Verify a Receipt

A Receipt is the artifact you hand an auditor, a customer, or a counterparty when they ask what exactly happened, and what did it cost. This guide is the counterparty's side: given a receipt, prove it is authentic — offline, with nothing but the receipt bytes and Ductor's published public keys.

What you are verifying

The signed unit is a canonical byte string — a versioned, deterministic serialization of the receipt's envelope. Three design choices make offline verification actually mean something:

Everything that matters is inside the signature

The algorithm and signing-key id are bound into the signed bytes under a domain-separation constant, so a signature can never be replayed onto different claims, a different scheme, or a different system's payloads.

Lifecycle state is outside it

Whether a receipt has settled is derived from immutable facts, never written into signed content — so a receipt settling later cannot disturb a signature you already verified.

Use the returned canonical bytes

The API supplies canonical signing bytes and their payload hash. Verify those bytes directly; do not reconstruct them with your client's JSON serializer.

The procedure

The whole path, and the two places a forged or altered receipt is caught:

Every failure edge is terminal: there is no fallback key, no re-serialization attempt, and no partial pass.

curl -s https://api.ductor.io/.well-known/work-receipts/jwks.json

sum := sha256.Sum256(canonical)
if hex.EncodeToString(sum[:]) != receipt.PayloadHash {
    return Tampered
}
ok := ed25519.Verify(publicKey, canonical, signature)

The verdict is structured, not boolean — each check answers separately:

A hosted second opinion exists — VerifyWorkReceipt on the API, and the governed work_receipt.verify tool for agents. It applies the deployment's configured key policy as well as the hash and signature checks.

Full receipt retrieval and hosted verification require work_receipt:read in the authenticated tenant. Bespoke MCP work_receipt.get and work_receipt.verify enforce that permission on every call through the canonical explicit-scope, wildcard, or role-bundle rules, even with an older manifest. Missing, anonymous, expired, or unauthorized cross-tenant principals are refused before private lookup. Keep the manifest lease and exact discovered tool version/schema pins; those grants supplement current permission.

REST uses the field names above and adds ok. The bespoke MCP work_receipt.verify tool returns KeyFound, WithinWindow, HashMatch, SignatureValid, and Reason, with no ok field. All four check fields must be true for a complete pass.

New-signature readiness is separate from historical verification. Issuance startup proves the active private/public pairing, and each signing call checks current availability plus the canonical payload's actual issuance timestamp. An expired signing key blocks new signatures, while a receipt issued within its window can still verify against its retained public key and current policy. Issuance can be disabled with public keys only. Changing key policy requires the existing deployment restart; there is no silent fallback or hot reload.

A valid signature authenticates Ductor's recorded claims. For held RFQ work, the signed acceptance records the independently journal-backed output-schema verdict evaluated before settlement. Cryptographic verification authenticates that verdict; it does not establish factual accuracy or quality beyond the published schema. See Clear AI work.

Reading what you verified

For held RFQ work, first find the original signed receipt through GET /api/agent-rfqs/{environment_id}/{session_id}/observation, or generated governed MCP api_agentrfqservice_getagentrfqobservation. The buyer needs routing_market:read and access to the requested environment. This read-only snapshot correlates market, award, admitted execution, journal, and exact original issuance identity; it does not supply signing bytes or perform verification. Retrieve those bytes with the separately authorized WorkReceipt getter, then apply the procedure above.

Issuance can be pending, dead-lettered, missing, or mismatched after money has settled. A signed original may also exist before its id is backfilled on the award, and a later amendment does not replace that original. Launch-void awards currently have no WorkReceipt. Observation makes these states visible without repairing them; its unsigned response is not independent cryptographic proof or a payout-account attestation.

The separate configured recovery worker can enqueue an absent original request from validated terminal financial evidence, or link an already signed exact original without altering its bytes. It never substitutes an amendment or manufactures an absent original after reversal. Pending requests keep their persisted retry schedule; restore the same key while issuance remains pending. A dead request without an original is not automatically revived. See original receipt recovery for bounds and refusal cases. Continue to verify the original independently; automatic linkage is not signature verification.

A verified receipt is a set of claims, each anchored to deeper evidence:

• worker identifies the selected worker and its source definition. RFQ award receipts snapshot the original awarded pins; re-pinning or deleting a registration before delayed issuance cannot replace them. Failed award receipts retain this worker identity. Ordinary unassigned routing outcomes may have worker: null.
• acceptance records the accepted flag/reason/version; task, schema, input and actual output hashes; source and governed execution definitions; session, turn, manifest, policy receipt, run, step, cost, and evaluation time. All are signed. A committed full RFQ receipt requires an accepted verdict. A completed rejected task instead records completed, accepted: false, and released.
• route carries the decision id and a digest of its explanation — the snapshotted why, not a live reconstruction.
• tools carries the content hash of the exposure manifest the agent acted under, joining the per-invocation receipts from the governed tool surface.
• cost is exact: int64 micro-units, with total equal to the sum of its breakdown by construction.
• settlement references the journal transactions that moved the money — arriving at issuance when settlement already committed, or later as a signed amendment that never mutates the original.

Held awards preserve their original payout account through registration rotation, deletion, capture retry, and claw-back. The receipt signs totals and transaction references; it does not sign account details or a digest of journal entries. Proving the actual payout owner requires trusted tenant-scoped journal retrieval and reconciliation. The hosted receipt verifier does not perform that check.

Amendments chain: a claw-back, a late settlement, each is a new signed receipt referencing its predecessor, and the chain reads newest-last with the original intact. Verify each link the same way.

Where to go deeper