canton-token

Canton Network token-standard workflows: the registry client, choice contexts, and the transfer and allocation flows. CIP-56 (V1) at the crate root and CIP-0112 (V2) under v2, which keeps the same function names one module down — token::transfer and token::v2::transfer are different standards, and the path is what says which you meant.

Part of the Canton Rust SDK.

What this crate is, and is not

The token-standard types are generated from the Splice DARs and live in the canton-splice-api-token-* crates. This crate does not re-declare any of them — that would duplicate the code generator and go stale on the next Splice release. The Holding named here is the same Rust type an application reads out of the ledger.

What is missing from generated types is the workflow: resolving a factory, asking a registry for a choice context, attaching the contracts it says to disclose, and exercising the choice. That is this crate.

Why a registry is involved

A token-standard choice is exercised through an interface, and only the registry knows what reference data that choice needs — its own configuration contracts, the rules for an instrument, the current round. So the client asks for a choice context and gets back two things: the data to pass into the choice, and the contracts the participant must be shown for it to resolve.

Those contracts are usually invisible to the submitting party. That is what explicit disclosure is for, and attaching them correctly is most of what this crate does.

The registry API is off-ledger HTTP, specified by the token standard's OpenAPI documents — token-metadata-v1, transfer-instruction-v1, allocation-v1, allocation-instruction-v1, and their V2 counterparts transfer-instruction-v2, allocation-v2, allocation-instruction-v2. Every path and payload here comes from them (vendored under testdata/openapi/ at the Splice release the tests pin), and the method names follow their operationIds so the two can be read side by side.

The encoding that makes this work

The standard specifies that a factory's choiceArguments are encoded "using the Daml JSON API, with the extraArgs.context and extraArgs.meta fields set to the empty object" — and the context comes back in the same encoding. That is exactly what canton-daml implements, so a generated choice type serializes straight onto the wire and the returned context deserializes straight into the generated ChoiceContext. No hand-written JSON anywhere in the path.

Licence

Apache-2.0. See LICENSE.