What signed audit receipts actually prove (and what they don't)

What the signature actually guarantees

A signed receipt under the ChainChoice format provides five specific cryptographic guarantees.

First: the receipt content has not been altered since signing. The signature is computed over a canonical serialisation of the receipt body. Any change to that body — even a single character — invalidates the signature. A reader who fetches the receipt and verifies the signature against the published public key knows that the bytes they received match the bytes that were signed.

Second: the signing party controlled the private key at the time of signing. The signature can only be produced by the holder of the private key corresponding to the published public key. If the published public key is verifiably ChainChoice's (via the JWKS endpoint and the trust anchoring), the signature proves that ChainChoice signed the content.

Third: the receipt ID is content-addressed. Identical inputs produce identical receipt IDs deterministically. Two readers computing the receipt ID independently from the same input data will arrive at the same ID. This makes the receipt referenceable by content rather than by mutable URL.

Fourth: the timestamp is committed. The signed content includes the receipt creation timestamp. A reader knows the receipt was signed at that time — not retroactively created to look older.

Fifth: the input that produced the recommendation is committed. The receipt binds the input data (the question, the user profile, the catalog state hash) to the output (the recommendation). A reader can verify that the recommendation was actually produced from the inputs they see in the receipt.

What the signature does not guarantee

These are equally important, and rarely stated honestly by platforms claiming signed-receipt architecture.

First: the signature does not prove the methodology was correct. The receipt cryptographically commits to the methodology version used. If the methodology itself is flawed — biased weights, incorrect data, sloppy normalisation — the signature does not detect or correct that. A receipt with a bad methodology is still a verifiable receipt of a bad recommendation.

Second: the signature does not prove the input data was accurate. The receipt commits to the input data hash. If the input data (the provider catalog state, the regulatory status determinations, the fee inputs) contained errors at signing time, those errors are signed in. The signature ensures nobody can later alter the input, but does not detect errors that existed at signing.

Third: the signature does not prove the recommendation was useful for the reader. A receipt can be cryptographically perfect and editorially wrong. The signature confirms what was recommended; it does not confirm whether the recommendation served the reader's actual interest.

Fourth: the signature does not prove non-recommendation. The receipt commits to the recommendations made; it does not commit to the recommendations not made. A provider absent from a "top 5" recommendation is not necessarily absent because of failure on the merits — the receipt does not tell you that story.

Fifth: the signature does not prove that the rest of the platform behaves consistently with the receipt. A receipt is a snapshot of one recommendation at one time. The platform's broader behaviour — which providers it features prominently elsewhere, which advertisers it accepts, which content it pushes on other surfaces — is not bound by the receipt.

Why the distinction matters

The honest distinction matters because the marketing of signed-receipt platforms often blurs it. A platform that can truthfully say its recommendations carry a signature has still said nothing about their quality.

The useful framing is: signed receipts are a foundation for editorial integrity, not a substitute for it. They make some claims verifiable that would otherwise be unverifiable. They do not make all claims verifiable, and they specifically do not make the deepest claims — methodology quality, data accuracy, editorial judgment — verifiable from the receipt alone.

A reader evaluating a "signed receipt" platform should ask: yes the receipt is signed, but is the methodology that produced it publicly documented? Are the inputs that fed into it externally verifiable? Are corrections and revisions themselves committed as receipts? Is the wider editorial behaviour consistent with the receipt-based claims?

Without positive answers to those questions, signed receipts are cryptographic theatre. With them, they become a meaningful trust layer.

How ChainChoice handles the distinction

We try to be specific about the boundary, starting with which records are signed. Two are: the Impressum and the affiliate disclosure come with an Ed25519-signed receipt over the SHA-256 of their exact text, and the signature checks against ChainChoice's published keys. Most are not: the receipts printed on country, US-state and comparison pages are hashed, not signed, and /r/<id> rebuilds today's list and compares it with the hash. The published order needs no signature to be checked: every score, with its weights and formula, is in /data/rankings.json and can be recomputed from that file alone.

We also try not to over-claim. A signed legal text proves that the text you read is the text we signed, not that it is right. A hashed page receipt proves that the list you saw is the list the hash names, not that the methodology behind it is sound. That evaluation is the reader's, not ours; we make it as easy as we can by publishing the methodology in full, with versions and a public changelog.