Skip to main content
New to the substrate? Start with Adopt the substrate, the open, Apache-2.0 foundation that is free to build on. This page is the record of who already has. This page is the public registry of parties publishing artefacts under the AlgoVoi-authored canonicalisation discipline urn:x402:canonicalisation:jcs-rfc8785-v1, normatively specified in IETF Internet-Draft draft-hopley-x402-canonicalisation-jcs-v1 (Independent Submission, Informational; AlgoVoi-authored). The registry is maintained by AlgoVoi as a neutral record of observed adoption. Inclusion is informational and reflects public adoption only; it does not imply endorsement or normative authority from the listed party. Absence from the registry is not normative. It records adoption of either L1 substrate — the JCS canonicalisation discipline (urn:x402:canonicalisation:jcs-rfc8785-v1) and the RFC 9421 §2.5 signing-base (rfc9421_proxy_chain_v1, draft-hopley-x402-rfc9421-binding). Building an L2 layer on top is free; what is recorded — and the one ask — is attribution of the L1 you import (keep the NOTICE, import by hash). The registry parallels the Appendix C “Known Adopters” section maintained in the IETF I-D revisions. The registry is the canonical web-accessible record between I-D revisions.

​
Why a public registry

Adoption of a canonicalisation discipline is the load-bearing evidence that the discipline works across independent implementations and use cases. A retained byte-deterministic record of who has adopted, when, and against which canon_version pin is itself audit-grade evidence:
  • For year-N auditability: a verifier reading retained receipts can confirm the adopters that were emitting under the same canonicalisation pin at the time of emission.
  • For ecosystem clarity: downstream parties evaluating whether to adopt benefit from observing existing adopter surfaces and their interoperability records.
  • For authorship attribution: the registry records each adopter’s own authorship of the artefacts they publish, alongside their dependence on the underlying canonicalisation discipline. Authorship of artefacts and authorship of the discipline are separate facts; the registry records both cleanly.

​
Registry

The registry is observed at the time of the most recent revision below. Adopters present at observation but not listed above are invited to submit an entry via the process in the next section.

​
Ecosystem and distribution

Beyond parties that pin the canonicalisation version directly, the substrate is carried in ecosystem and bibliographic datasets. These are recorded here as distribution surfaces, distinct from the discipline adopters above:
  • IETF Relaton (ietf-tools/relaton-data-ids, mirrored at relaton/relaton-data-ids) — the IETF Relaton bibliographic dataset carries metadata records for the draft-hopley-x402-* Internet-Draft family (canonicalisation-jcs, rfc9421-binding, refund-receipt, cancellation-receipt, settlement-attestation, composite-trust-query, retention-chain, payment-evidence-frame, pqc-credential-binding), each with datatracker source links.
  • Electric Capital (electric-capital/open-dev-data) — the Electric Capital open-dev-data ecosystem dataset lists the algovoi-mcp package within its mapped developer ecosystem.

​
Convergent implementations (code users)

Distinct from the adopters above, these projects were created after the 2026-05-24 publication of the canonicalisation discipline and independently implement the same JCS (RFC 8785) plus SHA-256 content-addressed receipt construction. They are recorded here as a convergence signal, not as substrate adopters: each was verified by direct file read to use the construction, but none carries the distinctive tells (integer-millisecond *_at_ms timestamps, integer minor-unit *_minor amounts) or an attribution reference, so derivation from the AlgoVoi substrate is not established. Inclusion records observed use of the construction pattern; it does not imply the project derives from or endorses AlgoVoi, nor the reverse.

​
Adopter authorship principle

Adopters publishing vector sets, receipt-format extensions, or production artefacts under the canonicalisation discipline retain authorship of their own work. The registry records the adoption fact, not co-authorship of the underlying discipline. The discipline itself is AlgoVoi-authored under sole authorship. Substrate authorship history is catalogued at Substrate Authorship and Provenance. This separation is deliberate. An adopter publishing (say) a new vector set anchored to canon_version: jcs-rfc8785-v1 is the author of that vector set; AlgoVoi is the author of the canonicalisation discipline the vector set anchors to. Both facts are recorded; neither displaces the other.

