The receipt chain

Every request through RelayOne produces a signed receipt. Every receipt carries the previous receipt's hash and is signed with an Ed25519 key specific to its signer: ingress node, sovereignty tagger, identity decider, rerouter, egress node, commerce settler. Nine signers in the app-layer chain.

The chain is verifiable end-to-end. An auditor with the public keys can walk every request without trusting RelayOne at all. There is no "please trust our logs" step.

Ed25519 signatures throughout: every node publishes its key to the evidence bundle
append-only storage: receipts are written to tamper-resistant DB tables with integrity extensions
no cloud backstop: verification does not rely on CloudTrail, KMS, or S3 bucket versioning
deterministic serialization: receipts canonicalize before signing so replays match

Evidence bundle shape

A signed evidence bundle is a tar.gz with a manifest, the receipt log for the window, the chain-of-custody roster, and the verifier tool. Below is the top-level schema your auditor receives.

Signed evidence bundle (v2)

{
  "bundle_version": "v2",
  "tenant": "acme-finance",
  "window": {
    "start": "2026-04-01T00:00:00Z",
    "end":   "2026-04-30T23:59:59Z"
  },
  "policy_snapshot": {
    "version": "2026-03-22-cel-1",
    "sha256": "7c9e0b...e1d4"
  },
  "chain_of_custody": [
    { "node": "ingress",      "pubkey": "ed25519:MCowBQYDK2VwAyEA..." },
    { "node": "sovereignty",  "pubkey": "ed25519:MCowBQYDK2VwAyEA..." },
    { "node": "identity",     "pubkey": "ed25519:MCowBQYDK2VwAyEA..." },
    { "node": "reroute",      "pubkey": "ed25519:MCowBQYDK2VwAyEA..." },
    { "node": "egress",       "pubkey": "ed25519:MCowBQYDK2VwAyEA..." },
    { "node": "truecom",      "pubkey": "ed25519:MCowBQYDK2VwAyEA..." }
  ],
  "receipts": [
    {
      "request_id": "req_01J...",
      "ingress": { "at": "2026-04-12T14:22:01Z", "sig": "..." },
      "envelope": {
        "origin_region": "ca-central-1",
        "destination": "openai:gpt-4o",
        "residency_required": "ca",
        "cross_border": false
      },
      "decision": { "outcome": "rewrite", "policy_rule": "no-pii-to-external", "sig": "..." },
      "reroute": { "target": "r1://internal/summarize-v3", "sig": "..." },
      "egress": { "at": "2026-04-12T14:22:02Z", "bytes_out": 842, "sig": "..." },
      "settlement": null
    }
  ],
  "disputes": [],
  "verifier": "bin/relayone-verify",
  "manifest_sig": "ed25519:..."
}

The verifier walks every receipt, checks each signature against the chain-of-custody roster, and reports a pass or a specific failure. Verification is offline. No network call to RelayOne is required.

Continuous assembly

The bundle for the current window is always available. You do not wait for an end-of-quarter job; the chain is maintained incrementally. When procurement or an auditor asks for a window, the answer is already waiting.

rolling windows: daily, weekly, monthly, and custom; exported on demand
chain-of-custody pinning: signing-key rotations are recorded as signed events
tamper detection: a missing or resigned receipt breaks verification loudly
dispute states: receipts under dispute carry their dispute history, not a redaction

What an auditor does with it

Download the signed bundle (tar.gz).
Run the included verifier against the manifest; confirm every signature.
Walk the receipts relevant to the compliance question.
If a receipt is under dispute, read the dispute thread.
Attach the bundle hash to the audit report.

For the technical integrity model (how signatures compose, what makes the chain tamper-resistant, how recovery works after a key compromise), see the architecture docs.