Independent Submission C. Hopley Internet-Draft AlgoVoi Intended status: Informational 17 June 2026 Expires: 17 December 2026 Self-Verifiable Retention Chain for Payment Receipts draft-hopley-x402-retention-chain-02 Abstract This document specifies two cryptographic constructions for self-verifiable agentic payment records. The first, the Retention Chain Reference (retention_chain_ref), enables tamper-evident audit chains linking payment receipts without requiring external infrastructure. The second, the Payment Action Lifecycle, defines a content-addressed model for the exactly-once execution of payment actions, including an action reference primitive (action_ref) and a per-state transition hash (transition_hash) with a provable SKIP-on- retry idempotency guarantee. Both constructions use only SHA-256 and the JSON Canonicalization Scheme (JCS, RFC 8785), and are verifiable by any party holding the relevant receipts without contacting the issuer. The constructions satisfy 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 17 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. Payment Action Lifecycle 7.1. Action Reference 7.2. Transition Hash 7.3. Lifecycle States 7.4. Exactly-Once Guarantee (SKIP-on-retry) 7.5. Input Validation Rules 8. Conformance Vectors 8.1. Retention Chain Vectors: Test Inputs 8.2. Retention Chain Vectors: Vector 0 -- Genesis 8.3. Retention Chain Vectors: Vector 1 -- Chain Link 8.4. Retention Chain Vectors: Vector 2 -- Chain Link 8.5. Lifecycle Vectors: Action Reference 8.6. Lifecycle Vectors: State Transitions 8.7. Lifecycle Vectors: SKIP-on-retry Idempotency 8.8. Adversarial Boundary Vectors 9. Regulatory Applicability 9.1. MiCA Article 80 9.2. DORA Article 14 9.3. AMLR Article 56 10. Security Considerations 10.1. Collision Resistance 10.2. Subset Auditability 10.3. Chain Truncation 10.4. Issuer Isolation 10.5. Exactly-Once Security Properties 11. IANA Considerations 12. References 12.1. Normative References 12.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 two constructions that together cover the full lifecycle of a regulated agentic payment: 1. The Retention Chain Reference links receipts into a verifiable audit chain. Any party holding receipts can verify chain integrity without contacting the issuer. 2. The Payment Action Lifecycle assigns a stable, content-addressed identity (action_ref) to each payment action, and a per-state digest (transition_hash) to each lifecycle stage. The construction provides a provable SKIP-on-retry guarantee: a re-presented identical transition request reproduces the prior transition_hash byte-for-byte and cannot constitute a second effect. Both constructions require only: o A SHA-256 implementation (available in every standard library). o A JCS canonicalization implementation (RFC 8785). o The receipts and/or transition records themselves. The constructions are designed for use with x402 payment receipts [X402] but are not limited to that protocol. The preimage schemas use only primitive JSON types (integer and string), making them compatible with any receipt format that can supply the 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. action_ref: A content-addressed identifier for a payment action, computed as the SHA-256 digest of the JCS canonical form of the action's identity preimage (Section 7.1). Encoded as 64 lowercase hexadecimal characters (no "sha256:" prefix). MUST NOT change across any state of the action's lifecycle. transition_hash: A content-addressed digest of a payment action's state at a specific lifecycle stage, computed as the SHA-256 digest of the JCS canonical form of the transition preimage (Section 7.2). Encoded as 64 lowercase hexadecimal characters (no "sha256:" prefix). timestamp_ms: A non-negative integer representing a point in time as milliseconds since the Unix epoch (1970-01-01T00:00:00Z). Implementations MUST NOT represent timestamps as RFC 3339 strings, floating-point values, booleans, or null. 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 8.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. Payment Action Lifecycle This section specifies the content-addressed model for the exactly- once execution of payment actions. It defines two primitives: action_ref (the stable identity of an action across its lifecycle) and transition_hash (the state-specific digest for each lifecycle stage). 7.1. Action Reference An action_ref uniquely identifies a payment action. It is computed as the SHA-256 digest of the JCS canonical form of the following four-field identity preimage: action_type (string, non-empty) agent_id (string, non-empty) scope (string, non-empty) timestamp_ms (integer, non-negative) JCS lexicographic key order: action_type, agent_id, scope, timestamp_ms Pseudocode: identity = { "action_type": action_type, "agent_id": agent_id, "scope": scope, "timestamp_ms": timestamp_ms, } canonical_bytes = JCS(identity) action_ref = hex(SHA256(canonical_bytes)) The action_ref is encoded as 64 lowercase hexadecimal characters with no prefix. Implementations MUST NOT include the "sha256:" prefix used by retention_chain_ref and receipt_hash. The action_ref MUST remain constant across all lifecycle states of the action. It serves as the binding key that connects every transition_hash for a given action. 7.2. Transition Hash A transition_hash records the state of a payment action at a specific lifecycle stage. It is computed as the SHA-256 digest of the JCS canonical form of the following five-field transition preimage: action_ref (string, 64 lowercase hex chars) authority_verified_at_ms (integer, non-negative) revocation_check_at_ms (integer, non-negative) state (string, non-empty) transition_timestamp_ms (integer, non-negative) JCS lexicographic key order: action_ref, authority_verified_at_ms, revocation_check_at_ms, state, transition_timestamp_ms Pseudocode: transition = { "action_ref": action_ref, "authority_verified_at_ms": authority_verified_at_ms, "revocation_check_at_ms": revocation_check_at_ms, "state": state, "transition_timestamp_ms": transition_timestamp_ms, } canonical_bytes = JCS(transition) transition_hash = hex(SHA256(canonical_bytes)) The transition_hash is encoded as 64 lowercase hexadecimal characters with no prefix. 7.3. Lifecycle States Three lifecycle states are defined: PENDING: The action has been initiated and is awaiting settlement. COMMITTED: The action has settled. This is the "once" in exactly-once: a COMMITTED transition_hash is the authoritative proof of settlement. REVERSED: The action has been reversed following a COMMITTED transition. Because the state field is load-bearing in the JCS preimage, each lifecycle state produces a distinct transition_hash even when all other fields are identical. Implementations MUST NOT treat transition_hash values from different states as interchangeable. 7.4. Exactly-Once Guarantee (SKIP-on-retry) The SKIP-on-retry invariant is a consequence of the deterministic JCS+SHA-256 construction: if two calls to the transition_hash computation use identical values for all five preimage fields, they MUST produce identical output. Therefore: a payment processor that re-presents an identical transition request (same action_ref, same state, same timestamps) MUST produce the same transition_hash as the original. The retry is byte-identical to the first attempt; it cannot constitute a second effect. Implementations MUST NOT introduce randomness, a nonce, or a wall-clock re-sampling into the transition preimage. Doing so would break the idempotency guarantee. This guarantee is content-addressed and requires no session state, no idempotency-key registry, and no coordination between retrying parties. Any party holding the original transition_hash can verify a retry by recomputing the hash from the five fields. 7.5. Input Validation Rules Implementations MUST enforce the following constraints before computing any hash defined in this section. A violation MUST cause the computation to be rejected; implementations MUST NOT silently accept or coerce invalid inputs. Timestamp fields (timestamp_ms, transition_timestamp_ms, authority_verified_at_ms, revocation_check_at_ms): o MUST be a non-negative integer JSON value. o MUST NOT be a string (including RFC 3339 date-time strings). o MUST NOT be a floating-point value, a boolean, or null. The action_ref field in a transition preimage: o MUST be exactly 64 characters in length. o MUST consist entirely of lowercase hexadecimal characters ([0-9a-f]). String fields (agent_id, action_type, scope, state): o MUST be non-empty strings. o MUST NOT be null. These constraints are load-bearing: violating any of them alters the JCS canonical form and therefore the computed hash. Accepting an invalid input silently would cause the implementation to compute a hash for a different logical object than intended. 8. Conformance Vectors Implementations MUST produce the hash values in Sections 8.2 through 8.7 for the given inputs. The adversarial vectors in Section 8.8 MUST be rejected as specified. An extended vector set covering multi-issuer isolation, sequence-gap detection, and the full set of adversarial boundaries is published at: https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors 8.1. Retention Chain Vectors: Test Inputs The following receipt_hash values are used across Sections 8.2 through 8.4. 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. 8.2. Retention Chain Vectors: 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 8.3. Retention Chain Vectors: 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 8.4. Retention Chain Vectors: 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.5. Lifecycle Vectors: Action Reference The following fixed identity preimage is used throughout Sections 8.5 through 8.7: agent_id: "agent_alpha" action_type: "payment" scope: "vauban:stark_settlement" timestamp_ms: 1716494400000 JCS canonical form (keys in lexicographic order): {"action_type":"payment","agent_id":"agent_alpha", "scope":"vauban:stark_settlement","timestamp_ms":1716494400000} Expected action_ref (64 lowercase hex, no prefix): 7528529a8be2044488e603b7913efaa4f83620dbcc63010d4a1478cf7e9a473c This action_ref is stable and MUST be reproduced identically for the PENDING, COMMITTED, and REVERSED transition vectors in Section 8.6. 8.6. Lifecycle Vectors: State Transitions All three transition vectors use the action_ref from Section 8.5. Implementations MUST produce distinct transition_hash values for each state. Vector: PENDING action_ref: 7528529a8be2044488e603b7913efaa4f836 20dbcc63010d4a1478cf7e9a473c state: "PENDING" transition_timestamp_ms: 1716494400000 authority_verified_at_ms: 1716494400500 revocation_check_at_ms: 1716494400800 Expected transition_hash: 0957638b64c790292c11d90e9ae15576a6454f37f23a0aade222acf9e2ea18b0 Vector: COMMITTED action_ref: 7528529a8be2044488e603b7913efaa4f836 20dbcc63010d4a1478cf7e9a473c state: "COMMITTED" transition_timestamp_ms: 1716494500000 authority_verified_at_ms: 1716494500300 revocation_check_at_ms: 1716494500500 Expected transition_hash: f49faa7c4f82bd842705374311f5f6af073826539d519d0b65de3263258eac5f Vector: REVERSED action_ref: 7528529a8be2044488e603b7913efaa4f836 20dbcc63010d4a1478cf7e9a473c state: "REVERSED" transition_timestamp_ms: 1716494600000 authority_verified_at_ms: 1716494600300 revocation_check_at_ms: 1716494600500 Expected transition_hash: 681a6026dbbac7555c46282eaf617d3f02560925ed8b44c31e3c854fcfc1f613 8.7. Lifecycle Vectors: SKIP-on-retry Idempotency A re-presented COMMITTED transition with fields identical to the COMMITTED vector in Section 8.6 MUST reproduce the same transition_hash: action_ref: 7528529a8be2044488e603b7913efaa4f836 20dbcc63010d4a1478cf7e9a473c state: "COMMITTED" transition_timestamp_ms: 1716494500000 authority_verified_at_ms: 1716494500300 revocation_check_at_ms: 1716494500500 Expected transition_hash (MUST equal the COMMITTED value above): f49faa7c4f82bd842705374311f5f6af073826539d519d0b65de3263258eac5f An implementation that produces a different value for this input has introduced non-determinism into the transition preimage and MUST be considered non-conformant. 8.8. Adversarial Boundary Vectors The following inputs MUST be rejected by a conformant implementation. For each vector, the reject_reason states the violated constraint from Section 7.5. adv-001 -- RFC 3339 string timestamp transition_timestamp_ms: "2026-06-09T00:00:00Z" (string) reject_reason: timestamp_ms MUST be a non-negative integer; string values are not permitted. adv-002 -- Negative timestamp authority_verified_at_ms: -1 (negative integer) reject_reason: timestamp_ms MUST be non-negative. adv-003 -- Boolean timestamp revocation_check_at_ms: true (boolean) reject_reason: timestamp_ms MUST be an integer; booleans are not permitted. adv-004 -- Malformed action_ref (non-hex characters) action_ref: "gggggggg..." (64 chars, not lowercase hex) reject_reason: action_ref MUST consist entirely of lowercase hexadecimal characters [0-9a-f]. adv-005 -- Short action_ref action_ref: "abcd1234" (8 chars) reject_reason: action_ref MUST be exactly 64 characters. adv-006 -- Empty state state: "" reject_reason: state MUST be a non-empty string. All inputs in the extended adversarial vector set (published at the URL in Section 8) produce byte-identical JCS canonicalization across 8 independent RFC 8785 implementations, confirming that these are reproducible, real inputs that MUST be rejected at the validation layer rather than the canonicalization layer. 9. Regulatory Applicability 9.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 constructions in this document satisfy this requirement: o The retention chain embeds a tamper-evident linkage directly into each receipt (Section 4). Any individual receipt can be verified in isolation (Section 6.1); any contiguous sequence can be verified as a complete audit trail (Section 6.2). o The Payment Action Lifecycle (Section 7) provides a stable, content-addressed identity for each transaction (action_ref) and a verifiable state record for each lifecycle stage (transition_hash), satisfying the reconstruction requirement for the full lifecycle of each transaction. o No issuer infrastructure is required for verification. 9.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 constructions provide: 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. o The exactly-once guarantee (Section 7.4) provides a verifiable record that each operational transaction was executed at most once, supporting ICT incident reconstruction. 9.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. The transition_hash provides an additional integrity primitive: an authority can verify that a COMMITTED transition was not subsequently altered by recomputing the hash from the five fields. 10. Security Considerations 10.1. Collision Resistance The security of both constructions depends on the collision resistance of SHA-256. As of the date of this document, no practical collision attack against SHA-256 is known. Preimage lengths vary with field values but are always well above the threshold at which length-extension attacks become relevant. 10.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. 10.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. 10.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.5. Exactly-Once Security Properties The SKIP-on-retry guarantee (Section 7.4) is a consequence of determinism, not of access control. It provides a verifiable proof that a retry is byte-identical to the original, but it does not prevent an attacker who controls the preimage inputs from constructing a different transition with a different timestamp. The action_ref binding property prevents replay under a different agent identity: an identical state+timestamps tuple under a different action_ref produces a different transition_hash. This means a transition_hash is bound to exactly one action_ref. The input validation rules in Section 7.5 are security-critical. An implementation that accepts an RFC 3339 string as a timestamp will compute a different transition_hash than one that enforces the integer constraint, breaking cross-implementation interoperability and the exactly-once guarantee. 11. IANA Considerations This document has no IANA actions. 12. References 12.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. 12.2. Informative References [VECTORS] Hopley, C., "AlgoVoi JCS Conformance Vectors v0.9.0", chopmob-cloud/algovoi-jcs-conformance-vectors, June 2026, . [X402] x402 Working Group, "x402 HTTP Payment Protocol", Work in Progress, 2026. Author's Address C. Hopley AlgoVoi United Kingdom Email: chopmob@gmail.com