Proof & Audit

Receipts & proof

A successful paid call produces three artifacts: a signed receipt, an audit-chain entry, and a downloadable proof bundle the agent's principal can verify offline.

Signed receipts

Receipts are signed via a Signer port. Production implementations are KMS / HSM-backed. Ephemeral signers are refused in production without an explicit override.

  • Ed25519-signed receipts shipped
  • KMS-backed signer in production shipped
  • Signing-key rotation with historical verify shipped

Receipt shape

{
  "schemaVersion": "agenttrust.receipt.v1",
  "receiptId": "rcp_<placeholder>",
  "providerId": "prv_<placeholder>",
  "requestSha256": "<sha256>",
  "agentDid": "did:web:<placeholder>",
  "principalId": "<placeholder>",
  "paid": true,
  "facilitator": "sandbox",
  "signature": "<ed25519>",
  "signingKeyId": "gw-ed25519-<id>"
}

Proof bundles

A proof bundle is a downloadable artifact that contains the receipt, its hash-chain proof, and the verifier's manifest. Customers run pnpm proof:verify <bundle> to verify offline.

  • Offline proof verifier (pnpm proof:verify) shipped
  • Per-receipt hash chain proof shipped
  • Bundle signature over manifest shipped
$ pnpm proof:verify ./bundle-12af34.zip
{
  "schemaVersion": "agenttrust.proof_bundle.v1",
  "verdict": "valid",
  "receiptCount": 2,
  "hashChainContinuous": true,
  "signaturesValid": true
}

Hash chain

Receipts are not just signed — they are linked. Every receipt commits to its predecessor's hash. Tampering with any receipt breaks the chain. Verification is offline.

Boundaries

  • The receipt body is sha256-hashed by default; raw bodies are not retained unless the merchant opts in.
  • Public verification depends on the gateway's published Ed25519 public key. Key rotation preserves historical verify.
  • Proof bundle is generated on demand; it is not pushed to a registry.