What a receipt for AI work proves

When an agent pays for a model call, two different things can be proven afterwards. One is that money moved, with the consent of whoever was entitled to give it. The other is that a particular machine ran a particular model on a particular input and produced a particular output. Both matter. They are not the same proof, and today they are usually produced by different systems that never refer to each other.

This article looks at what each kind of evidence covers, why a payment proof alone is not enough for AI work, and what it takes to bind the payment to the work, as Tenzro does as the open settlement and coordination layer underneath the operators and payment schemes involved.

What payment schemes prove

The open agent payment schemes are designed to answer a merchant's questions.

x402 describes itself as "an open, neutral standard for internet-native payments". It builds on the HTTP status code that RFC 9110 reserved for payment: a server answers a request with its payment requirements, the client returns a signed payment, and a facilitator verifies and settles it. What it proves is that a payment meeting the server's requirements was made.

AP2 addresses consent. It records the user's instructions and approvals as mandates: a checkout mandate for the specific items and terms the agent negotiated, and a payment mandate authorising payment against a specific instrument. Its authors describe the sequence from intent to cart to payment as creating "a non-repudiable audit trail that answers the critical questions of authorization and authenticity".

Both are answers to the questions of retail commerce: was I paid, and did the buyer agree to this purchase? For physical goods or content, delivery is a separate event that the buyer can observe and dispute. For AI work, it is not.

Why payment proof is not enough for AI work

The product of a model call is the response, produced on a machine the buyer never sees. Several things can go wrong that a payment proof cannot detect.

The model may not be the one paid for. A smaller or more heavily quantised model is cheaper to serve and can produce plausible output.

The usage may be overstated. Most AI work is priced per unit: input tokens, output tokens, audio milliseconds, image steps. If the only record of units is the serving side's own report, the bill is whatever that report says.

The machine may not be the one claimed. Where a buyer has chosen an operator for its hardware, its location or its compliance posture, a payment proof says nothing about where the work actually ran.

In each case the payment is valid and the consent is genuine. What is missing is evidence about the work.

What inference receipts prove

Standards work on that second kind of evidence is under way at the IETF, in the context of the RATS architecture for remote attestation.

The Attested Inference Receipt draft defines a signed envelope that "binds model identity, input/output hashes, attestation-linked metadata, and operational telemetry into a single signed artifact suitable for independent third-party verification of a confidential AI inference". It is careful about its own limits: a receipt is "Attester-signed Evidence, not an appraisal verdict", and a verifier must still appraise the platform attestation it references. Its first version covers CPU-side trusted execution environments; GPU confidential-compute attestation is out of scope.

A second draft, on attestation receipts, specifies a compact JSON receipt that binds an outcome to a request hash under a published key, so that "a party that does not trust the issuer's infrastructure can still verify offline" what was decided.

Neither draft addresses billing or payment. That is a reasonable scope for each. It also means that a buyer holding both a payment proof and an inference receipt has two documents that do not mention each other.

The gap: binding the money to the work

Closing the gap takes three bindings.

The receipt and the payment must refer to the same call. If the payment record names the request and the receipt names the request, anyone can confirm that a given payment bought a given piece of work.

The amount must follow from the receipt. If the billed units are taken from the signed receipt, and the receipt's units are bounded by what the buyer actually sent and received, the serving side cannot charge for work it did not do.

The signer must be a known machine. A signature is only as good as the key behind it. A receipt signed by a key held in hardware, and certified as belonging to a specific machine, carries more weight than one signed by a key that could be copied anywhere.

What a receipt still does not prove

Precision matters in the other direction too. A signed receipt proves that a particular machine, holding a particular key, attested to running a particular model on a particular input and producing a particular output. It does not, by itself, prove that the output is correct, or that the machine ran the computation honestly rather than signing a fabricated result. Those require further mechanisms: re-execution by an independent party, commitments that can be checked against a re-run, or hardware attestation of the execution environment. The useful question is not whether a receipt proves everything, but which of these mechanisms a buyer can ask for on a given call, and what happens when a check fails.

What this means for buyers and auditors

When you evaluate any system that settles AI work, ask for the payment record and the work receipt for a single call, and check whether they name each other. Ask where the billed units come from, and whether anything caps them. Ask where the signing key lives. Ask what you can verify without trusting the operator, the platform or the vendor's dashboard.

Where Tenzro fits

Tenzro settles AI work against receipts of the work. What is built, per the Tenzro repository documentation:

• A locally served answer carries a receipt signed by the serving node's session key, which is certified by the machine's hardware identity key and named in the receipt. It covers the catalogue model hash and engine, the serving machine's identity, the request nonce, the input commitment, the output hash, the billed units and the sampling parameters. A streamed answer carries its receipt on the final chunk.
• A forwarded call is billed from the provider's signed receipt, checked against the key the provider's machine registered, with every dimension capped by what was actually sent and received. A provider cannot over-report usage.
• Every payment leaves one record binding the request digest, the quote digest and the USD price the payer signed. After delivery, the payee lists a delivery receipt, including the inference receipt's digest, on that record. Request, quote, payment and receipts form one hash chain.
• Callers choose a verification level per call. On request, a chat response also carries a hash commitment over the top-k logits of each decoding step that any node holding the same weights can recompute; a disputed commitment goes to a committee that excludes the provider. At the optimistic level, answers are drawn for re-execution on another provider, and a mismatch is filed as an inference fault that refunds the caller. A node refuses a level it cannot meet before doing any work.
• Payments are kept in three classes that are never mixed: native settlements on the Tenzro ledger, payments proven from another chain, and attested payments on card, bank or processor rails, which are labelled, capped and never counted as proven.
• An agent's payments, with their receipts, can be exported as an evidence pack and verified offline against a certified state root.
• A node charges and accepts payment over x402 and MPP, the open agent payment protocols, and checks every payment against the paying agent's terms. Tenzro adds the binding between payment and work; it does not replace the protocols that prove payment and consent.