Portable proof for agent transactions.
Open Receipt is a portable signed evidence format for recording what was authorized, what executed, what was delivered, and how the transaction settled.
Used today for Receipt capability transactions and designed as a rail-agnostic evidence format for card, wallet, API, stablecoin, and account-to-account transactions. Those additional rails are design scope, not a claim of current Receipt execution.
Standards positioning
Designed to complement commerce protocols.
Open Receipt is designed to map cleanly to mandate semantics such as AP2 and to carry evidence alongside commerce and payment protocols such as ACP and x402. This is standards-aligned architecture, not a claim of endorsement or certification.
Commercial facts and assurance
Know what the signature does—and does not—say.
Commercial facts identify the transaction, quote, seller, amount, currency, capability, and settlement event. A valid signature shows that signed content has not changed. Delivered or validated assurance describes the bound outcome evidence; it is distinct from signature validity and issuer trust.
Open Receipt 0.2 · Backward compatible with v0.1
Signed evidence with verifiable issuer trust
Open Receipt defines portable commercial evidence and the rules for verifying it. Version 0.2 adds purpose-bound signing keys, signed issuer metadata, historical key status, and issuance attestations. Conformance is defined by the published schemas, test vectors, and verifier behavior for each version.
spec_versionevent_idevent_typeissuerissued_attransaction_idquote_idcommercial_factsevidenceprovenanceassuranceparent_event_hashessigning_key_idissuer_metadata_versionissuer_metadata_hashissuance_attestationsignatureInitial event types
quote.issuedauthorization.grantedexecution.attemptedvalidation.completedsettlement.completedreversal.issuedAssurance
delivered records provider delivery.validated is used only when the bound Delivery Contract or validator ran and passed. Validation is evidence that the declared contract was satisfied—not a universal guarantee.
Deterministic and inspectable
Events use RFC 8785 JSON canonicalization and a detached compact JWS with Ed25519. Parent hashes bind signed events into a verifiable evidence chain. Signed, versioned issuer metadata publishes purpose-bound current and historical JWKs.
protected = { alg: "EdDSA", kid, typ: "open-receipt+jws" }
payload = RFC8785(event without signature)
input = b64url(protected) + "." + b64url(payload)
signature = Ed25519.sign(input)
event.signature = b64url(protected) + ".." + b64url(signature)Verify online, pinned, or fully offline
The TypeScript package separates mathematical signature validity from issuer trust. Resolve signed metadata over allowlisted HTTPS, pin a trusted snapshot and hash, or use an embedded key for untrusted cryptographic consistency. Offline results report their metadata freshness and knowledge boundary.
Receipt documents use wire spec_version values 0.1 and 0.2. These are distinct from Python implementation version 0.2.1 and TypeScript implementation version 0.2.2.
TypeScript
npm install @receiptprotocol/open-receipt@0.2.2
import { verifyOpenReceiptTrust } from "@receiptprotocol/open-receipt";
const result = await verifyOpenReceiptTrust(receipt, {
trustMode: "pinned_metadata",
pinnedMetadata: cachedMetadata,
pinnedMetadataHash
});Python 3.10+
pip install open-receipt==0.2.1
# Local file or stdin
open-receipt verify ./receipt.json
cat receipt.json | open-receipt verify -CLI — local cryptographic verification
npm install --global @receiptprotocol/cli@0.1.3
receipt verify ./open-receipt-v0.1.json
# Pin v0.1 issuer identity from a trusted local metadata copy
receipt verify ./open-receipt-v0.1.json \
--issuer-metadata ./issuer.jsonThe CLI verifies v0.1 events and bundles from local files. Use the TypeScript package above for full v0.2 trust-aware verification.
Schemas and test vectors
The v0.2 catalog defines 30 deterministic lifecycle and trust vectors using non-production test keys. Every downloadable v0.1 example is also synthetic and uses a reviewed test-only signing key.
JSON Schemas
Synthetic offline examples
SYNTHETIC TEST VECTOR — NOT A PRODUCTION TRANSACTION
These deterministic conformance fixtures use test-only identities, transactions, amounts, keys, and signatures. You can also verify your own downloaded receipt entirely offline.
Small by design. Open to scrutiny.
Open Receipt is an open, versioned specification for portable, verifiable commercial evidence. The schemas, verifier, and vectors are public so implementers can inspect, test, and challenge the design. Conformance is defined by the published schemas, test vectors, and verifier behavior for each version.
Inspect the specification, verifier source, schemas, test vectors, examples, contribution process, and security policy on GitHub.