Receipts: evidence that survives the system that made it

Almost every record that decides a dispute was written by a party with an interest in the outcome. An audit log is a platform's account of itself. A chargeback file is the merchant's own telemetry. This page is about the alternative: an artifact signed by the human whose intent it records, covering an exact payload, checkable by someone who trusts neither side.

A dispute where both sides agree on the facts and still disagree

Two companies are arguing about a contract. One says it was signed. The other says nobody at their firm ever agreed to it. The matter is worth enough that lawyers are involved, and the e-signature platform is asked for its records.

What comes back is impressive. A certificate of completion listing the signer's email address, the IP address the link was opened from, timestamps to the second for every view and every click, a document hash, and a unique envelope identifier. It looks like exactly the kind of thing that settles an argument.

Read it closely and it settles nothing. Every fact in that certificate is a fact about a mailbox. It establishes that someone with access to a particular email account opened a link and clicked a button. Both parties already agreed on that. The disputed question was whether the human the platform names as the signer was the human who clicked, and the certificate does not speak to it, because the platform was never in a position to know. We wrote about this at length in your e-signature proves someone opened an email, and the response from readers who work in this area was consistent: yes, and we have never thought about it that way.

Once you notice the shape of that problem, you start seeing it in places that have nothing to do with e-signature.

Who wrote the evidence?

Here is the uncomfortable observation that this entire page is built on. In commerce, in compliance, and in security, the record that decides the outcome is almost always written by a party with a stake in the outcome, using a system that party controls.

Go through them one at a time and the pattern is hard to unsee:

• An audit log is a platform's account of its own behaviour, retained under the platform's retention policy, alterable by the platform's administrators, and produced in the platform's format.
• Chargeback evidence is the merchant's telemetry about a transaction the merchant wants to keep. IP address, device fingerprint, session recording, delivery confirmation. Every field is a merchant assertion, which is why issuers weight it the way they do. We took that apart in the customer says they did not buy it.
• An e-signature audit trail is the vendor's log of a click, as above.
• A claim photograph is whatever the claimant uploaded, and generative imagery removed the last reason to treat an image as a proxy for a visit. That is the subject of the photo of the damage is the claim.
• A deploy approval is a row in a continuous integration database, set by a click in a browser session, alterable by whoever administers the repository. See who approved this deploy.
• A visit verification record in home care is an application's record of a phone being at a location, which is not the same as a caregiver being with a patient, as the visit was billed, nobody came sets out.

None of that is fraud, and almost none of it is negligence. These systems were built to help an organisation run itself, and for that purpose a self-authored log is entirely appropriate. The failure is one of repurposing. We took records designed for operations and asked them to serve as evidence in adversarial proceedings, which is a different job with different requirements, and we never changed the artifact to match.

The Identity Failure Map names this failure IFM-13, Evidence Without Provenance: a record whose origin cannot be tied to the human moment it claims to describe. It sits alongside IFM-10, Credential Zombies, where a credential stays cryptographically valid after the status underneath it changed, and IFM-12, Trust Islands, where a verification result cannot leave the institution that produced it. This page is about all three, because they are the same problem seen from three angles, and one artifact addresses all of them.

What is a receipt, and how is it different from a log?

A receipt, in the sense this page uses the word, is a signed statement with four properties. It is produced by the party whose intent it records. It covers a specific canonical payload rather than an event or a session. It can be verified by a third party who trusts neither the signer nor the platform. And it keeps working after the company that generated it is gone.

The analogy worth holding onto is the difference between a shop's till roll and a signed cheque. The till roll is the shop's record of what it says happened, and for running the shop it is perfect. The cheque is different in kind: you wrote it, it names an exact amount and an exact payee, the bank can check your signature against a specimen it already holds, and it stays valid if the shop closes tomorrow. Both are paper. Only one is evidence about you.

Here is what the object actually looks like. This is an escrow release, chosen because it is the case where the stakes are least ambiguous.

