The evidence layer for agent commerce
Identity says which agent knocked. Authorization says what it was allowed to do. Payment says value moved. None of them says what arrived.
The evidence layer is the record that binds all four together — Ed25519-signed, independently verifiable, and issued separately from the rail that carried the money.
Four layers, four different questions
An autonomous purchase crosses four boundaries. Each has protocols, and each answers a genuinely different question.
| Layer | The question it answers | Where it's handled |
|---|---|---|
| Identity | Which agent is this, and who controls it? | Web Bot Auth signatures, wallet handles, agent credentials |
| Authorization | Was this agent permitted to spend, and under what mandate? | Delegated authorization, spending policies, payment mandates |
| Payment | Did value move, and did it settle? | x402, card rails, Stripe, stablecoin rails |
| Evidence | Under what authority was this bought, what was delivered, and can a third party check it? | The signed record — this page |
The first three are being standardized quickly and well. What none of them produces is a single artifact that a counterparty, an auditor, or a regulator can verify without access to the systems that ran the transaction. That's a different job, and it's the one CertifiedData does.
Where each protocol defines its scope
This is not a competitive comparison. Every protocol below drew a scope boundary deliberately and published it, and each is well designed for what it covers. The point is that the boundaries all sit in roughly the same place — and there's something on the far side of them.
As of August 2026, from each party's own published documentation. Specifications move — FIDO's Payments TWG is the boundary most likely to shift.
x402 ↗
HTTP-native payment negotiation and settlement
Its PAYMENT-RESPONSE carries settlement outcome — success, error reason, transaction, network, payer. The Foundation currently lists working groups for Domain Discovery, Identity, Tax, and Card Acceptance; none is dedicated to audit-grade transaction evidence.
Visa Trusted Agent Protocol
Agent recognition and intent signalling at the merchant front door, over RFC 9421 HTTP Message Signatures
Lists post-transaction reconciliation and settlement procedures as out of scope.
Agentic Commerce Protocol (OpenAI + Stripe)
Delegated payment tokens, scoped by amount and expiry, plus risk signals
States that settlement, refunds, chargebacks and compliance remain with the merchant and their PSP.
AP2 / Verifiable Intent (FIDO, Google, Mastercard)
Payment mandates as portable, cryptographic evidence of user intent — designed for validation without relying on proprietary logs
Mastercard's own documentation states it does not cover delivery, fulfillment, or order fulfillment.
Legal Context Protocol (AAA-ICDR and contributors)
Pre-transaction legal terms discovery and consent
Defers signed receipts, evidence bundles and audit records.
Read down the boundaries and the same shape appears five times. Authorization is covered. Settlement is covered. Delivery is not. That gap is not an oversight — proving what was delivered requires fingerprinting the delivered artifact, which is a different technical problem from moving money, and payment protocols correctly declined to take it on.
An independent Internet-Draft proposes adding cryptographic receipts to x402 — indicating the gap is recognized but not standardized. (It is an individual draft: not an IETF standard, not working-group output, and not an endorsement of anyone's implementation. Its signature suites differ from ours; the overlap is canonical signed receipts and independently verifiable evidence. The relevant distinction: the draft defers delegation binding, while CertifiedData binds each purchase to the authorization policy that permitted it.)
For agent architectures using x402, these compose: the protocol negotiates and settles the payment; the signed record carries the authority it was made under and the artifact that came back. Detailed mapping: x402 comparison.
Why an issuer-signed receipt isn't independent evidence
Several agent payment stacks now issue cryptographically signed receipts. The cryptography is real. The independence usually isn't. When the party that executed the transaction also signs the record of it, the result is a self-attestation with a good signature — tamper-evident, but the entity making the claim and the entity vouching for it are the same. It's the first thing a counterparty will question.
Independence has three requirements, and all three have to hold at once:
- Client-side verification. The check runs against public keys in the verifier's own environment. A server responding
verified: trueis a claim, not a proof — which is why every evidence page here runs the Ed25519 check in your browser and shows it separately from the server's verdict. - No access required. The verifier needs the record and the public key. Not an account, not an API key, not permission from anyone.
- Fail-closed evidence. If a binding cannot be proven — a policy snapshot that predates capture, an artifact that was never fingerprinted — the record says so explicitly rather than substituting a nearby value. A record that overstates itself is worse than no record.
The evidence layer is the independently issued, cryptographically signed record binding an agent's identity, its authorization, the payment, and the delivered artifact into one object that any third party can verify without trusting the platform that produced it.
The Agent Commerce Evidence Bundle
A transaction produces its evidence across several artifacts — an authorization, a decision record, a signed receipt, a policy reference. The bundle assembles them into one verifiable object at one opaque URL. Fields marked live are deployed and verifiable today; specified means designed but not yet shipped.
Agent and authority
- Buyer-agent identity (id + name)live
- Controlling principal — as a SHA-256 commitment, never a raw identitylive
- Payee identity (registration and payment-capability states recorded separately)live
- Signed authorization decision, outcome and rationalelive
- policy_id + policy_hash + policy_version — the snapshot evaluated at authorization timelive
Transaction
- Amount, currency, raillive
- Purpose — what was being boughtlive
- Settlement state, in exact operational terms (see below)live
- Settlement referencelive
- Internal transaction id — as a SHA-256 commitment onlylive
Delivery
- SHA-256 fingerprint of the delivered artifact (dataset purchases bind it at authorization)live
- Certificate id, where the artifact is certifiedlive
Provenance
- Decision Ledger record linkagelive
- Linked receipt id, hash, and public verify URLlive
- issued_at, signing key id, Ed25519 signature over the RFC 8785 canonical payloadlive
- USDC (Base) and ETH settlement railsspecified
Two things make this more than a formatted log. Policy binding — the hash and version of the policy snapshot in force at authorization time, so “this was authorized” becomes checkable rather than asserted (records that predate snapshot capture say bound: false — the current policy is never substituted). And delivery binding — the SHA-256 fingerprint of what actually arrived, which is what separates evidence of a payment from evidence of a transaction.
Settlement states use exact operational terms: checkout_session_created_not_settled · completion_observed_not_settled · settled · simulated_sandbox. A created Checkout Session is never described as a settlement, and the final signed receipt is issued only after the rail's authoritative success event.
Verify one yourself
The verification path is deliberately boring, and that's the point.
- Take an evidence bundle URL (or a receipt and its
verify_url). - Fetch the public key from
/.well-known/certifieddata-public-key.pem. Agent Commerce signs with its own key — separate from the certificate and Decision Ledger keysets. - Canonicalize the payload per RFC 8785, SHA-256 it, verify the Ed25519 signature — in your own environment. Every
/evidence/…page runs exactly this in your browser and shows it next to (never merged with) the server's own verdict. - For a delivered dataset, compare the SHA-256 fingerprint against the bytes you received.
On the public demo: the anonymous flow runs the complete path — mint a key, discover the agent, read the policy and live budget, authorize, execute, verify — as a stranger, against production. Sandbox records exercise the full signing path with settlement simulated and labeled (simulated_sandbox). They are not valid as compliance evidence; production records under a paid plan are.
Who else is working on this
A category with one participant is usually a category that doesn't exist. This one has several: independent vendors converging on signed agent receipts, auditor-facing evidence exports for EU AI Act logging, and academic work arriving at the same conclusion from formal analysis — the RAILS paper puts it plainly: tool protocols record what was called, not whether the call satisfied the obligation.
Nobody has settled on a name — the same layer is currently called an evidence layer, evidence packs, self-authenticating records, and verifiable receipts by different parties. Convergence from unrelated directions is usually a sign the problem is real. It's also a reason to publish specifications openly: certifieddata-agent-commerce-public carries the OpenAPI contract, event schema, SDKs, and Ed25519 receipt-verification test vectors — the vectors, not prose, are the normative description of our canonicalization.
The record-keeping angle
An agent purchase made by a high-risk AI system is an operational event, and EU AI Act Article 12 requires high-risk systems to keep automatic logs of their operation. Application logs generally satisfy the letter of that. What they handle less well is the case where the record is challenged rather than merely reviewed — a log stored by the deploying organization is evidence produced by an interested party. Records that are Ed25519-signed and verifiable without access to internal systems are a stronger artifact for that situation.
CertifiedData produces evidence records that support Article 12 record-keeping. The obligation itself remains with the deploying organization — the platform provides the artifact, not the compliance. Article-by-article detail: Article 12.
Honest questions
What is the evidence layer in agent commerce?+
The independently issued, Ed25519-signed record binding an agent's identity, its authorization, the payment, and the delivered artifact into one object that any third party can verify without trusting the platform that produced it.
How is this different from a payment receipt?+
A payment receipt confirms settlement. An evidence record additionally carries the hash of the policy snapshot that authorized the purchase and a SHA-256 fingerprint of what was delivered — so authorization and delivery are checkable, not asserted.
Does this replace x402?+
No. x402 handles HTTP payment negotiation and settlement. The evidence layer records the authority the payment was made under and the artifact returned. They compose.
Why does it matter who signs the receipt?+
When the party that ran the transaction also signs the record, the claim and the vouching come from the same entity. Independent evidence is verifiable without that issuer's cooperation — public key, client-side check, no account.
Can I verify a record without an account?+
Yes. Fetch the Ed25519 public key from /.well-known/certifieddata-public-key.pem and verify the signature client-side over the RFC 8785 canonical payload. Every evidence page runs this check in your browser and shows it separately from the server's own verdict.
Is the anonymous demo valid as compliance evidence?+
No. Sandbox artifacts exercise the full signing and verification path — settlement is simulated and the record says so (settlement_state: simulated_sandbox). Production records under a paid plan are the compliance artifact.
If it verifies for you as a stranger, it verifies for an auditor.
Run the anonymous loop and verify the record it issues — in your own browser, against the published key. Sandbox is free; production starts at $49/mo.