Cryptographic Receipts: Methods & Applications

• Cryptographic receipts are compact, cryptographically bound evidence artifacts that attest a completed event while revealing minimal underlying details.
• They are implemented using diverse methods such as hash confirmation tokens, document-specific signatures, and confidential attestation schemes tailored to various use cases.
• Their applications span payments, electronic voting, consent management, cross-chain exchanges, and AI audit evidence, emphasizing both verification and privacy.

Cryptographic receipts are cryptographically bound artifacts that document a completed event—such as a payment, signature, consent decision, workflow execution, cross-chain transfer, or vote recording—while constraining what is revealed about the underlying event. The literature does not present a single canonical primitive. Instead, receipts appear as a contract-bound payment transaction, a one-time certificate bound to a document hash, a machine-readable consent receipt, a hash-based voting confirmation token, a fixed-size signed evidence tuple, a receiver-attested confidential acknowledgment, a hardware-attested compliance record, or a cross-chain acceptance receipt (Gerhardt et al., 2012, Mayr et al., 2022, Pandit et al., 2024, Kao, 21 Nov 2025, Figuera, 2 Jun 2026, Sengupta et al., 20 Nov 2025). Taken together, these works suggest that the common role of a cryptographic receipt is evidentiary: it gives a verifier a compact object, or a compact object plus a public-log reference, that binds an event to identities, policies, ciphertexts, contracts, or ledger state without requiring the full event transcript.

1. Conceptual scope and evidentiary function

The strongest recurring distinction in the literature is between a receipt as an exchange artifact and a record as the maintained evidentiary base. In consent management, ISO/IEC TS 27560 treats a receipt as a machine-readable document with minimal mandatory metadata—specifically a unique identifier and a schema version—whereas a consent record documents what was consented to, by whom, when, how, and with what lifecycle events such as giving or withdrawal (Pandit et al., 2024). In regulated AI workflows, a constant-size evidence structure is explicitly described as a receipt-like artifact: a fixed-field tuple of fixed-length bitstrings cryptographically bound to an event, its inputs and outputs, configuration or policy state, optionally a TEE attestation, and a link into a larger audit structure (Kao, 21 Nov 2025).

Other domains push the same evidentiary idea in different directions. In the pay-to-contract protocol, the contract $x$ and the resulting blockchain payment jointly collapse “bill” and “receipt” into one object, so that the payment transaction itself becomes a timestamped receipt (Gerhardt et al., 2012). In one-time certificates, the certificate functions as a one-document attestation because the document hash is embedded in the CSR and the OTC, and “OTCs can only validate a signature corresponding to the hash contained within” (Mayr et al., 2022). In notarized agent systems, the receipt is neither a client-side trace nor a platform log; it is an external witness statement produced by the receiving service, encrypted to the owner, and published to a transparency log (Figuera, 2 Jun 2026).

A related distinction is between origin evidence and receipt evidence. The blockchain non-repudiation literature stresses that non-repudiation of origin and non-repudiation of receipt are different goals: a signed message or immutable publication can support the former, but not necessarily the latter (Zieglmeier, 2023). This distinction is important because many systems called “receipt” mechanisms actually prove different things: inclusion of a ciphertext, acceptance of a document hash, existence of a ledger entry, or observation of a service call. A plausible implication is that “cryptographic receipt” is best understood as a family resemblance term rather than a single formal object.

2. Cryptographic forms and construction patterns

Across the cited work, receipts are instantiated with markedly different cryptographic structures. One lightweight pattern is a hash confirmation token. In the quantum-secure voting framework, the voter computes

$$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$

and then derives the receipt as

$$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$

The server computes the same digest $H'$ and returns it; matching values confirm that the encrypted submission was received and stored correctly without exposing vote or identity (Mahmoud et al., 3 Oct 2025).

A second pattern is document- or contract-specific binding. In one-time certificates, the signer generates an ephemeral key pair $(sk, pk)$, hashes the document $h = H(m)$, includes the hash in the CSR, obtains an OTC, signs the document, and deletes the private key. The authors state that “the compromise of the private key would be meaningless, as it could only be used to generate the same signature that has already been generated” (Mayr et al., 2022). In pay-to-contract, the customer computes a unique payment address from the merchant public key and contract using the labeled-wallet construction

$s[x] := s + H(x), \qquad a[x] := a \cdot g^{H(x)},$

with

$d_{\text{addr}}(P,x) := \text{Hash160}(P[x]).$

