Skip to main content

Module types

Module types 

Source
Expand description

The generated token-standard types this crate’s API is written in terms of, re-exported so they can be named without depending on each generated crate directly.

This is not a convenience. transfer takes a Transfer and v2::transfer takes a Transfer — so without these a cargo add canton user could reach the functions through the facade and be unable to name their arguments. The whole token deliverable was unreachable that way, which is the same defect the crate’s own conformance suite states the rule against: a capability that works only via a member crate is not one cargo add canton delivers.

Whole modules rather than a hand-listed set of types, because a list goes stale the first time the standard adds a record and nothing notices.

Modules§

metadata
Metadata — ExtraArgs, ChoiceContext, Metadata. Shared by both standards: there is no metadata-v2.
v1
CIP-56 — the V1 token standard.
v2
CIP-0112 — the V2 token standard.