Skip to main content
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 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 (Independent Submission, Informational; AlgoVoi-authored, sole authorship), under the canonicalisation URN:
AlgoVoi’s authored L1 has a second part: the RFC 9421 §2.5 signing-base substrate (rfc9421_proxy_chain_v1, dated in draft-hopley-x402-rfc9421-binding; the key-credential binding vectors 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. 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 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.

​
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). 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 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 — the trust chain and the execution_ref primitive
  • SDK and Control Panel — 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 — run a chain and persist every reference to a tamper-evident journal
  • Agent layer — rules, triggers, and behaviours, each firing a behaviour_ref
  • Connect and Connectors — bind live operations across databases, message buses, HTTP services, and object storage
  • 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 (zero-knowledge reputation, cross-issuer federation, ATB credential verification) and a growing application suite 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. 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.

​
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 (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 (Independent Submission, Informational); proposed as a dedicated normative spec file (specs/canonicalisation.md) in x402#2453 (the live spec PR; replaces closed #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: 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. 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, replacing closed #2436). Authorship: AlgoVoi-authored. First published in response to AURA’s scope-enum question on x402#2332 comment 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)

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, authored by @andysalvo) — 9 vectors × 4 reference impls = 36/36 byte-for-byte.
  • Axis 2 hybrid-PQC receipt cores (x402#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 ([email protected] / [email protected] / 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. 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 Python and @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).
To request listing as a v1 adopter, follow the submission process 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 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, not here. 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 (Independent Submission, Informational, AlgoVoi-authored). The currently-live upstream spec PR is x402#2453 (replaces closed #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).
  • 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/. 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<n> 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. Independent forks of this discipline under the urn:x402:canonicalisation:jcs-rfc8785-v<n> 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 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:

Python: algovoi-substrate

pip install algovoi-substrate. Wraps [email protected] with the discipline rules; exposes canonicalize, action_ref, composite_trust_query_hash, build_compliance_receipt, verify_audit_chain. Apache 2.0.

TypeScript: @algovoi/substrate

npm install @algovoi/substrate. Byte-for-byte parity with the Python sibling. Wraps [email protected] + 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 — 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 so every JSON-aware IDE auto-validates compliance receipts on open: 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:

draft-hopley-x402-compliance-receipt

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.

draft-vauban-x402-stark-receipts-00

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 — 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 for how the discipline pairs with Falcon-1024 / ML-DSA-65 signatures.
  • Canonicalisation discipline v2 (PQC-aware) — 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 — the 53-vector matrix and the standalone corpus.
  • 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 — the reference verifier that consumes the substrate (hosted at verify.algovoi.co.uk + PyPI + npm).
  • The 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 — 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 — the upstream PRs and spec authorship surfaces where the substrate is being referenced.
  • Substrate licensing and attribution — what the Apache-2.0 licence requires of reuse, and how AlgoVoi handles reuse without attribution.
  • 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 — 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 — 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).
  • Vauban Pay third-party panel — Axis 0 substrate view — 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.
  • Verifiable x402 receipts — how the substrate produces a byte-deterministic, offline-verifiable receipt chain for x402 payments.
  • Offline-verifiable agent receipts — the offline-verification property proven across ten independent JCS implementations.
  • No-PII compliance receipts — how the substrate carries a sanctions screening verdict with no wallet address in the canonical bytes.