Because the payment output address is contract-derived, the blockchain transaction itself becomes evidence for the specific contract (Gerhardt et al., 2012).

A third pattern is fixed-size signed evidence. The evidence-structure abstraction defines

$$\mathsf{Ev} = \{0,1\}^{\lambda} \times \dots \times \{0,1\}^{\lambda},$$

with $k$ fields $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$0, and produces $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$1 where each field is derived as $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$2 and the tuple is signed (Kao, 21 Nov 2025). This produces a uniform receipt body independent of the size of the underlying event metadata $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$3, after which chaining or Merkle anchoring can supply sequence integrity and external auditability.

A fourth pattern is confidential receiver attestation. In Sello, the receipt is a COSE_Sign1 envelope wrapping an HPKE-encrypted payload,

$$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$4

with protected headers that include the service key identifier, protocol version, token reference, and log URL (Figuera, 2 Jun 2026). Aegon uses a different confidential evidence path on Android: the device signs a compliance receipt with a hardware-backed key, and the broker verifies the attestation chain, boot state, JWS signature, ledger existence of txn_id, content-hash match, and replay status (Baskaran et al., 8 Apr 2026).

These constructions employ different primitives—hashing, signatures, public logs, HPKE, QKD-derived XOR encryption, Merkle trees, content addressing, and hardware attestation—but they converge on the same design objective: make later verification reduce to well-scoped checks over a compact artifact.

3. Voting receipts, voter verifiability, and receipt-freeness

Electronic voting provides the sharpest internal tension in the receipt literature because the system must enable voter verification without creating transferable proof of vote choice. The quantum-secure voting framework uses a verifiable receipt mechanism as a post-cast confirmation token. After QKD with BB84 establishes symmetric keys, the voter encrypts the vote and voter ID with bitwise XOR, sends the ciphertexts to the Election Committee, receives a returned digest $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$5, and compares it to the locally recomputed $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$6. The paper states that “A match confirms that the vote was received by the server and stored correctly, without requiring exposure of the original vote or identity” (Mahmoud et al., 3 Oct 2025). The receipt therefore supports recorded-as-cast verification and tamper detection, but the same paper also states that it does not provide a dedicated cast-as-intended mechanism in the standard sense, and it does not define signatures, commitments, zero-knowledge proofs, receipt encryption, blind signatures, or threshold signatures.

Other voting work treats the very existence of a transferable receipt as a problem. ACE defines a receipt as any information that lets a voter later prove how they voted to a third party, and it claims strong receipt-freeness by ensuring that the public bulletin board contains only tallier-randomized commitments. With Pedersen vector commitments,

$$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$7

the voter never learns the tallier’s blinding factor, so even disclosure of the voter’s private randomness does not link the public record to the private vote under the stated assumption that at least one tallier is honest (Rojjha et al., 20 Apr 2026). Cast-as-intended is enforced through an Audit-or-Cast challenge: in an audit branch the voter checks the re-randomization, whereas in the cast branch the ballot is finalized. The paper bounds undetected cheating by $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$8 with $$E_{\text{vote}} = \text{XOR}(\text{vote}, K_{\text{vote}}), \qquad E_{\text{id}} = \text{XOR}(\text{ID}, K_{\text{id}})$$9 audit rounds.

The remote-voting protocol with paper assurance adopts an intermediate position. It explicitly states that it is “not receipt-free” in the strong sense, but claims “honest-but-remembering Receipt Freeness” or “passively receipt-free” if the client honestly follows the protocol and the coercer sees only the bulletin board, does not collude with the Electoral Commission, and cannot tap the relevant channels (McMurtry et al., 2021). Its core mechanism combines voter-generated secrets $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$0, Pedersen commitments, ElGamal encryption, and the relation

$$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$1

Server-side re-randomisation is central because the voter’s client does not know the randomness used to generate the ciphertexts posted on the web bulletin board.

A different response is to avoid cryptographic receipts in the classic sense. The non-cryptographic end-to-end verifiable scheme based on Software-Free Verification uses a physical receipt on high-security paper, a public bulletin board of randomized $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$2 pairs, decoys, manual arithmetic, and Risk-Limiting Audits rather than cryptographic proof objects (Gat, 23 Mar 2026). The receipt is voter-verifiable and later checkable against the ledger, but its evidentiary force is social, procedural, and paper-anchored rather than cryptographically formalized.

A plausible implication of these voting designs is that “receipt” in election cryptography is bifurcated. In some systems it denotes a verification token that proves inclusion or correct recording; in others it denotes precisely the kind of transferable evidence that must be excluded to preserve coercion resistance.

