> ## Documentation Index > Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt > Use this file to discover all available pages before exploring further. # JCS Canonicalisation Substrate > AlgoVoi authored JCS RFC 8785 canonicalisation discipline for agentic payment receipts, cross validated byte for byte across ten language implementations. The **AlgoVoi JCS Canonicalisation Substrate** is the RFC 8785 (JCS) canonicalisation discipline for agentic-payment receipts and mandates, published as the IETF Internet-Draft `draft-hopley-x402-canonicalisation-jcs-v1` and cross-validated byte for byte across ten independent language implementations. It guarantees that any verifier recomputes the same hash for the same object, offline and years later, so a retention-obligated audit trail never breaks at re-verification. *Last updated: 3 August 2026.* The agentic-payments ecosystem (x402, AP2, A2A, MPP) depends on **byte-identical canonicalisation** of receipt and mandate objects across independent implementations. If two verifiers serialise the same logical object differently, their hashes diverge, and any retention-obligated audit trail breaks at year-N supervisor re-verification. See [Agentic Payment Receipts](/agentic-payment-receipts) for how this discipline produces verifiable, offline-verifiable compliance receipts across x402, AP2, A2A and MPP. AlgoVoi authors the **canonicalisation discipline** that anchors this property across the ecosystem. The discipline is specified in IETF Internet-Draft [`draft-hopley-x402-canonicalisation-jcs-v1`](https://datatracker.ietf.org/doc/draft-hopley-x402-canonicalisation-jcs-v1/) (Independent Submission, Informational; AlgoVoi-authored, sole authorship), under the canonicalisation URN: ``` urn:x402:canonicalisation:jcs-rfc8785-v1 ``` AlgoVoi's authored L1 has a **second part**: the **RFC 9421 §2.5 signing-base substrate** ([`rfc9421_proxy_chain_v1`](/rfc9421-verifier), dated in `draft-hopley-x402-rfc9421-binding`; the [key-credential binding vectors](/key-credential-binding) pin how a signature maps to an issued agent credential). The same rule covers both — **build L2 layers freely; attribute the L1** you build on (keep the NOTICE, import the substrate by hash). See [Adopt the substrate](#adopt-the-substrate). The URN is registered in **Section 10.1** of the canonicalisation I-D. That Section is the authoritative registration; documents using this discipline are encouraged to cite the URN as a Normative Reference so cross-spec verifiers can resolve the registration unambiguously rather than re-deriving it from RFC 8785 alone. The discipline combines: * **JCS RFC 8785** as the canonicalisation rule * **Substrate Rule 2**: integer-millisecond timestamp encoding (RFC 3339 strings rejected) * **Field-name + array-order + type-validation rules** (Section 4 of the I-D) * **Retention property** (Section 5) supporting MiCA Art. 80, AMLR Art. 56, DORA Art. 14 record-keeping * **In-band `canon_version` pin** (Section 4.6) for year-N self-describing re-verifiability These rules collectively extend RFC 8785 in ways that matter for byte-identical interop: RFC 8785 alone does not specify integer-millisecond timestamps, in-band `canon_version` pinning, or the schema-normalisation rules. The URN identifies the specific discipline as registered, not the underlying RFC. It is **byte-for-byte cross-validated across ten independent JCS implementations in ten programming languages**, including the implementation by the editor of RFC 8785 himself (Anders Rundgren via the Java impl). 1226/1226 cumulative agreements covering 16 distinct vector sets. [Most recent attestation](https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/blob/main/_attestations/2026-07-19-jcs-edge-v1-ten-impl.md) dated 2026-07-19. This page is the developer-facing entry point. The canonical normative specification is the IETF I-D linked above. Receipt-format I-Ds in the AlgoVoi suite (compliance receipt, refund receipt, settlement attestation, cancellation receipt, composite-trust-query) normatively reference the canonicalisation I-D rather than redefining the discipline inline. For a complete record of all IETF I-Ds and published specifications anchoring to this discipline, see the [x402 Document Index](/x402-document-index). ## Adopt the substrate We are all building toward the same thing: an agent economy that actually works, where a payment, a credential, or an audit record means the same thing no matter who issued it. That only happens if the evidence layer underneath is shared. So we are putting ours in the open, for anyone to build on. You do not need to rebuild the canonicalisation, the action references, the receipt chain, or the settlement and cancellation formats from scratch. They are published, versioned, and cross-validated across ten independent implementations in ten languages (see [conformance vector sets](/conformance-vectors)). Take them. The only ask is the one the licence already makes: keep the NOTICE attribution, reference where the substrate came from, and then build whatever you are building on top of it. Your products, your brands, your differentiation, your business. That is what a substrate is for. **Open and free for the community (Apache-2.0):** * The canonicalisation discipline and the full receipt family: admission, settlement, refund, cancellation, composite trust * Action references and the transactional receipt chain * RFC 9421 request signing and verification, with post-quantum signatures (Falcon-1024 / ML-DSA) * The conformance vectors: 45 sets, 374 vectors (corpus `manifest.json` v0.38.0, 2026-07-21); the directly-executed cross-impl matrix covers 16 of those sets across ten independent implementations in ten languages at 1226/1226 byte-for-byte agreements * Reference implementations and standalone verifiers, published to PyPI and npm (listed below) **Build on it with the Keystone toolchain (Apache-2.0):** The [Keystone](/keystone) composes the whole agentic trust chain (identity, authority, policy, decision, execution, verdict) into one recomputable sequence, and the open Keystone tooling is how you build on the substrate. Start with the Control Panel: * [The Keystone](/keystone) -- the trust chain and the `execution_ref` primitive * [SDK and Control Panel](/keystone-sdk) -- the umbrella toolchain (`algovoi-keystone`) plus `algovoi-keystone-control`, the open browser Control Panel for installed bolt-ons: install, run, and verify from one place * [Runtime and journal](/keystone-runtime) -- run a chain and persist every reference to a tamper-evident journal * [Agent layer](/keystone-agent) -- rules, triggers, and behaviours, each firing a `behaviour_ref` * [Connect](/keystone-connect) and [Connectors](/keystone-connectors) -- bind live operations across databases, message buses, HTTP services, and object storage * [Proof](/keystone-proof) -- offline verification against a published key When you need more than the open core, support, warranty, an SLA, or the advanced trust layer, there is a commercial tier built on the same substrate: the enhanced [Substrate 2](/substrate-2) (zero-knowledge reputation, cross-issuer federation, ATB credential verification) and a growing [application suite](https://api.algovoi.co.uk/suite-store) of production apps you can license and run. Same canonical evidence format, fully interoperable. A step up, not a rebuild. ## The five reference implementations The substrate is defined by what these five impls agree on. They are independently authored by four non-overlapping author sets, which is what makes the substrate empirical rather than vendor-claimed. | Language | Impl | Author | Version | Substrate role | | ---------- | ----------------------------------------------------------------------------------------- | ----------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Python | [`rfc8785`](https://pypi.org/project/rfc8785/) | Trail of Bits | `0.1.4` | Reference; original AlgoVoi anchor | | JavaScript | [`canonicalize`](https://www.npmjs.com/package/canonicalize) | erdtman | `3.0.0` | Browser-side conformance anchor | | Go | [`gowebpki/jcs`](https://github.com/gowebpki/jcs) | Web PKI WG | `v1.0.1` | Server-side conformance anchor | | Java | [`cyberphone/json-canonicalization`](https://github.com/cyberphone/json-canonicalization) | Anders Rundgren | (RFC 8785 author's reference) | RFC 8785 author's own implementation | | Rust | [`serde_jcs`](https://crates.io/crates/serde_jcs) | seritalien (Vauban Pay) | `0.2.0` | Third-party Rust impl validated against the AlgoVoi-authored substrate vectors ([validation report, 2026-05-21](https://github.com/x402-foundation/x402/issues/2357#issuecomment-4505674559)) | A vector "validates" only if all five produce **bit-identical canonical bytes** and **bit-identical SHA-256 digests** of those bytes. This original v1 matrix ran 53 vectors × 5 impls = **265 byte-for-byte agreements** across the four anchor sets. The corpus has since expanded to a **ten-implementation** matrix -- **1226/1226 directly-executed agreements** across sixteen vector sets (cumulative through 2026-07-21), within a **45-set / 374-vector** corpus (`manifest.json` v0.38.0, 2026-07-21); see [Conformance vector sets](/conformance-vectors). ### Edge-case conformance (`jcs_edge_v1`) The hardest part of RFC 8785 to get right is the part a naive "sorted keys" serialiser skips. The `jcs_edge_v1` set pins it: U+2028 and U+2029 as literal UTF-8 rather than their backslash-u escapes (section 3.2.4); property names ordered by UTF-16 code units, with a supplementary-plane key so the order differs from code-point ordering (section 3.2.3); and 1.0 versus 1 (section 3.2.2.3), plus the mandatory short escapes and literal solidus and `&` `<` `>`. It is validated byte-for-byte across all ten implementations. The run caught a real divergence in the corpus's own stdlib PHP serialiser, which escaped U+2028 and did not fold 1.0 to 1; the fix is the same serialiser patch as [a2a-go#368](https://github.com/a2aproject/a2a-go/pull/368) (Go's `encoding/json` escapes U+2028 and U+2029 even with `SetEscapeHTML(false)`): emit the canonical bytes directly with only the mandatory escapes. A conformant-looking implementation stayed wrong until an independent vector set measured it, which is the case for anchoring on a corpus rather than a single reference implementation. ## The substrate rules (normative) The five rules that any spec referencing this substrate inherits. AlgoVoi-authored under sole authorship. Filed as IETF Internet-Draft [`draft-hopley-x402-canonicalisation-jcs-v1`](https://datatracker.ietf.org/doc/draft-hopley-x402-canonicalisation-jcs-v1/) (Independent Submission, Informational); proposed as a dedicated normative spec file (`specs/canonicalisation.md`) in [x402#2453](https://github.com/x402-foundation/x402/pull/2453) (the live spec PR; replaces closed [#2436](https://github.com/x402-foundation/x402/pull/2436)). 1. **`JCS_hash = SHA-256(JCS(RFC 8785)(object))`**, lowercase hex. JCS is the only canonicalisation primitive. Variants like `json.dumps(sort_keys=True, separators=(',',':'), ensure_ascii=False)` are close approximations but **not bit-identical** to RFC 8785 (number serialisation §3.2.2.3 and Unicode handling differ); they will produce divergent hashes across implementations. 2. **`timestamp_ms` MUST be epoch-millisecond integer.** RFC 3339 string admits multiple lexically distinct encodings of the same instant (`Z` vs `+00:00`, fractional precision, `.000` vs no-fraction), which under JCS produce different digests. The pin closes that surface. 3. **Field names are load-bearing opaque bytes.** Renaming a field even with equivalent semantics is a canonicalisation-breaking change. The substrate carries a field-name canonicalisation invariant (vectors 007a / 007d / 008a / 008b in `privacy_class_v0.1`). 4. **Type validation BEFORE canonicalisation, reject rather than coerce.** A field declared as `string` that receives an integer is a hard validation failure, not a silent type-cast. Coercion produces non-deterministic canonicalisation surface across implementations. 5. **Retention property is co-equal with cross-observer property.** A spec referencing the substrate MUST include `canon_version` when emitted under a framework-bound retention obligation (MiCA Art. 80 / AMLR Art. 56 / DORA Art. 14). The version pin is what lets a year-5 auditor distinguish "the canonicalisation rules drifted" from "the object content drifted." ## Scope conventions for `action_ref` (non-normative) `action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms}))` is the atomic per-action primitive in the substrate. The `scope` field is typed as a non-empty string with no enum constraint at the canonicalisation layer; the cross-impl matrix validates byte-equivalence of the canonical form across the five reference implementations, not the value-space. A convention is emerging across the substrate's emitter set, documented here as a non-normative recommendation for downstream adopters. ### Today: free-form non-empty string In `algovoi-substrate` (PyPI / npm), `scope` is typed as a non-empty string. Any non-empty string derives a valid `action_ref` and verifies in the audit chain. The substrate does not impose a closed enum. ### Convention emerging across the substrate's emitter set Across the production emitter sets running against the substrate, the following `scope` values are in current use: | `scope` value | Emitter | Receipt surface | | ------------------- | ------------------------------------------------------------------------------------- | ------------------ | | `settlement` | Vauban Pay STARK payment receipts; AlgoVoi `/compliance/attestation` audit chain rows | Settlement layer | | `bilateral` | nobulex bilateral-receipt vectors; CTEF v0.3.1 bilateral framing | Bilateral framing | | `compliance_screen` | AlgoVoi `/compliance/screen` receipts | Admission time | | `agent_os` | Agent OS COMMITTED Claim Engine (8715) initial-onboarding claims | Onboarding | | `payment` | AURA `financial_integrity` reputation dimension | Reputation observe | | `access` | AURA `security_compliance` reputation dimension | Reputation observe | The set is converging by practice rather than by spec text. The AURA dimension mapping (`scope` → reputation dimension) is a clean reputation-consumer projection of the convention; named-column projections of this kind are exactly the downstream composition the substrate was designed to receive. ### Recommended portable form: `{emitter}:{scope}` namespacing As more emitters compose against the substrate, an unprefixed `scope` value risks collision (two emitters using `payment` for genuinely different semantic concepts). The portable form AlgoVoi recommends is `{emitter}:{scope}` namespacing: * `algovoi:compliance_screen` * `vauban:stark_settlement` * `agent_os:committed_claim` * `aura:reputation_observe` The namespaced value is still hashed into `action_ref`, preserving the dedup / idempotency property, and gives reputation consumers and downstream verifiers an unambiguous mapping target. This recommendation is non-normative on values. The substrate-level constraint remains "non-empty string". Closing the value-space at the spec level would lock out future emitters arriving with valid new scopes. The recommendation is also being proposed as a non-normative paragraph in the canonicalisation spec text ([x402#2453](https://github.com/x402-foundation/x402/pull/2453), replacing closed #2436). **Authorship**: AlgoVoi-authored. First published in response to AURA's scope-enum question on [x402#2332 comment 4526409528](https://github.com/x402-foundation/x402/issues/2332#issuecomment-4526409528). Downstream forks and adopter projects are welcome to cite the convention; the canonical home is this page plus the linked spec PR. ## The conformance vectors (v1 original: 5 anchor sets, 53 vectors; current corpus: 45 sets, 374 vectors) Each anchor set is an AlgoVoi-authored gist with: * A `vectors.json` containing structured pair-invariants (`same_hash_as`, `different_hash_from`) so a verifier doesn't just check absolute hash values, it checks the **relational property** the substrate is meant to anchor. * Single-file runners for all 5 reference impls so anyone can reproduce the matrix in their own environment. * An attestation file recording the 265-agreement substrate matrix run dates and the third-party validators who confirmed it. ### Axis 0 substrate sets (5 anchor sets) | Anchor set | Gist | Vectors | Pair invariants | Cross-impl coverage | | ----------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------- | --------------- | ---------------------------------------------- | | AP2 `open_mandate_hash` v0 | [`chopmob-cloud/1dca25fd`](https://gist.github.com/chopmob-cloud/1dca25fd6107db4b7a30bed5dbf2ded8) | 7 | 4 | 5/5 impls | | AP2 PQC v0 (joint with rayc0) | [`chopmob-cloud/c7d2f788`](https://gist.github.com/chopmob-cloud/c7d2f788ff92593a636e642c8a81bbe1) | 1 mandate × 3 sigs (ES256 + Ed25519 + Falcon-1024) | n/a | 5/5 impls (ML-DSA-65 leg pending @rayc0) | | CTEF v0.3.1 + APS v1 receipts | [`chopmob-cloud/5f35eaa5`](https://gist.github.com/chopmob-cloud/5f35eaa527d292bf3ddc52f8725a85c9) | 14 (4 CTEF + 10 APS) | 10 | 5/5 impls (removed from the corpus 2026-06-23) | | `per_chain_envelope` v0 | [`chopmob-cloud/e1bf4c9e`](https://gist.github.com/chopmob-cloud/e1bf4c9efde6f0e94b77c238cb33d78d) | 19 across 7 chain families | 9 | 5/5 impls | | `privacy_class` v0 + v0.1 | [`chopmob-cloud/30bcbc71`](https://gist.github.com/chopmob-cloud/30bcbc717c86493f737feb92c415ba07) | 13 (v0.1 additive over v0's 10) | 12 | 5/5 impls | All five sets are published under Apache 2.0. Provenance: `chopmob-cloud (AlgoVoi)` is the original author of every Axis 0 vector and the substrate-architecture skeleton; specific application-axis vector sets authored by other adopters (`andysalvo` action-ref, `feedoracle` hybrid-PQC) are validated **against** this substrate as cross-validation service runs, not redefined by them. ### Application axis sets (cross-validated, not AlgoVoi-authored) The substrate is the empirical anchor that other adopter-authored application-axis vector sets run against. Validation runs AlgoVoi performed on third-party-authored sets: * **Axis 3 work-binding receipts** ([x402#2398](https://github.com/x402-foundation/x402/pull/2398), authored by @andysalvo) — 9 vectors × 4 reference impls = 36/36 byte-for-byte. * **Axis 2 hybrid-PQC receipt cores** ([x402#2411](https://github.com/x402-foundation/x402/pull/2411), authored by @feedoracle) — 4 receipt cores × 4 reference impls = 16/16 byte-for-byte; pinned-divergent-digest discipline confirmed for both FAIL vectors. ## How to use it If you are implementing a spec that anchors to this substrate, the integration path is: 1. **Pick the closest anchor set.** AP2 mandate-shaped objects → AP2 OMH v0. Chain-native amount or address fields → `per_chain_envelope` v0. Privacy / settlement-visibility attestation → `privacy_class` v0.1. A2A receipt or APS delegation → CTEF + APS v1 (removed from the corpus 2026-06-23). 2. **Run the matrix.** Each gist ships single-file runners. The output is a 53-vector pass/fail table per impl. If your impl produces non-matching digests against the matrix output, your implementation has a canonicalisation drift you need to find before shipping the spec. 3. **Cite the substrate.** Document the canonicalisation rule applied (RFC 8785 + the four pins above) and the anchor set you validated against. The recommended citation form for adopter implementations: > Substrate validation: chopmob-cloud (AlgoVoi) 5-impl JCS reference matrix > (rfc8785\@0.1.4 / canonicalize\@3.0.0 / gowebpki/jcs v1.0.1 / cyberphone/json-canonicalization / serde\_jcs 0.2.0) Documented in the spec text rather than just review comments — gives future readers the replication anchor. 4. **Pin `canon_version`** if your spec is emitted under a framework-bound retention obligation (MiCA / AMLR / DORA). The substrate version-pin is what makes year-5 audit replication possible. ## Substrate adopters Parties anchoring their own services or specifications to v1 (pinning `canon_version: jcs-rfc8785-v1` in publicly-citable artefacts) are recorded in the [Substrate Adopters Registry](/adopters). Inclusion is informational and reflects observed public adoption; absence is not normative. Current v1 adopters: * **AlgoVoi** -- production gateway and reference implementation (`api.algovoi.co.uk`; [`algovoi-substrate`](https://pypi.org/project/algovoi-substrate/) Python and [`@algovoi/substrate`](https://www.npmjs.com/package/@algovoi/substrate) TypeScript packages). * **Supership / Crest Deployment Systems** -- `service_trust_v0` conformance vector set + `urn:crest:trust-check-v1` general-service-trust envelope (`verify.crestsystems.ai`, indexing 47K+ services). * **PEAC Protocol** -- AP2 `open_mandate_hash` v0 fixture set ([peacprotocol/peac](https://github.com/peacprotocol/peac)). To request listing as a v1 adopter, follow the [submission process](/adopters#how-to-submit-an-adoption-entry) in the registry. AlgoVoi validates submissions against the artefact's canonical bytes and adds qualifying entries. The registry is the canonical inclusion record. The IETF Internet-Draft's Appendix C "Known Adopters" section mirrors the registry at I-D revision time. ## Acknowledgments and external contributions The discipline is AlgoVoi-authored under sole authorship, but the byte-for-byte cross-validation that anchors it is empirically possible only because of the independent JCS implementations and conformance work contributed by other parties. AlgoVoi acknowledges with thanks the contributions recorded below. Notably, the validation matrix includes the **RFC 8785 author's own Java implementation** ([`cyberphone/json-canonicalization`](https://github.com/cyberphone/json-canonicalization) by Anders Rundgren and Samuel Erdtman) — the substrate has been validated byte-for-byte by the editor of the canonicalisation standard it pins. The roles below are factual descriptions of what each party did relative to the discipline. They are not discipline co-authorship. The word "adopter" is reserved for parties that anchor their own services to the canon\_version pin; those parties are listed in the [Substrate Adopters Registry](/adopters), not here. | Party | Role | What they did | | ----------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | chopmob-cloud (AlgoVoi) | Discipline author | The five normative rules; the 5 Axis 0 anchor sets; the cross-validation service runs on Axes 1-3 | | seritalien (Vauban Pay) | Validator (independent JCS impl) | `serde_jcs` v0.2.0 confirmed as a fifth byte-equivalent JCS implementation against the AlgoVoi-authored substrate vectors ([public validation report on x402#2357](https://github.com/x402-foundation/x402/issues/2357#issuecomment-4505674559)). Separately, Vauban Pay authored a downstream receipt format ([`draft-vauban-x402-stark-receipts-00`, immutable archive copy](https://www.ietf.org/archive/id/draft-vauban-x402-stark-receipts-00.txt); [current revision on datatracker](https://datatracker.ietf.org/doc/draft-vauban-x402-stark-receipts/)) that anchors to the AlgoVoi canonicalisation discipline (Vauban is the author of the receipt format; AlgoVoi is the author of the canonicalisation discipline the receipt format anchors against). | | seritalien (Vauban Pay) | Mirror host | [x402#2412](https://github.com/x402-foundation/x402/pull/2412) mirrors the 53 AlgoVoi-authored vectors as `fixtures/canonicalisation-substrate/v0/` in the x402 Foundation repo. The vectors are AlgoVoi-authored; Vauban Pay is the host of the in-tree mirror. | | feedoracle (FeedOracle) | Discussion contributor | Suggested the MiCA / AMLR / DORA scoping for the `canon_version` MUST clause during the originating discussion. The clause was refined and incorporated into the discipline by AlgoVoi; FeedOracle is not a co-author of the clause. | | feedoracle (FeedOracle) | Validator (independent vector set) | Independent hybrid-PQC vector set (4 receipt cores × 4 impls = 16/16 byte-for-byte) validated against the AlgoVoi substrate. | | @andysalvo | Validator (independent vector set) | Independent work-binding vector set (9 vectors × 4 impls = 36/36 byte-for-byte) validated against the AlgoVoi substrate. | | arian-gogani (Nobulex) | Validator (independent JCS impl) | Confirmed the five normative rules against an independent JCS implementation; published nobulex bilateral-receipt vectors that anchor to the AlgoVoi `action_ref` derivation. | The discipline itself is sole-AlgoVoi-authored under `urn:x402:canonicalisation:jcs-rfc8785-v1`. The roles above describe what external parties did relative to the discipline; they do not constitute discipline co-authorship in whole or in part. The IETF I-D track is [`draft-hopley-x402-canonicalisation-jcs-v1`](https://datatracker.ietf.org/doc/draft-hopley-x402-canonicalisation-jcs-v1/) (Independent Submission, Informational, AlgoVoi-authored). The currently-live upstream spec PR is [x402#2453](https://github.com/x402-foundation/x402/pull/2453) (replaces closed [#2436](https://github.com/x402-foundation/x402/pull/2436)). ## Provenance and reproducibility Everything on this page is independently reproducible: * **The five impls** are public packages on PyPI / npm / Go module proxy / Maven / crates.io. No AlgoVoi infrastructure required to install any of them. * **The five anchor gists** are publicly hosted at `gist.github.com/chopmob-cloud/`. No login required. Each gist's `vectors.json` is JCS-canonicalised; the gist's content hash anchors the substrate state. * **The matrix runs** are documented in the AlgoVoi memory-graph (`projections/cross_impl_validators.md`) — every run records the date, the runner version, the digest set, and which third-party attested it. The public attestation summary is at the 8-implementation cross-validation record dated 2026-05-24 in the conformance vectors repository ([`_attestations/2026-05-24-8-impl-cross-validation.md`](https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/blob/main/_attestations/2026-05-24-8-impl-cross-validation.md)). * **In-tree cross-impl runners.** The four AlgoVoi-authored single-file JCS runners (Python / JS / Go / Java) plus all 53 vectors and 37 pair invariants are merged in-tree at [`agentgraph-co/agentgraph` `tests/cross-impl/`](https://github.com/agentgraph-co/agentgraph/pull/21). A reviewer can re-run the full matrix from a repo checkout without resolving gist URLs. * **Third-party attestations** on record: @amavashev (Python), @Ectsang (JavaScript), @seritalien (Rust, runner shipped 3.5 hours after the AlgoVoi publication of the `per_chain_envelope_v0` set). The substrate is not vendor-claimed: it is empirically anchored by five impls × four non-overlapping author sets × 53 vectors that all agree byte-for-byte. ## Version governance Successor versions of this canonicalisation discipline (`jcs-rfc8785-v2`, `jcs-rfc8785-v3`, ...) within the `urn:x402:canonicalisation:jcs-rfc8785-v` URN namespace are authored under the same authorship discipline as v1: sole authorship by AlgoVoi, with downstream-adopter acknowledgments recorded in the IETF I-D Appendix C "Known Adopters" section and in the AlgoVoi-maintained [Substrate Adopters Registry](/adopters). Independent forks of this discipline under the `urn:x402:canonicalisation:jcs-rfc8785-v` URN namespace that are not authored by AlgoVoi or its named successors are **not part of the authoritative discipline lineage** for the purposes of this document or any downstream receipt-format specification that normatively references this version's `canon_version`. Such forks SHOULD be published under their own URN namespace (e.g. `urn:vendor-x:canonicalisation:...`) to avoid downstream confusion. Substantive proposals for inclusion in successor versions are welcome via: * IETF Internet-Draft revisions of `draft-hopley-x402-canonicalisation-jcs-v1` * Pull requests against the canonical Mintlify source * Off-list to the AlgoVoi authorship contact Inclusion is at the editorial discretion of the discipline author. Adopter contributions (vector sets, downstream URN extensions, applied-domain profiles) compose under v1 without requiring a discipline-level version bump; the [Substrate Adopters Registry](/adopters) records adopter authorship without conferring discipline-level co-authorship. ## Reference implementations on PyPI and npm The substrate primitives (canonicalisation, `action_ref`, composite trust-query, compliance receipt, audit chain) are published as installable reference implementations in Python and TypeScript: `pip install algovoi-substrate`. Wraps `rfc8785@0.1.4` with the discipline rules; exposes `canonicalize`, `action_ref`, `composite_trust_query_hash`, `build_compliance_receipt`, `verify_audit_chain`. Apache 2.0. `npm install @algovoi/substrate`. Byte-for-byte parity with the Python sibling. Wraps `canonicalize@3.0.0` + `node:crypto`. Apache 2.0. The two packages are byte-for-byte equivalent on identical inputs -- cross-validated by tests that exercise `action_ref`, `sha256_jcs`, `composite_trust_query_hash`, and per-row compliance-receipt hashes across both languages. A standalone conformance corpus is at [`chopmob-cloud/algovoi-jcs-conformance-vectors`](https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors) \-- the canonical citation surface for downstream JCS / x402 / AP2 / A2A implementations to validate against. ## Compliance receipt JSON Schema The compliance receipt shape (the AlgoVoi production schema emitted by `/compliance/screen`) is published as a formal JSON Schema (draft-07) and submitted to [schemastore.org](https://www.schemastore.org/) so every JSON-aware IDE auto-validates compliance receipts on open: * Schema `$id`: `https://json.schemastore.org/algovoi-compliance-receipt-v1.json` * **Merged PR** (2026-05-23): [SchemaStore/schemastore#5726](https://github.com/SchemaStore/schemastore/pull/5726) * Mirror in the corpus: [`schemas/compliance-receipt-v1.schema.json`](https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/blob/main/schemas/compliance-receipt-v1.schema.json) The schema enforces the closed `ALLOW` / `REFER` / `DENY` enum (load-bearing under UK POCA 2002 s.330 for the SAR-obligation distinction), the integer-only `screen_timestamp_ms` (Substrate Rule 1), and the `canon_version` pin to `jcs-rfc8785-v1`. ## IETF Internet-Draft The substrate is anchored on the IETF Independent Submission stream by two companion Internet-Drafts on the IETF datatracker: AlgoVoi-authored. Specifies the admission-time categorical compliance screening receipt format, the canonicalisation discipline, and the long-term audit-chain properties. Submitted 2026-05-23, ISE queue. Vauban Pay-authored. Specifies the settlement-time STARK payment-proof receipt format. Credits AlgoVoi in acknowledgments as contributor of the canonical preimage discipline. Submitted 2026-05-22, ISE queue. The two drafts compose via the substrate's composite trust-query algorithm: an admission-time compliance screening receipt and a settlement-time STARK payment-proof receipt fold into a single `composite_hash` that a downstream verifier can audit in one pass. Both drafts pin the same `urn:x402:canonicalisation:jcs-rfc8785-v1` canonicalisation discipline, including Substrate Rule 2 (epoch-millisecond integer timestamps). ## See also * [Verifiable Compliance Suite](/verifiable-compliance-suite) -- the self-hosted commercial estate built on this substrate: every signed evidence chain in the suite canonicalises with this exact JCS discipline before signing, so the evidence stays offline-verifiable for decades. See also [post-quantum evidence longevity](/post-quantum-evidence-longevity) for how the discipline pairs with Falcon-1024 / ML-DSA-65 signatures. * [Canonicalisation discipline v2 (PQC-aware)](/canonicalisation-substrate-v2) -- the strictly-additive successor version that adds a `signature_algorithm` open-enum registry and a fail-closed verifier discipline for post-quantum migration. v1 (this page) remains valid indefinitely; v2 is opt-in for adopters that need to declare a signature algorithm in-band. * [Conformance vectors](/conformance-vectors) -- the 53-vector matrix and the standalone corpus. * [action\_ref verifier](/action-ref-verifier) -- hosted public endpoint at `verify.algovoi.co.uk/action-ref`: POST any `{agent_id, action_type, scope, timestamp_ms}` payload and get back the JCS canonical form + SHA-256 digest. No installation required. * [Audit verifier](/audit-verifier) -- the reference verifier that consumes the substrate (hosted at verify.algovoi.co.uk + PyPI + npm). * [The Keystone](/keystone) -- the agentic lifecycle and agentic-payment trust chain built on this substrate, byte-verifiable end to end across identity, authority, policy, decision, execution and verdict; closed in `algovoi-substrate` 1.0.0 with `execution_ref` decision-bound execution evidence. * [The Agent Passport](/agent-passport) -- post-quantum trust credentials issued to AI agents and verified offline against this substrate before spend authority is granted, then revocable instantly; the identity anchor of the Keystone trust chain, canonicalised with the same JCS discipline so a credential's bytes recompute decades later. * [Ecosystem contributions](/ecosystem-contributions) -- the upstream PRs and spec authorship surfaces where the substrate is being referenced. * [Substrate licensing and attribution](/substrate-licensing-and-attribution) -- what the Apache-2.0 licence requires of reuse, and how AlgoVoi handles reuse without attribution. * [Compliance](/compliance) -- how the AlgoVoi facilitator integrates the substrate into the retention-obligation framework (UK MLRs / SAMLA Reg 40(3) / FCA 7-year retention). * [x402#2326 originating discussion thread](https://github.com/x402-foundation/x402/issues/2326) -- the issue thread where the discipline was first surfaced; superseded as the canonical citation by the IETF I-D and PR #2453. * [x402#2334 `privacy_class` spec PR](https://github.com/x402-foundation/x402/pull/2334) -- AlgoVoi-authored x402 PR proposing a settlement-visibility attestation that references the substrate by name; closed unmerged 2026-06-02 (see the [authorship-provenance record](/substrate-authorship-provenance)). * [Vauban Pay third-party panel -- Axis 0 substrate view](https://demo.pay.vauban.tech/#axis-0) -- adopter-hosted rendered view of the 53-vector / 5-impl matrix with cross-links back to AlgoVoi's owned surfaces. Companion adopter surface: [Vauban's STARK receipt docs](https://docs.vauban.tech/x402-stark-receipts/). * [Verifiable x402 receipts](/verifiable-x402-receipt) -- how the substrate produces a byte-deterministic, offline-verifiable receipt chain for x402 payments. * [Offline-verifiable agent receipts](/offline-verifiable-receipts) -- the offline-verification property proven across ten independent JCS implementations. * [No-PII compliance receipts](/no-pii-compliance-receipt) -- how the substrate carries a sanctions screening verdict with no wallet address in the canonical bytes.