Independent Submission A. Hopley Internet-Draft AlgoVoi Intended status: Informational 16 June 2026 Expires: 16 December 2026 Self-Verifiable Retention Chain for Payment Receipts draft-hopley-x402-retention-chain-00 Abstract This document specifies a cryptographic construction, the Retention Chain Reference (retention_chain_ref), that enables self-verifiable audit chains linking payment receipts without requiring external infrastructure. Each receipt in a sequence carries a chain reference computed as the SHA-256 digest of the JSON Canonicalization Scheme (JCS, RFC 8785) canonical form of a fixed four-field preimage. Any party holding any contiguous or non-contiguous subset of receipts can independently verify chain integrity by recomputing the reference from locally held data. No AlgoVoi infrastructure, no registry lookup, and no network access are required. The construction satisfies the transaction recording and audit trail obligations of MiCA Article 80, DORA Article 14, and AMLR Article 56. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Terminology 3. Preimage Schema 4. Chain Reference Computation 4.1. JCS Canonicalization 4.2. SHA-256 Digest 4.3. Output Encoding 5. Chain Construction Rules 5.1. Genesis Record 5.2. Subsequent Records 6. Verification Procedure 6.1. Single-Link Verification 6.2. Sequence Verification 7. Conformance Vectors 7.1. Test Inputs 7.2. Vector 0 -- Genesis 7.3. Vector 1 -- Chain Link 7.4. Vector 2 -- Chain Link 8. Regulatory Applicability 8.1. MiCA Article 80 8.2. DORA Article 14 8.3. AMLR Article 56 9. Security Considerations 9.1. Collision Resistance 9.2. Subset Auditability 9.3. Chain Truncation 9.4. Issuer Isolation 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Author's Address 1. Introduction Agentic payment systems that operate under MiCA, DORA, or AMLR are required to maintain tamper-evident records of every payment transaction and to make those records available for regulatory audit on demand. Existing approaches rely on centralised audit logs, which introduce availability risk and require auditors to trust the operator's infrastructure. This document specifies a construction that embeds audit-chain integrity directly into each payment receipt. The construction requires only: o A SHA-256 implementation (available in every standard library). o A JCS canonicalization implementation (RFC 8785). o The receipts themselves (no external data source). Because the chain reference is computed entirely from fields present in the receipt, any party holding a set of receipts -- including a regulator, an auditor, or a counterparty -- can verify chain integrity without contacting the issuer. This property is termed client-sovereign auditability. The construction is designed for use with x402 payment receipts [X402] but is not limited to that protocol. The preimage schema uses only primitive JSON types (integer and string), making it compatible with any receipt format that can supply the four required fields. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. chain_seq: A non-negative integer identifying the position of a receipt in an issuer's sequence. The genesis receipt has chain_seq = 0. Each subsequent receipt increments chain_seq by 1. issuer_id: A non-empty string uniquely identifying the receipt issuer within the deployment. Issuers SHOULD use URN or DID syntax. receipt_hash: The SHA-256 digest of a payment receipt, encoded as the string "sha256:" followed by 64 lowercase hexadecimal characters. prev_receipt_hash: The receipt_hash of the immediately preceding receipt in the issuer's chain. MUST be the empty string "" for the genesis record (chain_seq = 0). retention_chain_ref: The output of the chain reference computation defined in Section 4. Encoded as the string "sha256:" followed by 64 lowercase hexadecimal characters. JCS: JSON Canonicalization Scheme as defined in RFC 8785. 3. Preimage Schema The preimage is a JSON object with exactly four fields. When serialised using JCS (Section 4.1), the fields appear in the following lexicographic order: chain_seq (integer, non-negative) issuer_id (string, non-empty) prev_receipt_hash (string, "sha256:<64-hex>" or "") receipt_hash (string, "sha256:<64-hex>") Implementations MUST NOT include additional fields in the preimage. Implementations MUST NOT omit any of the four fields. Field constraints: o chain_seq MUST be a non-negative integer. Floating-point representations are not permitted. o issuer_id MUST be a non-empty string. o prev_receipt_hash MUST be "" when chain_seq = 0, and MUST be a valid receipt_hash string (as defined above) when chain_seq > 0. o receipt_hash MUST match the pattern "sha256:[0-9a-f]{64}". Uppercase hexadecimal characters are not permitted. 4. Chain Reference Computation 4.1. JCS Canonicalization The preimage object MUST be serialised using the JSON Canonicalization Scheme [RFC8785]. JCS produces a deterministic byte sequence by: o Sorting object keys lexicographically by Unicode code point. o Serialising numbers without insignificant leading zeros or trailing decimals. o Encoding strings using minimum-length Unicode escape sequences. o Omitting all insignificant whitespace. For the four-field preimage defined in Section 3, the keys in lexicographic order are: chain_seq, issuer_id, prev_receipt_hash, receipt_hash Example canonical form for the genesis vector (Section 7.2): {"chain_seq":0,"issuer_id":"algovoi:test", "prev_receipt_hash":"","receipt_hash":"sha256:24c3e22bc6ece631 e4524e3beeb904553fbb1cd6fd124e1cb3c68a9a277ba23a"} (Line breaks above are for readability only; the actual canonical form contains no whitespace between tokens.) 4.2. SHA-256 Digest The SHA-256 digest [FIPS180-4] MUST be computed over the UTF-8 encoding of the JCS canonical byte sequence produced in Section 4.1. The result is a 32-byte (256-bit) digest. 4.3. Output Encoding The retention_chain_ref is the string formed by concatenating the literal prefix "sha256:" with the lowercase hexadecimal encoding of the 32-byte SHA-256 digest. The result is always exactly 71 characters: 7 prefix characters followed by 64 hexadecimal characters. Pseudocode: preimage = { "chain_seq": chain_seq, "issuer_id": issuer_id, "prev_receipt_hash": prev_receipt_hash, "receipt_hash": receipt_hash, } canonical_bytes = JCS(preimage) digest = SHA256(canonical_bytes) retention_chain_ref = "sha256:" + hex(digest) 5. Chain Construction Rules 5.1. Genesis Record The first receipt in an issuer's chain MUST satisfy: o chain_seq = 0 o prev_receipt_hash = "" Implementations MUST reject a genesis record whose prev_receipt_hash is non-empty. 5.2. Subsequent Records Each subsequent receipt MUST satisfy: o chain_seq = (previous chain_seq) + 1 o prev_receipt_hash = receipt_hash of the immediately preceding receipt (NOT the preceding retention_chain_ref) The chain links via receipt_hash values, not via retention_chain_ref values. This design allows an auditor who holds a receipt but not its chain reference to reconstruct chain linkage from the receipts alone. 6. Verification Procedure 6.1. Single-Link Verification To verify a single retention_chain_ref: 1. Extract chain_seq, issuer_id, prev_receipt_hash, and receipt_hash from the receipt under examination. 2. Check field constraints as defined in Section 3. Fail if any constraint is violated. 3. Compute retention_chain_ref as defined in Section 4. 4. Compare the computed value to the retention_chain_ref stored in or alongside the receipt. 5. The link is valid if and only if the values are identical. 6.2. Sequence Verification To verify a contiguous sequence of N receipts R[0], R[1], ..., R[N-1]: 1. Verify R[0] as a single link per Section 6.1. 2. For each i in 1..N-1: a. Verify R[i] as a single link per Section 6.1. b. Check that R[i].chain_seq = R[i-1].chain_seq + 1. c. Check that R[i].prev_receipt_hash = R[i-1].receipt_hash. 3. The sequence is valid if and only if all per-link verifications pass and all adjacency checks pass. An auditor holding a non-contiguous subset of receipts MAY verify each individual link independently. The subset does not constitute a complete chain audit but does demonstrate that each held receipt is internally consistent. 7. Conformance Vectors Implementations MUST produce the retention_chain_ref values in Sections 7.2 through 7.4 for the given inputs. These vectors are sufficient to detect incorrect key ordering, incorrect hash prefixing, and endianness errors. 7.1. Test Inputs The following receipt_hash values are used across all three vectors. Each is the SHA-256 digest of the UTF-8 encoding of the literal string shown: receipt_0: SHA-256("receipt_0") = sha256:24c3e22bc6ece631e4524e3beeb904553fbb1cd6fd124e1cb3c6 8a9a277ba23a receipt_1: SHA-256("receipt_1") = sha256:55d4a60cbf6928423fd1cd0e06f7cccd98011e9064240a3fd24f 7c6bbae8266a receipt_2: SHA-256("receipt_2") = sha256:08a132f9262230f24640a591c60a08e756d313dbf15ff578b4c1 0fdd30120a4a issuer_id = "algovoi:test" for all three vectors. 7.2. Vector 0 -- Genesis Input: chain_seq: 0 issuer_id: "algovoi:test" prev_receipt_hash: "" receipt_hash: sha256:24c3e22bc6ece631e4524e3beeb904553fbb1 cd6fd124e1cb3c68a9a277ba23a JCS canonical form (UTF-8, no whitespace): {"chain_seq":0,"issuer_id":"algovoi:test","prev_receipt_hash": "","receipt_hash":"sha256:24c3e22bc6ece631e4524e3beeb904553fbb1 cd6fd124e1cb3c68a9a277ba23a"} Expected retention_chain_ref: sha256:f15a1dcd03cc039204dff24619ff4815ad041ad8796b94f59d5225 2043d0d08f 7.3. Vector 1 -- Chain Link Input: chain_seq: 1 issuer_id: "algovoi:test" prev_receipt_hash: sha256:24c3e22bc6ece631e4524e3beeb904553fbb1 cd6fd124e1cb3c68a9a277ba23a receipt_hash: sha256:55d4a60cbf6928423fd1cd0e06f7cccd98011 e9064240a3fd24f7c6bbae8266a Expected retention_chain_ref: sha256:7114dc39543710bf26d0a5825acddd915ffd51fb5b14503024f70f da403053d9 7.4. Vector 2 -- Chain Link Input: chain_seq: 2 issuer_id: "algovoi:test" prev_receipt_hash: sha256:55d4a60cbf6928423fd1cd0e06f7cccd98011 e9064240a3fd24f7c6bbae8266a receipt_hash: sha256:08a132f9262230f24640a591c60a08e756d31 3dbf15ff578b4c10fdd30120a4a Expected retention_chain_ref: sha256:d3bddca79477e6003cb6ef199897bffed185f5d785b4e7333f9b05 85b2b81144 8. Regulatory Applicability 8.1. MiCA Article 80 MiCA Article 80 requires crypto-asset service providers to maintain records of all transactions in a manner that permits reconstruction of each transaction. The retention chain construction satisfies this requirement by embedding a tamper-evident linkage directly into each receipt such that: o Any individual receipt can be verified in isolation (single-link verification, Section 6.1). o Any contiguous sequence can be verified as a complete audit trail (sequence verification, Section 6.2). o No issuer infrastructure is required for verification. 8.2. DORA Article 14 DORA Article 14 requires financial entities to maintain audit logs of ICT-related incidents and operational transactions with integrity guarantees. The retention chain provides: o Cryptographic ordering (chain_seq) that prevents receipt insertion or reordering without detection. o Hash linkage that makes deletion of any receipt in a sequence detectable by the holder of adjacent receipts. o Issuer isolation (issuer_id field) that partitions chains by operational entity. 8.3. AMLR Article 56 AMLR Article 56 requires obliged entities to retain records of financial transactions for a period of at least five years and to ensure those records are available to competent authorities. The retention chain satisfies the integrity dimension of this requirement: a competent authority holding a set of receipts can verify their integrity without requesting further data from the obliged entity, reducing audit friction and eliminating the possibility of post-hoc record manipulation by the issuer. 9. Security Considerations 9.1. Collision Resistance The security of the construction depends on the collision resistance of SHA-256. As of the date of this document, no practical collision attack against SHA-256 is known. The preimage length varies with issuer_id and hash field lengths, and is always at least 100 bytes, making length-extension attacks irrelevant. 9.2. Subset Auditability An auditor holding only a non-contiguous subset of receipts can verify each held link individually but cannot detect gaps in the sequence. To detect gaps, the auditor MUST obtain a complete contiguous range and apply sequence verification (Section 6.2). Issuers SHOULD provide receipts in complete contiguous sequences to auditors. 9.3. Chain Truncation An issuer could present a chain that begins at chain_seq > 0 and claim it is complete. Auditors SHOULD verify that the chain begins with a genesis record (chain_seq = 0, prev_receipt_hash = "") unless they have independent evidence of the chain's starting point. 9.4. Issuer Isolation The issuer_id field is included in the preimage to prevent cross- issuer chain forgery: a receipt from issuer A with a given receipt_hash cannot be substituted for a receipt from issuer B with the same receipt_hash. Issuers MUST use distinct, non-guessable issuer_id values within any deployment. 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020. 11.2. Informative References [X402] x402 Working Group, "x402 HTTP Payment Protocol", Work in Progress, 2026. Author's Address A. Hopley AlgoVoi Email: chopmob@gmail.com