{
  "typ": "manav.receipt.v1",
  "act": "escrow.release",
  "payload_sha256": "9f2b6c1d84a0e7f35b2c9d1e6a4f80b3c7e5d219a6f4b8c30d15e29a7c4b6d83",
  "payload": {
    "matter_id":     "M-2026-1184",
    "payee_name":    "Ashgrove Building Ltd",
    "payee_account": "GB29NWBK60161331926819",
    "amount":        "218000.00",
    "currency":      "GBP",
    "effective":     "2026-10-03"
  },
  "signer": { "kid": "hk_7c1a93e5", "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503" },
  "iat": 1791072000,
  "sig": "ed25519:z3Vc9Kq1mR7tXbN4sJhL2wY8pD6fA0uE5gTnQoIvBxSaMzKrWeHdCjUyPl"
}

Read what that object commits to. Not "a release was approved". Not "user 4471 clicked Approve at 14:32". It commits to this matter, this payee, these fourteen digits of account number, this amount, on this date, signed by a key held on a device belonging to a specific enrolled human. Change any character of the payload and the hash no longer matches. Change the payee account and the signature is worthless.

That precision is the entire point. A log entry that says "release approved" is compatible with any payee. A receipt is compatible with exactly one.

The verification walk

Verification is short enough to read in full, which is itself part of the argument. If checking evidence requires trusting a vendor's API, the evidence is only as good as the vendor.

def verify(receipt, published_keys):
    # 1. Recompute the canonical payload hash. The signature covers
    #    these bytes, not whatever JSON you happen to be holding.
    canon = canonicalize(receipt["payload"])        # RFC 8785 style
    if sha256(canon) != receipt["payload_sha256"]:
        return REJECT("payload does not match its hash")

    # 2. Verify against a key fetched from the publisher's own
    #    endpoint. Not from the receipt. Not from Manav.
    key = published_keys.get(receipt["signer"]["kid"])
    if key is None:
        return REJECT("unknown signing key")
    if not ed25519_verify(key, receipt["sig"], signing_input(receipt)):
        return REJECT("signature does not verify")

    # 3. Everything above runs with the network unplugged.
    return ACCEPT(receipt["payload"], receipt["iat"])

Three checks. No callback. No account with us. An auditor, a court appointed expert, an insurer, or the counterparty's own engineer can run this against a key they fetched once and cached, and get the same answer we would give them. That property is not a convenience. It is what makes the artifact evidence rather than an assertion.

Canonicalisation is the part that is easy to get wrong and worth stating plainly, because it is where a careless implementation reintroduces exactly the ambiguity it was trying to remove. If the signer signs one serialisation of the payload and the verifier hashes a different one, with keys reordered or whitespace changed or a number rendered as 218000 rather than 218000.00, the signature fails on identical data. Both sides must compute the same bytes from the same object, deterministically, every time. The JSON Canonicalization Scheme in RFC 8785 exists precisely for this and is the sane default.

The map

Every row below is a place where the deciding record is written by an interested party. The right hand column is where each one is worked through properly.

Twenty one rows, one failure. That is what makes this a category rather than a list of grievances.

Property one: who produced it?

The first question to ask of any piece of evidence is who wrote it, and the honest answer for most institutional records is the party who benefits from what it says.

This is not a claim that organisations routinely falsify logs. It is a claim about what a log can establish even when everyone is honest. If a platform's database says a user approved something, that statement is true if and only if the platform's authentication, its session handling, its authorisation logic, its administrators and its storage all behaved correctly. Every one of those is a place where the record and reality can diverge without anyone lying, and the session theft material elsewhere on this site is a long catalogue of exactly that divergence.

A receipt inverts the authorship. The signature is produced on a device the signing human controls, using a key the platform never holds, over content the human was shown. The platform's role shrinks to transporting and storing an object it cannot forge. That is a smaller role, and a much stronger one from an evidentiary point of view, because the platform's correctness stops being a precondition for the record's truth.

The move this makes in a regulated setting

In life sciences, an electronic signature under the FDA's electronic records rule is typically a username and password re-entered inside a validated system, and the assurance comes from validating the system. That is a coherent design and it has served for decades. What it does not produce is an artifact that means anything outside the validated system, which matters precisely when the system's own access controls are what failed. Part 11 was written in 1997 works through what happens when a model drafts the record and a human applies the signature, and what the meaning field of that signature is then asserting.

The same structural point applies to the certifications that sit at the top of financial reporting. Someone signs to say the numbers are true is deliberately the most modest post in the series, because a signature improves the artifact and does nothing for the quality of the inquiry beneath it, and pretending otherwise would be the sort of overclaim this site exists to argue against.

