Minimal Receipt Format for Agent-to-Agent Payments: Five Fields for Verifiable Transactions

When two AI agents complete a payment, the on-chain record only tells you "A transferred X to B at time T" — it says nothing about what was purchased, what was delivered, or whether the amount matched the original quote. If a dispute arises, both parties are left piecing together a story from chat logs. An author identifying as an AI agent, mbnagent, has proposed a minimalist receipt design that aims to solve this "payments are traceable but not provable" problem at its root.

The Core Problem: Transfers Have No Context

An on-chain transfer is an isolated fact. It records an amount, a recipient address, and a timestamp — but carries no business semantics. It doesn't indicate which request the payment corresponds to, what was delivered, or whether the actual amount matches a prior quote.

In human-to-human transactions, this information is typically scattered across emails, chats, or contracts, filled in manually after the fact. But in agent-to-agent automated payment scenarios, there's no human present to provide post-hoc interpretation. As transaction volume scales and disputes arise, the lack of structured evidence makes the entire chain unauditable.

Five Fields Are Enough

The author argues that a self-proving payment receipt needs only five core fields:

• request_id: A hash of the canonicalized JSON of the request (keys sorted, whitespace stripped). Both parties can independently recompute it to confirm "which request was paid for."
• quote: Amount, asset type, and expiration timestamp.
• payment_ref: The transaction signature, written into the transfer memo or referenced later.
• deliverable_hash: A hash of the actual delivered artifact (file, report, JSON).
• status: Quoted, paid, delivered, accepted, or disputed.

The elegance of this schema is that it compresses the entire lifecycle of a transaction — from quote and payment to delivery and acceptance — into a few computable, verifiable values, without relying on either party's logs.

Why Canonical Serialization Is Critical

The central risk in this design lies in how request_id is generated. If two agents hash the same request but use different key ordering or whitespace formatting, they'll produce completely different IDs, and the link between payment and request will silently break — no error thrown, but the evidentiary chain is already invalid.

The solution is to define a single canonical form. The author recommends RFC 8785 (JSON Canonicalization Scheme) and suggests using a shared set of test vectors to verify that both implementations produce consistent results. This is an easily overlooked but critical engineering detail: the determinism of a hash depends entirely on the determinism of serialization.

RFC 8785 (JSON Canonicalization Scheme, JCS) is an IETF standard published in 2020. It defines a set of rules for converting any JSON object into a unique byte sequence: keys are sorted by Unicode code point, number formats are unified, extraneous whitespace is removed, and string escaping is fixed. This means that whether you're using Python's json.dumps or JavaScript's JSON.stringify, any implementation conforming to JCS will produce byte-for-byte identical serialization — and therefore identical SHA-256 hashes — for the same logical JSON object. In agent payment scenarios where buyer and seller may use entirely different programming languages and runtimes, JCS is the contract that eliminates this heterogeneity. Test vectors play an equally critical role: they are known input/output pairs that all parties must pass before integrating with the system, ensuring "we all understand the spec the same way." Specs without test vectors frequently produce silent divergences on edge cases (such as whether 1.0 and 1 are handled identically), which are hard to catch in unit tests and only surface during real transaction reconciliation.

Four-Step Verification: Trust No One

The value of a receipt lies in its ability to be independently verified by a third party. The author lays out a clear four-step process:

1. Recompute request_id from the stored request.
2. Verify the on-chain transaction: does the amount, recipient address, and memo or reference match the quote?
3. Recompute deliverable_hash from the delivered artifact.
4. Confirm the time sequence: payment occurred before quote expiration, delivery occurred after payment.

If all four checks pass, the receipt is self-validating — no need to trust either the buyer's or seller's logs. This is the core value of the entire design: transforming dispute resolution from "my word against yours" to "recompute and reveal the truth."

Common Mistakes

The author also lists several pitfalls that repeatedly appear in practice:

• Paying before the quote is locked: The amount can drift, making the payment and quote impossible to match.
• Storing only the transaction signature: This loses the context of the request and delivery — effectively starting over from scratch.
• Mutable deliverables: You should hash a snapshot of the delivered artifact, not a URL — the content a URL points to can be altered at any time.

What these mistakes share is that they all break the receipt's "recomputability." Once any step can no longer be independently reproduced, the self-validating chain is broken.

Implications for the Automated Economy

This design proposal, written by an AI agent, is brief — but it touches on a foundational infrastructure problem for the agent economy. As AI agents increasingly call each other's services and pay per use, trustworthy transaction verification can no longer depend on manual reconciliation or platform endorsement.

The author themselves offers research briefs and design reviews at roughly $1–3 per engagement, using a "pay after delivery (on Solana)" model — which is itself a real-world application of this receipt design. A lightweight, trustless receipt standard that can be independently verified by both parties and any third party may become a necessary prerequisite for large-scale agent collaboration.

Of course, this proposal remains at the design stage, lacking large-scale validation or standardization. But the core principle it introduces — using canonical hashing and on-chain references to build a self-proving evidentiary chain — is worth considering for any team building agent payment systems.

The agent economy describes a new form of transaction in which AI agents act as economic actors, autonomously entering service contracts with each other, completing payments, and delivering results. Unlike traditional API calls, agent-to-agent transactions typically involve dynamic pricing, pay-for-outcome models, and multi-round negotiation — and traditional OAuth or API key systems don't natively include a semantic layer that binds "payment to delivery." Relevant standards currently being explored in the industry include Anthropic's Model Context Protocol (MCP) and various on-chain micropayment channels, but there is no recognized standard specifically for a lightweight receipt format binding the payment-request-delivery triad. The approach proposed here operates at the application layer, independent of any specific blockchain. It can theoretically be implemented on any chain that supports memo fields, which keeps migration costs low — but also means adoption depends on ecosystem participants organically converging on the standard to create network effects.