4. Payments, document signing, consent, and cross-chain exchange

Outside voting, receipts more often serve as durable transaction evidence. The pay-to-contract protocol is exemplary because it eliminates the need for a trusted payment descriptor from the merchant: the customer computes the destination address from the contract and merchant public key, and “funds and receipt are exchanged in a single atomic action” (Gerhardt et al., 2012). The receipt proves that a payment was made, that it went to the merchant identified by $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$3, and that it corresponds to the specific contract $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$4, while remaining valid even if the merchant’s online infrastructure is compromised so long as the merchant’s private key stays offline and safe and the customer’s trusted device remains uncompromised.

One-time certificates implement a narrower but closely related evidentiary model. Each document gets its own ephemeral key pair and certificate; the certificate is bound to a single document hash; the private key is deleted after use; and no revocation mechanism is required at the user certificate level. The paper proposes “unique certificates, that is, irrevocable certificates that use ephemeral keys,” and argues that OTCs replace reusable signing credentials with document-specific proof artifacts (Mayr et al., 2022). This produces a receipt-like attestation for one signing event rather than standing authorization for future documents.

Consent receipts formalize an exchange artifact in a regulatory setting. ISO/IEC TS 27560, as implemented with DPV and JSON-LD, models a receipt as dpv:ConsentReceipt with metadata such as dct:conformsTo, an identifier via dpv:hasIdentifier, and references to records through dpv:hasRecordOfActivity (Pandit et al., 2024). The same work maps consent records and receipts to GDPR demonstrability requirements, notes compatibility with W3C DID and Verifiable Credentials, and states that digital signatures and certificates can establish provenance, authenticity, and non-repudiation. At the same time, it emphasizes that the receipt portion of ISO-27560 is intentionally underspecified beyond minimal metadata, so interoperability depends on profiles and implementer agreement.

Cross-blockchain exchange adds bilateral acknowledgment. InterSnap treats a cross-chain transaction $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$5 and the returned receipt transaction $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$6 as a single set,

$$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$7

and requires receiver-side acknowledgment with endorsements so that the destination network cannot credibly deny acceptance (Sengupta et al., 20 Nov 2025). Source and destination endorsements are archived in encrypted snapshots, uploaded to private IPFS, and identified by a content-addressed CID,

$$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$8

The paper reports that encryption time for archives containing up to 12,000 transactions stays below 0.6 s, that saving encrypted archives to IPFS stays under 1 s, and that the system handled around 900 transactions in a one-hour test with an overall transaction success rate of 99.33% (Sengupta et al., 20 Nov 2025). Here the receipt is not only an acknowledgment but also part of a disaster-recovery and dispute-resolution archive.

5. Audit evidence for regulated AI and machine actions

The most explicit generalization of cryptographic receipts beyond classical transactions appears in AI governance and agent observability. Constant-size evidence structures treat each workflow event as generating a fixed-format evidence item $$H = \text{SHA256}(E_{\text{vote}} \,\|\, E_{\text{id}}).$$9, where the tuple is composed of hashed fields and authenticated by a signature (Kao, 21 Nov 2025). The formal algorithms $H'$0, $H'$1, and $H'$2 provide a receipt body, local consistency verification, and hash-chain anchoring

$H'$3

The stated goals are audit integrity, non-equivocation, binding to events and configurations, and tamper detection, under the assumptions that $H'$4 is collision-resistant and the signature scheme is EUF-CMA secure. The implementation reports single-threaded generation at $H'$5 events/s with 28.4 $H'$6 average latency per event, multi-threaded generation at $H'$7 events/s with 5.7 $H'$8, CPU batch verification at $H'$9 events/s with 6.1 $(sk, pk)$0, and GPU batch verification at $(sk, pk)$1 events/s with 2.5 $(sk, pk)$2 on the reported commodity server configuration (Kao, 21 Nov 2025). The design is informed by industrial experience with regulated AI systems at Codebat Technologies Inc.

Sello shifts the trust boundary for agent logs. Rather than asking the acting agent to log itself, the receiving service signs what it observed, encrypts the receipt to the owner, and publishes it to a witness-cosigned Merkle transparency log (Figuera, 2 Jun 2026). The protocol combines four properties: receiver-side signing, HPKE encryption to an owner public key bound to the authorization token via JWS, publication to a witness-cosigned Merkle log, and owner-side discovery by token reference. The receipt body includes agent-identifier, action-type, action-input-hash, action-output-hash, result-status, timestamp, and optional service-defined fields, with only SHA-256 hashes of inputs and outputs rather than verbatim content. This makes the receipt both witness-generated and confidentiality-preserving.

