Self-Verifiable Retention Chain for Payment Receipts
draft-hopley-x402-retention-chain-00

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