Anatomy of a signed receipt

Every claim Attest makes reduces to objects like this one. Pick any of the 447 real receipts the demo deployment issued — the annotations are per-field, the chain links are real prev_hash edges, and the verify → button runs the receipt through the same browser verifier the packs use. Nothing here is a mockup.

receipt

This page needs JavaScript — it fetches the 447 signed receipts and rebuilds canonical payloads locally. Any one verifies offline with attest verify demo-receipts/<receipt-id>.json or browse the receipts index.

receipt

field	value	what it does / what it never does

What the signature actually covers

The Ed25519 signature signs only the payload's SHA-256. The payload is canonicalized first — sorted keys, no whitespace, each literal's exact spelling preserved — which is why two implementations produce the same bytes to sign. Below is the canonical payload of the receipt above, rebuilt in your browser from the served file's raw bytes — and the hash recomputed live:

The honest boundary. A valid signature proves these bytes existed under this issuer key at signing time. It does not prove the camera saw a person, that the worker was present, that the household told the truth, or that the log you saw is the only log — the transparency log and witness cosignatures exist to cover those gaps, and even they can't prove physical presence. Records, not verdicts.

Payload fields mirror the envelope deliberately: the signature binds the payload; the envelope columns must agree, and any divergence is an integrity failure, not a reinterpretation. The journal_head field inside some payloads pins the mutation journal's tip at issuance — a truncated tail is caught too.

Elsewhere: landing · two-minute tour · all 447 receipts as the chain · adversarial corpus · the verifier