Aegon applies receipt mechanisms to AI content licensing. The protocol binds JWT-based license tokens to an append-only ledger with a Certificate Transparency-style Merkle tree, tracks provenance events such as content_fetched, content_chunked, chunk_embedded, chunk_retrieved, and content_cited, and adds hardware-attested compliance receipts for Android agents (Baskaran et al., 8 Apr 2026). The Android receipt example includes receipt_id, txn_id, publisher_scope_id, content_hash, licensing constraints, and device-attestation information; the broker verifies the Google hardware attestation chain, security level, verified boot state, JWS signature, ledger existence of txn_id, content-hash match, and replay status. The paper does not present measured results, but it specifies target goals including token validation with cached JWKS at edge of $(sk, pk)$3, token issuance P95 at 100 req/s of $(sk, pk)$4, provenance event overhead of $(sk, pk)$5, StrongBox signing of $(sk, pk)$6, KeyMint signing of $(sk, pk)$7, and receipt size of $(sk, pk)$8 (Baskaran et al., 8 Apr 2026).

This body of work suggests a broadening of the receipt concept from transaction acknowledgment to auditable evidence structures for machine-mediated action. The shift is significant because the receipt issuer is increasingly not the party requesting the action, but the party observing, validating, or mediating it.

6. Security properties, misconceptions, and limitations

The literature repeatedly warns against over-claiming what receipts prove. The clearest negative result is that “appending data to blockchain is not sufficient for non-repudiation of receipt” (Zieglmeier, 2023). The position paper distinguishes non-repudiation of origin from non-repudiation of receipt and argues that public append is not equivalent to provable receipt. For confidential data, the paper identifies a catch-22: plaintext publication violates confidentiality, while encrypted publication leaves the recipient able to deny receiving the decryption key. For non-confidential data, plausible deniability remains because the recipient can claim to have been offline, unsynchronized, or otherwise unavailable. Theorems in the paper state that delivering confidential data via blockchain cannot guarantee non-repudiation of receipt, and that delivering non-confidential data via blockchain cannot guarantee it either.

Voting research surfaces a second major limitation: verifiability and receipt-freeness are distinct, and sometimes competing, goals. The QKD voting receipt supports recorded-as-cast verification but is “not sufficient by itself” to establish cast-as-intended and is not a receipt-free voting scheme; the paper explicitly notes that a verifiable receipt can, in some models, be repurposed for coercion or vote-buying if it becomes transferable evidence (Mahmoud et al., 3 Oct 2025). ACE addresses precisely this issue by removing transferable linkage from the public board and proving receipt-freeness only under the assumption that at least one tallier is honest (Rojjha et al., 20 Apr 2026). The remote-voting protocol with paper assurance acknowledges that it is not receipt-free in the strong sense and only offers a weaker honest-but-remembering notion (McMurtry et al., 2021).

AI and audit systems expose a third class of limits: receipts may be authentic yet incomplete. Sello is explicit about the suppression attack, service collusion, replay, token-reference enumeration, owner key loss, and the adoption-incentive problem (Figuera, 2 Jun 2026). Aegon states that it does not guarantee completeness of provenance logs, does not cryptographically prevent training misuse if a platform lies, and does not eliminate broker trust (Baskaran et al., 8 Apr 2026). The AI evidence-structure paper formalizes tamper detection and non-equivocation, but its guarantees reduce to collision resistance and signature unforgeability for the generic construction (Kao, 21 Nov 2025). InterSnap prevents denial of completed cross-chain exchanges only when a valid receipt exists and the transaction set is complete within the stipulated time limit; otherwise the set is marked incomplete and excluded from future references (Sengupta et al., 20 Nov 2025).

A common misconception is that a receipt must always be either a signed acknowledgment or a public-ledger artifact. The surveyed work shows a wider design space: a receipt may be a digest of ciphertexts, a document-specific certificate, a contract-bound address derivation, a constant-size signed tuple, a physical voter slip, a hardware-attested mobile record, or a receiver-generated confidential envelope. A second misconception is that receipts always establish non-repudiation of receipt. The literature does not support that claim. What a receipt proves depends on who generated it, what was bound into it, whether verification is local or public, whether completeness is guaranteed, and whether the artifact is transferable.