Skip to main content
Some applications need more than data — they need a proof of where it came from: “eligible data carries a proof it came from service X.” The protocol provides a standardized place to express that: a provenance commitment for a data point. The protocol anchors a fingerprint (a hash) on-chain; the actual proof and metadata live off-chain. A buyer fetches the proof and checks it against the on-chain hash. The protocol stays cheap, private, and not opinionated about what the proof is. In some cases, that proof is a ZK proof of a specific attribute of the data, for example, that a given file contains a minimum number of conversations, or that a given video meets a quality requirement.
Status. Not yet live. These fields are being added to the data registry so the protocol has a standardized place to express verifiability. The protocol anchors provenance; the off-chain attestation is what establishes origin, with the attestation layer and zkTLS hardening to follow.

​
How it works

The protocol stores only hashes — no data, no metadata, and no file location on-chain. Each data type defines its own metadata schema off-chain; the protocol never parses formats.

​
What the protocol anchors

A few fields on the (scope-aware) data registry: Metadata can live in a third party-provided service, in personal servers, or any other off-chain store. Only authorized buyers fetch it and verify it against the on-chain hash.

​
Pluggable proofs

The protocol is not opinionated about the proof. The on-chain anchor is the same regardless of how provenance is actually established, so the proof system can evolve with no contract change:
  • Initially: an attestation signed by a Vana verification service — “this data came from service X.”
  • Later: a decentralized attester network, or zkTLS-style proofs, or any other scheme a data type wants.
Attestors are not fixed. Depending on its requirements, a data type can rely on a centralized provider, a decentralized attester network, or a trusted execution environment writing the attestation — and different data types can make different choices at the same time. A single signed attestation means trusting its signer; a data type that needs weaker trust assumptions can use a decentralized or TEE-based attestor. Because the protocol only stores a hash of whatever proof exists, these implementations coexist behind the same fields, and can evolve, with no contract change.

​
Binding to the data

A provenance proof is only meaningful if it is about the exact data the buyer receives. Otherwise a buyer could verify a real, valid attestation that is not actually about the bytes they were handed (proof substitution). That is what dataCommitment is for, and why it is distinct from metadataHash:
  • dataCommitment binds the data; metadataHash binds the proof/metadata.
  • An attestation signs over or references dataCommitment, so “service X produced this” is provably about this committed data.

​
What this gives you

A standardized, cheap, private slot to commit to a data point’s provenance, and an upgrade path from a signed attestation to stronger proofs (zkTLS, decentralized attesters) without touching the contract. The on-chain anchor commits to the data; the strength of the origin guarantee comes from the off-chain attestation, which buyers fetch and verify against the anchor.