Receipt
The signed, verifiable record of what happened and what it cost — decision, tool manifests, cost, consent, and settlement joined into one object.
A Receipt is the signed, verifiable record of what happened and what it cost
— Receipt (WorkReceipt) in the API. It joins the
route's explanation, content-hashed tool-exposure manifests and invocation records, the cost
in exact units, the consent trail, and the settlement reference into one object:
the artifact you hand an auditor, a customer, or a counterparty when they ask
what exactly happened, and what did it cost.
The evidence exists today as separate records — decision explanations, content-hashed tool-exposure manifests, per-request cost accounting, consent certificates. The unified, signed receipt is the object that joins them and makes "provable" literal.
shipping — the joined WorkReceipt aggregate, its Ed25519 signer, the verify
surface, and JWKS key publication are live; issuance is enabled per deployment
behind a config gate.
What "signed" means
A receipt is immutable and Ed25519-signed. Signing binds a versioned canonical serialization of the payload — including the algorithm and signing-key id, under a domain-separation constant — so a verifier can recompute the hash and check the signature against a key published via JWKS offline. To also check the deployment's key-validity and revocation policy offline, the verifier needs trusted policy metadata from the operator; JWKS publishes public keys without those policy fields. Lifecycle state is never inside the signed bytes: it is derived, so a receipt settling later can never disturb its signature. A redacted shareable receipt is a distinct re-signed object issued under a revocable, expiring share grant — never a blanked copy of the original, and the full receipt is never public.
Held RFQ receipts also sign the versioned acceptance verdict: task/schema/input
and output hashes, original source and governed execution definitions, actual
agent session/turn and manifest, policy receipt, run/step, cost, and evaluation
time. Full capture receipts require accepted output; a completed workflow with
rejected worker output records completed, accepted: false, and released.
Original worker pins survive registration changes before asynchronous issuance.
Redacted shares omit private acceptance and run/session evidence; the full
original is needed to verify those claims.
Enabled signing proves the active private/public key pair at startup and checks
both current availability and the actual signed issuance timestamp on each
call. Expiry blocks new signatures while historical verification continues
under issuance-time policy and current revocation flags. Full receipt get/verify
requires work_receipt:read, separately from buyer market observation and an
MCP exposure grant. Public-only verification remains available with issuance off.
Money can settle before the signed original is available. A bounded recovery worker can restore an absent original issuance request from validated financial evidence or link an existing exact original, preserving its signed bytes even after reversal. It never replaces the original with an amendment, creates a missing original from reversal, or revives a dead request without its receipt. See original receipt recovery.
WorkReceiptAssembled at terminal outcome from the evidence records.
WorkReceiptCanonical bytes signed and stored.
WorkReceiptFinalized once settlement commits.
WorkReceiptA claw-back appends a compensating receipt — the original is never mutated, and amendments carry stable identities so retries converge instead of duplicating.