Skip to main content
Every payment receipt in an agentic stack needs to answer one question in a regulatory audit: was this record tampered with, and does it sit in the correct sequence? Today that answer depends on the issuer’s infrastructure being available. If the issuer is offline, acquired, or simply unwilling, the auditor is stuck. The Retention Chain Substrate removes that dependency. Each receipt carries a retention_chain_ref — a single hash computed from four fields the receipt already contains — that lets any party independently verify chain integrity with no network access and no AlgoVoi infrastructure. Specified in IETF Internet-Draft draft-hopley-x402-retention-chain-00, sole AlgoVoi authorship. Cross-validated byte-for-byte across 8 implementations in 8 programming languages.
Commercial add-on. Available under the AlgoVoi Retention Chain commercial licence. Included as standard in every Substrate 2 licence. Contact chopmob@gmail.com to license the add-on standalone.

​
How it works

The chain reference is computed as: 
retention_chain_ref = "sha256:" + SHA-256(JCS(preimage))
The preimage is a four-field JSON object, JCS-canonicalised (RFC 8785) so the key order is deterministic across all implementations: 
{
  "chain_seq":         0,
  "issuer_id":         "acme:payments",
  "prev_receipt_hash": "",
  "receipt_hash":      "sha256:24c3e22bc6ece631..."
}
Fields in JCS lexicographic order: chain_seq, issuer_id, prev_receipt_hash, receipt_hash. The genesis receipt has chain_seq = 0 and prev_receipt_hash = "". Every subsequent receipt increments chain_seq by 1 and sets prev_receipt_hash to the receipt_hash of the receipt immediately before it — not the previous chain ref, the previous receipt hash. This means an auditor with any subset of receipts can recompute and verify each link independently.

​
What an auditor can verify

Auditor holdsWhat they can check
A single receiptThat the retention_chain_ref is internally consistent
A contiguous rangeThat no receipt was inserted, deleted, or reordered
A non-contiguous subsetThat each held receipt is individually intact
All receipts, chain_seq 0 to NComplete chain audit from genesis
No issuer call. No registry lookup. No AlgoVoi service. SHA-256 and a JSON parser is the entire dependency.

​
Regulatory mapping

ObligationArticleHow the chain ref satisfies it
Transaction record integrityMiCA Art. 80Any receipt can be re-verified years later from locally held data; no issuer callback required
ICT audit trailDORA Art. 14chain_seq enforces ordering; hash linkage makes deletion detectable by any receipt-adjacent party
AML record retentionAMLR Art. 56A competent authority holding receipts can verify integrity without requesting further data from the obliged entity

​
Cross-language conformance

The algorithm is specified at the byte level in the I-D and cross-validated across 8 independent implementations. Every implementation must produce identical retention_chain_ref values for the same inputs.
LanguageConformance status
Python22/22 tests pass
TypeScript22/22 tests pass
Go3/3 vectors verified
Ruby3/3 vectors verified
Rust3/3 vectors verified
C# (.NET)3/3 vectors verified
Java3/3 vectors verified
KotlinVectors specified; runnable in any JVM/Gradle environment
Conformance vectors are published in the I-D (Section 7) and in the package distribution. An implementer in any language can verify against the three canonical test cases independently.

​
Conformance vectors (summary)

The three published vectors use issuer_id = "algovoi:test" and receipt hashes derived from known byte inputs.
#chain_seqExpected chain_ref
00 (genesis)sha256:f15a1dcd03cc039204dff24619ff4815ad041ad8796b94f59d52252043d0d08f
11sha256:7114dc39543710bf26d0a5825acddd915ffd51fb5b14503024f70fda403053d9
22sha256:d3bddca79477e6003cb6ef199897bffed185f5d785b4e7333f9b0585b2b81144
Full preimage inputs and JCS canonical forms are in the I-D, Section 7.

​
Relationship to the open substrate

The Retention Chain Substrate sits directly on top of the open JCS Canonicalisation Substrate. It uses the same RFC 8785 JCS canonicalization and SHA-256 primitives that the open substrate defines — no additional cryptographic dependencies. 
Retention Chain Substrate      commercial add-on (this page)
        |
        v
JCS + SHA-256 primitives       open substrate (Apache-2.0)
        |
        v
RFC 8785 (JCS)                 IETF standard
If you already use the open substrate, adding the Retention Chain requires no new cryptographic infrastructure — only the implementation library and the retention_chain_ref field in your receipts.

​
Substrate 2

The Retention Chain Substrate is included as standard in every Substrate 2 licence. Substrate 2 customers receive all 8-language implementations, the full verification library, and the regulatory compliance documentation at no additional cost. If you are licensing Substrate 2, the Retention Chain add-on is already included.

​
Specification

The normative specification is IETF Internet-Draft draft-hopley-x402-retention-chain-00 (AlgoVoi, sole authorship, 16 June 2026). The I-D defines:
  • The exact preimage schema and field constraints
  • The JCS canonicalization requirement (RFC 8785 normative reference)
  • Chain construction rules (genesis condition, link ordering)
  • Single-link and sequence verification procedures
  • The three conformance vectors with exact canonical byte sequences
  • Regulatory applicability analysis (MiCA Art. 80, DORA Art. 14, AMLR Art. 56)
  • Security considerations (collision resistance, subset auditability, truncation, issuer isolation)