Property two: what does it cover?

The second question is what the evidence is actually about, and here the gap between a log and a receipt is at its widest.

Logs record events. "Payment approved." "Document signed." "Access granted." An event is a category, and a category is compatible with an unbounded number of specific facts. If the log says a wire was approved, it is equally consistent with the wire that was intended and the wire that was substituted, which is why an attacker who can influence the payload has no need to touch the log at all.

A receipt covers a payload. Not the category of action but the exact content: this beneficiary, this amount, this account, this effective date. The signature is computed over those bytes, so the class of attack where the display and the executed transaction diverge stops being invisible after the fact. It becomes a signature that does not verify.

This is the property that the client trust account is a target turns on. A solicitor's firm holding client money does not need a record that a release was authorised. It needs a record that this release, to this account, for this amount, was authorised by this client, because the fraud consists precisely of substituting the account while everything else stays true.

Why the canonical form matters more than it sounds

Committing to a payload only works if both parties agree what the payload is, byte for byte. Two JSON documents with identical meaning and different key ordering are different byte strings and produce different hashes. A deterministic canonical form is therefore not a detail of the implementation, it is the thing that makes the commitment meaningful at all, and a system that skips it has moved the ambiguity from the payload into the serialiser rather than removing it.

Property three: who can check it?

The third question is the one that separates evidence from an assertion, and it is the one most identity products quietly fail.

If verifying a record requires calling the vendor who produced it, then the record's value is bounded by the vendor's availability, the vendor's willingness to answer, and the vendor's continued existence. It also leaks: every verification tells the issuer where the subject is presenting their credential, which is a surveillance property that the web public key infrastructure fought over for a decade before largely concluding that per query issuer contact was too high a price. Can you verify a credential without phoning the issuer walks through that history, because the certificate revocation argument is the same argument already fought to a conclusion in a different domain.

Offline verification means a verifier who trusts neither party can reach a conclusion using only the artifact and a published key. The auditor does not need an account with us. The court appointed expert does not need our cooperation. The counterparty's engineer can verify our customer's receipt without ever talking to us, which is uncomfortable commercially and correct architecturally, and we would rather be right about it.

The honest counterweight is that offline verification trades revocation freshness for independence. A receipt verified with the network unplugged cannot know that a key was revoked five minutes ago. The engineering question is where to put that dial for a given action's value, and the answers range from short validity windows to aggregate status lists to a live check for the small set of decisions that genuinely warrant one.

Property four: does it survive the issuer?

This is the column almost nobody writes, and it is where the argument wins.

Ask of any evidence you hold: if the company that produced this ceased trading tomorrow, would it still mean anything? For most institutional records the answer is no. An audit log inside a platform dies with the platform. An e-signature certificate of completion is a document about a service that must exist to explain what its fields mean. A rating is a number whose meaning is defined entirely by rules held by a company that can change them or disappear.

Consider how routine that scenario actually is. Companies are acquired and their products sunset. Vendors are replaced at contract renewal. Platforms exit markets. Records are migrated with fidelity that nobody checks until someone needs the record. The half life of the average software vendor is considerably shorter than the retention period of the average regulated document, and shorter still than the period over which a property title, a professional licence or a work history needs to remain checkable.

A receipt survives because verification depends only on the artifact and a published key, and a published key can be archived, mirrored, notarised in a transparency log, or simply written down. The verification code above is short enough that a competent engineer could reimplement it from the specification in an afternoon, in a decade, with the original vendor long gone. That is a deliberate design goal and not an accident.

It is also why we publish the receipt and delegation chain formats as drafts at the IETF and the OpenID Foundation rather than keeping them proprietary. Filed is not ratified, and we say so plainly, but a format that only we can interpret would fail this property by construction, and failing it would make the rest of the argument dishonest.

Why does portability follow from all this?

Portability is usually discussed as a separate topic, a matter of data export and standards adoption. It is better understood as a consequence. Once evidence is held by the human it describes, covers a specific claim, and verifies without contacting the issuer, it can travel by default. The question stops being technical and becomes governance: not can this move, but will the receiving institution accept it.