​
Citation discipline

Adopters listed in this registry typically surface the canonicalisation discipline they anchor to in their own public artefacts. The following citation patterns make the substrate-author lineage traceable across downstream surfaces — useful both for year-N audit reconstruction and for ecosystem clarity about which discipline a particular artefact anchors to:
  • In adopter spec text or normative documentation: the URN urn:x402:canonicalisation:jcs-rfc8785-v1 and the IETF Internet-Draft draft-hopley-x402-canonicalisation-jcs-v1 cited as the normative reference.
  • In adopter package READMEs, API docs, or developer-facing surfaces: a link to this registry entry (https://docs.algovoi.co.uk/adopters) alongside the package’s own documentation.
  • In adopter conformance vector sets or reference implementations: the canon_version: jcs-rfc8785-v1 value in-band, byte-stable across the artefact.
Where an adopter publishes derivative or extension artefacts (new URNs under their own namespace, sub-type registries, applied-domain extensions), the underlying canonicalisation discipline is the load-bearing dependency. Citing it at the point where the substrate composition makes the dependency normative preserves the lineage for downstream consumers. The registry records observed adoption regardless of citation completeness. The patterns above describe the typical citation shape; they are not gating conditions for inclusion.

​
Attribution badge

Adopters who want a one-step way to surface the substrate they build on can drop this badge into a README or a docs page. It names the discipline and links back to this registry, so downstream consumers can trace the lineage. Attribution is welcomed, not required (see Citation discipline above). Markdown (for a README):
HTML:
Plain text (for a NOTICE file or a spec acknowledgement):
The badge renders as: Built on the AlgoVoi JCS substrate linking to this page. It uses a static shields.io image (no hosting required on the adopter side).

​
How to submit an adoption entry

To be listed in the registry, an adopter MUST publish at least one artefact that pins canon_version: jcs-rfc8785-v1 in-band, in a publicly-citable surface (GitHub repository, package registry, IETF I-D, hosted public endpoint). Once published, submit via one of the following paths:
  1. Pull request against chopmob-cloud/docs, editing this page (adopters.mdx) to add a row.
  2. GitHub issue at chopmob-cloud/algovoi-jcs-conformance-vectors/issues titled Adopter registry submission: {your-identifier}.
  3. Email to [email protected] with subject Adopter registry submission and the row fields below.
Required fields:
  • Adopter: human-readable name of the publishing party.
  • Identifier: a stable public identifier (DNS name, GitHub handle/org, DID URI, IETF author surname).
  • Surface: what is published (vector set, reference implementation, hosted endpoint, I-D, production service).
  • Anchor: the specific canon_version value pinned by the surface (currently jcs-rfc8785-v1).
  • First observed: ISO-8601 date the surface first published the anchor.
  • Evidence: at least one URL pointing to the publicly-citable artefact.
Submissions are validated by AlgoVoi against the artefact’s canonical bytes. The registry records whatever the artefact emits in-band; in particular, the registry does NOT validate the artefact’s correctness against any vector set or specification, only that it pins the canonicalisation discipline.

​
Withdrawal

An adopter MAY request removal at any time by the same submission paths. Withdrawn entries are not deleted but moved to a “Withdrawn (historical record)” section below to preserve the year-N audit history of the registry itself. The audit-chain of registry edits is recorded in the git history of chopmob-cloud/docs.

​
Withdrawn (historical record)

None at this revision.

​
Machine-readable mirror

A machine-readable JSON-LD mirror of the registry is maintained alongside this page at docs.algovoi.co.uk/adopters.json for automated consumption by composite-trust-query verifiers and downstream tooling.

​
See also