Verifiable receipts: why an agentic order needs signed proof

The transaction hash proves the money moved. It does not prove what was bought, at what price, under which rules or with whose permission. That is what gets disputed.

What a hash does not say

An agentic purchase settles in seconds and leaves the merchant with a transaction identifier. That identifier is excellent at one thing: proving that an amount moved from one address to another at a given moment. And it is useless for everything else.

It does not say which items were sold. It does not say at what price they were offered or under what conditions. It does not say whether the merchant had a rule allowing that sale, whether a human approved an order above the threshold, or who owned the agent that bought. When a buyer disputes a charge, an accountant reconciles a month, or somebody asks how an autonomous counterparty was handled, that is exactly what is needed.

Card networks answered this decades ago with the authorisation record. Agentic commerce has the payment and none of the record. Each system reinvents it as a log line, which is to say: as something the merchant can quietly edit afterwards.

What a receipt is, concretely

A JSON document per sale that binds together four things that live apart today: the offer that was made, the rules it was accepted under, the consent that existed and the settlement that happened. The store signs it with its own key and chains it to the previous receipt: each one carries the hash of the one before it.

The document includes, among other fields, its position in the chain, the previous hash, the event type, the store and its public key, the order and its number in the merchant's system, the exact terms that were quoted, the policy decision, the human approval if there was one, the agent's identity if it was required, and the payment with its hash, network, asset and amount.

Amounts are always decimal strings of integers in minor units, never number literals. A receipt travels between different languages, and JSON numbers lose integers above a certain size. A cent lost in a conversion ruins precisely the property the document was for.

The four properties that matter

It verifies without us. Checking a receipt means recomputing a SHA-256 over the body and validating an Ed25519 signature against the public key carried inside it. No API, no database, no service that could be down. If AgentPOS disappears, a store's receipts remain verifiable.

Chaining does not prevent tampering: it makes it visible. That is the real property. Whoever holds a later receipt can show that an earlier one was modified. A chain does not protect by magic, it makes rewriting the past leave marks.

What did not happen is evidence too. A refusal by policy, an order held because the payment did not match, an approval that expired unanswered: all of those produce a receipt. A chain that only records successes is a marketing document.

Never at the expense of the sale. A store that cannot write its receipt still delivers the order it was paid for. Evidence must not become a second point of failure.

No new custody and no new authority

The key that signs receipts holds no funds and belongs to the merchant. There is no central registry, no notary, no receipt service that could go down or charge a toll. That is the most important design point: if the proof depended on us, it would not be proof, it would be trust in us with extra steps.

Where this stands today

The format is written, implemented and published as a specification in the repository, marked as a draft and with its version declared inside every document. The store signs and chains every sale, the buyer receives a copy along with the order and can verify it independently, and the command line tool checks the whole chain.

What comes next, and does not exist yet, is anchoring the head of that chain on the network periodically, so that anyone can prove a receipt existed on a given date without trusting the store or us. It is planned and declared as future work, not as something you can use.

If the format itself interests you, the specification is in the repository and reads in half an hour. Criticism of a draft is more useful than praise for a final version.

The receipts specification ships with the repository, in October 2026. If you need it sooner, write to us.