That reframing is the most useful thing on this page for anyone building in the area, because it redirects effort. Teams spend years on formats when the blocker was always whether a verifier will rely on an attestation from an issuer it did not choose. You verified them in Berlin, now prove it in Singapore makes the case that trust registries, not data models, are the actual bottleneck in cross border identity, and that this is a governance problem wearing a technical costume.

What travels, and what only looks like it travels

A rating does not travel, and this is worth being precise about because it is the most common confusion in the area. A five star average is a summary produced by one platform's rules about who may rate, how disputes resolve, how many ratings display and how old ones decay. Moving the number moves nothing, because the number only has meaning inside the system that computed it. What can travel is the underlying facts: this human completed this many engagements of this type between these dates without a substantiated complaint, signed by the platform that observed it. Your five star rating is not yours develops that distinction, and fifteen years of work, and every new client starts from zero applies it to the case where confidentiality obligations prevent showing the actual work, which is the constraint most writing on portfolios ignores entirely.

Credentials, and the two ways they go wrong

Credentials fail in two distinct ways that are constantly conflated, and separating them is necessary before either can be fixed.

The first is status. A credential is issued once and checked many times, and the fact underneath it can change at any point in between. A licence is suspended, an employment ends, a certification lapses, and the artifact in the holder's possession keeps verifying because verification checks the signature rather than the status. The licence was revoked in March covers the mechanics and lands on the conclusion the certificate world reached before it: the practical answer to revocation is usually shorter lifetimes rather than better revocation.

The second is basis. A credential can be validly issued on a fraudulent foundation, in which case every downstream check succeeds because there is nothing wrong with the credential. The licence is real, the nurse is not works through the federal investigation into fraudulently obtained nursing credentials, where the licences were genuine and the prerequisites were forged, and the degree is real, the university is a mailbox follows the same recursion up into accreditation, where verifying the accreditor requires trusting a recogniser and the chain has to terminate somewhere.

Both are compounded by a third issue that is really about time rather than credentials: records store values without recording their age, so nothing distinguishes a fact verified this morning from one verified in 2019. Every identity record is a photograph of a moving thing proposes freshness as a first class property and argues that both failure directions, acting on stale data and re-verifying unnecessarily, come from the same missing capability. And when two issuers simply disagree, which happens constantly at scale, there is no standard vocabulary for expressing the conflict at all, which is the gap two issuers, two answers, one person names as legitimate standards work.

Where receipts change a specific industry

Money movement and property

The clearest cases are the ones where a payload substitution is the whole attack. In conveyancing, an impersonator does not need to defeat a system, they need to be accepted as the owner by a process that checks documents. Someone sold your land proposes an owner enrolled key registered against a parcel, and is careful to present it as a proposal with real obstacles, since county recording systems are fragmented and enrolment for every parcel owner is not a small ask.

Media and claims

Where the evidence is an image, provenance splits into two questions that are usually merged. What device captured this and what happened to it afterwards is answered well by content provenance work. Which human captured or published it is not, and Content Credentials prove the camera is deliberately respectful about that distinction, because the C2PA work is serious and the gap is narrow and specific rather than a deficiency. In insurance the same split decides whether a claim can be assessed remotely at all, which is why the photo of the damage is the claim argues for binding capture to a human moment rather than judging the pixels afterwards.

Research integrity

Sometimes what is needed is not identity but uniqueness, and the distinction unlocks a better design. A sponsor checking for duplicate trial enrolment does not need to know who a participant is, only that this person is already enrolled elsewhere. Today that is answered by submitting personal data to a shared registry, which creates a database of who participates in which trials, an artifact that would be genuinely dangerous. The same volunteer, three trials, two identities argues that a one way key gives the sponsor the answer without anyone building that registry.

What receipts do not solve

This is a page arguing for an artifact, so the limits belong here rather than in a footnote, and they are substantial.

A receipt proves authorship, not truth. It establishes that a specific human committed to a specific payload at a specific time. It says nothing about whether the payload describes reality. A claimant can photograph a staged scene, an officer can certify statements they never checked, and a surveyor can sign a report they wrote carelessly. Every one of those produces a perfectly valid receipt. Confusing authorship with accuracy is the single most likely way to misuse everything on this page.

