Trust Receipts: Signed Context for Agentic Commerce
A TrustReceipt preserves signed context for a covered action. It does not by itself prove buyer intent, payment settlement or that the event occurred.
Executive summary
A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.
Published
2026-06-26
Updated: 2026-09-13
6 min read
Author
Trusteed
Published by Trusteed
Written and maintained by the team that builds Trusteed. Technical claims in these articles are backed by the surfaces linked from each piece and by the signed capability registry at /.well-known/trusteed-capabilities.json, which is the arbiter when an article and a status surface disagree.
About TrusteedCategory
Agentic Commerce

A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.
Issuing a receipt does not mean a payment was settled. At the 2026-09-13 review, the public merchant registry reported beta_closed, no production merchants and accepts_real_payments=false. Check /.well-known/merchant-index.json for current availability; demonstrations and checkout previews are not evidence of real purchases.
What a TrustReceipt records
A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.
- 1The action and context available to Trusteed on a covered path.
- 2The recorded policy decision and authorization context, when captured; not independent proof of buyer intent.
- 3References and canonical hashes of input/output when present; not a guarantee that every underlying record is embedded.
- 4A signature that makes changes to the signed record detectable. Payment references, when present, still require external evidence of settlement.
Why a dispute still needs other evidence
An agent’s declared intent, a merchant’s policy decision and a payment provider’s outcome can live in different systems. A TrustReceipt helps identify what Trusteed recorded and whether the signed content changed. It does not replace buyer consent, payment-provider records, order fulfillment evidence or a legal assessment.
From a covered action to a signed record
- 1An agent invokes an operation on a path with receipt issuance enabled.
- 2The applicable controls evaluate the request; recorded identity context depends on that path’s verification policy.
- 3Trusteed captures the available context, decision and references. A settled payment is not a prerequisite for every receipt.
- 4The issuance path signs and persists the record. Check the individual result; do not infer successful issuance from configuration alone.
- 5Where chaining is present, validate the chain reference separately. Corpus-wide chaining is not claimed.
Hash chaining and checkpoints are armed, not measured across the corpus. Receipts issued before the 2026-08-06 genesis are not chained, and post-genesis coverage has not been established. A valid individual signature does not prove that no record is missing from a sequence.
Verify v1.0 and distinguish v1.1
For v1.0, obtain the issuer's trusted public key from its JWKS and retain the verification material. Verify the JWS with the key selected by kid. Compare canonical input/output hashes only when the original data is available. Historical embedded JWKS and additional time evidence belong to v1.1 hardening, which remains gated; they are not guaranteed by a v1.0 receipt.
The public health endpoint reports issuance activity and the latest schema version. At this review it reported v1.0 issuance; that is a service observation, not independent validation of every receipt. v1.1 hardening remains behind a feature flag. Qualified timestamping is not active, and legal claims remain subject to external review.
What merchants can use it for
- 1Preserve signed evidence of the authorization context available at the time.
- 2Detect changes to signed records during an investigation.
- 3Link a recorded decision to external order or payment evidence where references exist.
- 4Share a verifiable record and the required verification material with an authorized reviewer.
Portability has prerequisites
Retain the signed record, the trusted public key and any original data needed to reproduce its hashes. Portability does not recover lost records or automatically provide historical key material. v1.1 historical snapshots must not be assumed in v1.0. Keep the source evidence under the applicable access and retention rules.
A TrustReceipt preserves signed context for a covered action. It does not by itself prove buyer intent, payment settlement or that the event occurred.
Frequently asked questions
What does a TrustReceipt prove?
A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.
Does every receipt confirm a payment?
Issuing a receipt does not mean a payment was settled. At the 2026-09-13 review, the public merchant registry reported beta_closed, no production merchants and accepts_real_payments=false. Check /.well-known/merchant-index.json for current availability; demonstrations and checkout previews are not evidence of real purchases.
Can every receipt be verified offline?
For v1.0, obtain the issuer's trusted public key from its JWKS and retain the verification material. Verify the JWS with the key selected by kid. Compare canonical input/output hashes only when the original data is available. Historical embedded JWKS and additional time evidence belong to v1.1 hardening, which remains gated; they are not guaranteed by a v1.0 receipt.
Is every receipt hash-chained?
No. Chaining is armed, but corpus-wide coverage is not measured. Check the individual receipt and chain evidence; a valid signature alone does not prove a complete sequence.
Sources and references
- TrustReceipt scope and verification
Trusteed
- Public issuance status
Trusteed
- Public merchant registry
Trusteed
Related articles
Developer Guides
Building Agentic Commerce #3: Reading Trust Score v4.1
Trust Score v4.1: three weighted dimensions, an optional bonus and confidence caps. Read each response's engine; legacy v2 fallback remains possible.
Developer Guides
Building Agentic Commerce #4: x402 Stablecoin Payments, When Agents Pay in USDC
How AI agents make on-chain USDC payments using the x402 protocol: multi-chain settlement, EIP-712 signatures, and stablecoin checkout.
Agentic Commerce
ACP vs AP2 vs x402: Complete Guide to Agentic Payment Protocols
Three protocols are shaping how AI agents handle payments. ACP (Stripe/OpenAI) for fiat, AP2 (Google) for cart mandates, and x402 (Coinbase/Cloudflare) for USDC stablecoins. Here's when to use each.