Provenance

A trace answers the question for you. Provenance is the same question asked by someone else, months later, who was not in the room: what did this agent actually know when it made that decision, and how would I know if the record had been edited since.

Those are different problems. The first needs a good log. The second needs a commitment made at the time, verifiable without asking the party who benefits from the answer.

What already holds

Every call, delivered or refused, writes a record of the sources considered, what each one scored, which attempts ran, the checks that passed, the level that came out and why. Where an answer was anchored, the reference, its value, its round timestamp and the tolerances applied are all in there, along with whether that reference was independent of the source it agreed with.

Metera also distinguishes a number the source measured from one we derived by counting something it returned. That distinction, origin, rides on every answer, because a derived number and a measured one are different kinds of claim and only one has a provider standing behind it.

Traces are readable only by the account that made the call, and an id belonging to someone else is indistinguishable from an id that never existed.

How provenance works today

A record you hold is evidence to you and an assertion to everyone else. Making it evidence to a third party needed three things, and all three are built, running on devnet.

A commitment written at delivery time. Every delivered answer is hashed into a Merkle leaf at the moment it ships, batched, and committed to Solana in a single memo transaction. It is not reconstructed later from a log we control: the exact object that was hashed is stored with the trace, so a verifier checks the leaf that went into the tree, not a leaf rebuilt from the row as it stands today.

Verifiable without querying us. The trace carries the leaf, its hash, the Merkle path, the root, the signature and the slot, plus the key the fee payer must match. Anyone holding a trace can recompute the hash, walk the path to the root in the on-chain memo, and confirm who paid for the transaction, without asking Metera anything. Editing the record, or upgrading the level it claims, breaks the proof.

Without putting the caller's data on a public ledger. The leaf commits to a hash of the delivered value, never the value. And the chain carries only the root of each batch, never a leaf. What an agent asked about, and what it got back, stays in the trace, which stays private to the account that made the call. The proof shows that a specific answer existed at a specific time, and nothing else.

That last one is what made this hard. The obvious design publishes a hash of the trace, and a hash of the trace leaks the shape of what an agent was asking about, which is often the sensitive part rather than the value itself. A batch root reveals neither.

Where it matters

Wherever an agent's decision has to survive review. A treasury operation executed at a price someone later disputes. A risk check that passed before a transaction that failed. An audit asking not whether the agent was right but whether it was reckless, which is a question about what it knew and at what level of confidence.

What this does not prove

An on-chain record proves what was delivered and when. It does not make the number right. The proof says Metera returned this answer, at this level, at this moment, and that nobody has changed the record since. Whether the answer was correct is what the level was for, and the two must not be confused.

This runs on devnet today, and mainnet is next, once we have measured the real per-batch cost. Calling a devnet proof final would be exactly the kind of overstatement the rest of this product is built to prevent, so this page says devnet until it is not.