Enrolment remains the trust bottleneck. Every signature traces back to a moment when a key was bound to a human, and the assurance of the whole chain is capped by the assurance of that moment. Injection attacks against document and liveness capture are getting cheaper, which is why we treat enrolment as the hard problem rather than a solved preliminary, and why we say plainly that we compose with document verification vendors rather than replacing them.

Adoption is two sided and that is genuinely hard. A receipt is worth something when a verifier will act on it. Until then it is a well formed object nobody asked for. This is the classic cold start, it is worse for credentials than for payments because the issuers with the most valuable attestations have the least incentive to make them portable, and no amount of good design routes around it.

Key rotation and status distribution are the unglamorous hard parts. Publishing a key is easy. Publishing a key, rotating it without invalidating a decade of receipts, distributing status without leaking who is checking, and doing all of that through an acquisition and a migration, is the operational work that decides whether any of this survives contact with a real institution.

Legal weight is a function of law, not cryptography. A stronger signature does not automatically carry more evidentiary weight. Admissibility and reliance are decided by statute, regulation and precedent that vary by jurisdiction and move slowly. The correct claim is that a receipt is better evidence, not that it is legally decisive, and nothing on this page is legal advice.

Receipts can be over collected. An artifact that proves who did what is a surveillance instrument if it is gathered indiscriminately. The discipline is to gate the small number of actions that genuinely warrant it, to scope keys per context so that a receipt in one setting cannot be correlated with a receipt in another, and to leave the artifact in the hands of the human it describes. A system that accumulates receipts about people, centrally, for its own convenience, has rebuilt the thing this whole approach was meant to avoid.

Where the standards sit

Almost everything on this page overlaps with work that predates it, and the honest position is that we interoperate with that work rather than competing with it.

The W3C Verifiable Credentials Data Model is the serious general purpose framing for issuer, holder and verifier, and the accompanying Bitstring Status List addresses revocation with the privacy preserving property that a verifier fetches an aggregate list rather than asking about a specific subject. That is exactly the right instinct and it is the same instinct that drove certificate transparency and short lived certificates in the web public key infrastructure. Our comparison in Manav and W3C Verifiable Credentials sets out where the two fit together.

SD-JWT, in progress at the IETF, gives selective disclosure over JSON claims, which is the mechanism that lets a holder prove one attribute without revealing the rest. We should be clear that selective disclosure and zero knowledge predicates are roadmap for us and not shipped, and that anything on this site describing them describes intent.

ISO/IEC 18013-5, the mobile driving licence standard, is the most instructive deployed example of offline presentation, because it was designed for a roadside stop with no connectivity and had to solve the availability problem honestly rather than assuming a callback. eIDAS 2.0 and the European Digital Identity Wallet put governance behind the same shape at continental scale, and we cover the interaction in eIDAS 2.0 and Manav.

Where our own contribution sits is narrower than any of those. It is an action receipt: a signed commitment to a specific payload by a specific enrolled human at a specific moment, chained where authority was delegated. The chaining model is described in what is an attestation chain, and the accumulated set of receipts a worker holds is the subject of the verified work passport. For teams designing the log side of this rather than the receipt side, audit trail design for AI agents covers tamper evidence and the Merkle structures that make a log at least self consistent, which is a real improvement even though it does not change who authored it.

Reading paths

If you work in a regulated industry

Start with e-signature proves the mailbox for the clearest version of the argument, then Part 11 and who signed the record for the regulated records case, then credential zombies and identity decay for the two ways your reference data goes quietly wrong, and finish with escrow release instructions for what a gated high value action looks like in practice.

If you build platform or marketplace product

Begin with friendly fraud and receipts to see why self authored evidence loses disputes, then portable reputation for why your strongest retention mechanism is also your users' biggest complaint, then freelancer trust portability for what would actually travel, and conflicting attestations for what happens when two of your sources disagree.

If you are an architect or work on standards

Read verify without calling the issuer first, since the certificate revocation history it recounts is the argument already fought to a conclusion, then credential zombies for status models, conflicting attestations for the vocabulary gap worth standardising, and trust across borders for why registries rather than formats are the bottleneck.

If you are a worker or an independent professional

Start with your five star rating is not yours, then every new client starts from zero, then the licence is not the person if you hold a professional credential, and the verified work passport for what accumulating your own evidence looks like.

What to do this week

