Compatibility matrix

What this SDK is tested against, and what it therefore claims. Nothing is listed on the strength of “it should work” — but not everything is checked by CI on every push, and the table under What CI runs, and what it cannot says exactly which rows run only in the nightly LocalNet workflow.

Version 0.3.2, released 2026-10-23 (the review fixes over 0.3.1: contract keys under hashing scheme V3, point reads, transport-neutral update types).

Rust

The MSRV is workspace.package.rust-version. Raising it is a minor version bump, not a patch.

Platform

The whole test suite runs on all three. The live suites need a Canton participant; CI runs them against LocalNet in the LocalNet workflow, nightly and on demand — see below.

Canton and the Ledger API

Moving the supported Canton range re-vendors the protos in a new SDK minor. See the stability policy in canton-proto and ADR-0002.

Daml-LF

An LF 1 archive carries minors like 15, so judging it by the minor gate would report “Daml-LF 2.15 is unsupported” and send a reader to upgrade an SDK that will never read it. The major is checked first for that reason.

The decoder is held to the official JVM reader by a conformance oracle — the lf-conformance CI job.

Token standard

V2 reuses splice-api-token-metadata-v1; there is no metadata-v2.

Which standard each crate targets, crate by crate:

Verified against live registries — the Splice scan of a cn-quickstart LocalNet (Splice 0.6.11), the Scan of a Canton Builder Tool LocalNet (the three-participant settlement), and the public Scan of the Canton Network DevNet (Splice 0.8.1). The instrument on both is Amulet (Canton Coin), which declares both standards (splice-api-token-transfer-instruction-v1 and -v2). That is a V2 implementation, exercised as one. The registry’s OpenAPI documents at 0.8.1 differ from the vendored 0.6.11 copies by one additive field, which the client already reads.

On the “V2 reference token”. Splice documented a separate Token Standard V2 DevNet — a temporary, single-SV network run by Digital Asset for organizations validating the V2 standard, with a public scan and a weekly Monday reset. It appears to have been wound down: the document’s version line was bumped weekly through 23 June 2026 and has not moved since, and the network’s hostnames are absent from the certificate its address now presents (a valid certificate covering the ordinary DevNet names and no token-std-v2-dev name at all — a retired ingress rather than an IP allowlist, which would answer 403 over a good handshake). V2 has meanwhile landed in the ordinary stack, which is why a plain LocalNet’s Amulet declares every V2 API. So the runs below are against a V2 implementation on a normal network, which is the target that exists.

The runs are kept verbatim, with their environment and commands, in docs/verification/token-standard-live-runs.md; the DevNet update ids were read back from the participant by id after the run.

The allocation is the half that needs more than two parties: the sender reserves holdings for a settlement a third party — the executor — completes later, which is what delivery-versus-payment is built from. On the LocalNet the three roles are three parties on three participants, each submitting with its own participant’s token, and the executor settled both sides of the leg as one batch (the run of 2026-10-13); on DevNet, where one token was held, the settlement was run with the sender as executor and both sides of the leg in one allocation, after the settlement factory had refused a one-sided leg. Both are on record.

Each run resolved the factory against the registry and submitted with the contracts it named for disclosure, so the choice-context and createdEventBlob → DisclosedContract path are proven against a real registry rather than a stub.

The stub has its place too, and CI runs it: every workflow function in canton-token — V1 and V2 transfer, the instruction choices, allocation, settle_batch, the allocation and allocation-instruction choices — is driven against an in-process registry that answers what the OpenAPI documents say and records what it was asked, and the holdings read is driven against an in-process StateService. What those pin is the request each workflow sends and that the registry’s context lands inside the exercise argument, which is the part a mutation run found nothing else guarding.

The V1 packages come from cn-quickstart at a pinned commit, fetched in CI and checked against their SHA-256. The V2 packages ship as no DAR anyone publishes, so they were taken from a participant and committed under testdata/token-standard-v2, where each file name ends with the package id that hashes its bytes.

PQS

What CI runs, and what it cannot

The LocalNet workflow sets CANTON_TEST_REQUIRE_LIVE, so a suite that cannot reach its environment fails rather than skips, and it asserts each suite’s exact passed count and zero ignored tests: ledger 39, interactive 5, admin 5, PQS 9, token 5. One PQS test skips without that guard when the store holds no Amulet, so the workflow also requires the line that test prints when it compares. Outside CI, a suite gated on an environment variable skips when the variable is unset and fails when it is set and the connection fails — a connection failure and an unconfigured machine used to look the same in a green run, and they are not the same thing.

Conformance to the Ledger Client Standard

conformance/capabilities.toml lists every capability of the standard this SDK claims, and canton-conformance has one test named for each; conformance/ledger-client-standard-mapping.md is the same map for reading, row by row, with the rows the grant does not claim. A completeness guard asserts the two agree in both directions: no capability without a test, and no test claiming a capability the registry does not list.

One row is worth reading carefully. Contract keys are covered by a real keyed DAR, testdata/contract-keys (Daml-LF 2.3, six keyed templates): the conformance row generates bindings from it, canton-codegen’s compile test builds them and an exercise-by-key command from them, and the lf-conformance job holds the decoder to the JVM reader on it. A transaction that uses keys is signed under hashing scheme V3, which the SDK recomputes like V2.