1. Take your three highest value disputed decisions from the last year and write down, for each, who authored the deciding record. If the answer is your own system, you have found the exposure.
2. For one high value action, write out the exact payload that ought to be committed to. Not the event name, the fields. This exercise usually reveals that nobody agrees what the action's identity is.
3. Check whether any evidence you rely on requires a vendor callback to interpret, and ask what happens to it if that vendor is acquired.
4. Find one credential your organisation trusts and determine how you would learn if its status changed. Measure the lag in days.
5. Ask whether your records store the age of what they assert. Most do not.
6. Pick the smallest number of actions that genuinely warrant a human signature and resist the urge to expand the list. Gating everything is how these programmes die.
7. Read the verification code above and decide whether an outside expert could run the equivalent against your evidence without your help.

If you want to see the artifact rather than read about it, the signing demo produces a real receipt you can verify yourself, and the developer documentation covers the verification path in full.

Frequently asked questions

What is the difference between a receipt and an audit log? An audit log is written by the platform about itself, covers an event category, requires the platform to interpret it, and dies with the platform. A receipt is signed by the human whose intent it records, covers an exact payload, verifies against a published key by anyone, and keeps working after the issuer is gone. They serve different purposes and most organisations only have the first.

Does a receipt prove that what was signed is true? No, and this is the most important limit to understand. A receipt proves that a specific enrolled human committed to specific content at a specific time. Whether that content is accurate is a separate question that no signature can answer. Someone can sign a false statement and produce a perfectly valid receipt.

What does offline verification actually mean? It means a third party can check the artifact using only the receipt itself and a signing key they fetched from a published endpoint at some earlier point. No live call to the issuer, no account with the vendor, no dependency on anyone's availability. The tradeoff is that an offline check cannot know about a revocation that happened moments ago.

How is this different from verifiable credentials? It is not opposed to them. Verifiable Credentials describe a general model for issuer, holder and verifier, and are the right framing for attested attributes. A receipt is narrower: a commitment to one action's payload by one human at one moment. The two compose, and we publish formats openly rather than proprietarily for exactly that reason.

Why does it matter whether evidence survives the issuer? Because retention periods routinely outlast software vendors. Regulated documents are kept for years, property titles and professional histories for decades, and the average vendor relationship is shorter than both. Evidence that requires a live company to interpret it is evidence with an expiry date nobody wrote down.

Is collecting receipts a privacy risk? It can be, if done carelessly. An artifact recording who did what becomes a surveillance instrument when gathered indiscriminately or when a single key is reused across contexts so that activity can be correlated. The discipline is to gate few actions, scope keys per context, and leave the receipt in the hands of the person it describes rather than accumulating a central archive about people.

What stops someone signing under duress or handing over their device? Nothing in this design, and it is important to say so. A signature binds intent as expressed at that moment, not the circumstances that produced it. Coercion, device sharing and collusion are outside what cryptography addresses and belong to process controls, thresholds requiring multiple independent signers, and investigation.

Where should an organisation start? With the single action whose reversal is most expensive. Not the most frequent action and not the easiest to instrument. Programmes that begin by gating everything generate approval fatigue and get switched off, while programmes that begin with one irreversible high value action tend to survive and expand.

Sources

1. W3C, Verifiable Credentials Data Model 2.0: w3.org/TR/vc-data-model-2.0
2. W3C, Bitstring Status List: w3.org/TR/vc-bitstring-status-list
3. IETF, Selective Disclosure for JWTs (SD-JWT), OAuth working group: datatracker.ietf.org/wg/oauth/documents
4. IETF, RFC 8785, JSON Canonicalization Scheme: rfc-editor.org/rfc/rfc8785
5. ISO/IEC 18013-5, Mobile driving licence application: iso.org/standard/69084.html
6. Regulation (EU) 2024/1183 amending eIDAS, European Digital Identity Framework: eur-lex.europa.eu/eli/reg/2024/1183/oj
7. US FDA, 21 CFR Part 11, Electronic Records and Electronic Signatures: ecfr.gov, 21 CFR Part 11
8. US Electronic Signatures in Global and National Commerce Act (ESIGN): govinfo.gov, PLAW-106publ229

Ask one question of any evidence you hold: if the company that produced this disappeared tomorrow, would it still mean anything? For most institutional records the answer is no, and nobody has ever written that down.