Documentation

This section aims to outline the supported integration modes for apps that wish to compose with the Registry App directly on the Daml level. General guidance We recommend that your Daml code only depends on Daml interface packages, rather than packages depending on concrete template implementati

The Burn workflow removes existing holdings from circulation. Like minting, burning uses a request-and-accept model. Prerequisites Before burning can occur: • The holdings must already exist. • The requester must hold the amount to be burned. • The requester must satisfy the issuer credential

The Registry App supports the Canton Network Token Standard, as defined in CIP-56 and CIP-112 . App / Wallet providers integration App providers and Wallet providers wishing to transact Registry holdings as part of their application’s workflows must make sure that • all supported versions of th

In order to interact with the Registry App over CIP-56 or CIP-112 , certain contract disclosures need to be sourced via an off-ledger API. These endpoints are specific to each instrument admin, and are exposed with the following base URL: • MainNet • TestNet • DevNet https://api.utilities.

The Mint workflow creates new holdings for an instrument. Minting uses a request-and-accept model. The requester initiates the mint, and the Registrar approves or rejects it. Prerequisites Before minting can occur: • The Instrument Configuration must exist. • The requester must satisfy the is

Onboarding credential services for all entities All entities request credential service from DA, the Operator. Actor | Utility Module | Provider | CREDENTIAL | Registrar | CREDENTIAL | Issuer | CREDENTIAL | Investor1 | CREDENTIAL | Select ONBOARDING on the left navigation. Click REQUES

The Transfer workflow moves ownership of holdings from one party to another. The Registry App supports both two-step transfers and preapproved transfers. Prerequisites Before a transfer can occur: • The sender must hold the asset. • The Registrar must have created the required transfer rules.

DARs This release introduces the following DAR versions: Package | Version | Package Id | utility-commercials-v0 | 0.4.1 | fa5b1cc5c8368dff7c2e6a74aa2af9d520d755e2a508f44acd17343326e41839 | utility-credential-app-v0 | 0.4.1 | e9a3b7df354dfd2f15c7d015328c34256308c90ba96f86f185dad58ffca8299b |

After the Provider Configuration has been created, parties can request to onboard as registrars. A registrar is responsible for creating instruments and managing asset lifecycle workflows such as minting, burning, and transfer controls. Workflow • A party requests a Registrar Service from the Pr

DARs This release introduces the following DAR versions: Package | Version | Package Id | utility-registry-app-v0 | 0.8.2 | 2293eb12e82ceaeb3ff7f8fe3346dece8578e1e9fd7d46624aeb7bb07fa31eda | utility-registry-v0 | 0.7.1 | 1f80e086e9ce218cf93fdeed80943793e902ac35c521733d7373a5ba58813150 | uti

Before Registrars can be onboarded, the Provider must create a Provider Configuration. The Provider Configuration defines the onboarding requirements for Registrar parties. These requirements determine which parties can be onboarded as a Registrar. Purpose The Provider Configuration allows the

This tutorial details the steps to issue a tokenized instrument using the Credential and Registry utilities. Instrument The tokenized instrument issued is called BOND and is defined in the “Registrar creates instrument configuration” step. Roles Roles in Tokenization Utility | Entity | Rol

Investor1 returns all holdings to Issuer Investor1 (as the holder of BOND) offers transfer of BOND to Issuer (another holder of BOND). Actor | Utility Module | Investor1 | REGISTRY | Select HOLDINGS on the left navigation. The 8,000 BOND is there. Click TRANSFER. Input issuer’s party ID as t

Onboarding credential services for all entities Investor2 requests credential service from DA, the Operator. Actor | Utility Module | Investor2 | CREDENTIAL | Select ONBOARDING on the left navigation. Then click REQUEST CREDENTIAL USER SERVICE. A request is shown in the Requests tab. The req

In connection with the use of Circle’s xReserve Smart Contract, Digital Asset provides discretionary support to users with issues arising from certain Canton-related software components. Digital Asset does not provide support with respect to Circle’s xReserve Smart Contract or your use of USDCx on t

Investor1 offers token transfer to Investor2 Investor1 (as the holder of BOND) offers transfer of BOND to Investor2 (another holder of BOND). Actor | Utility Module | Investor1 | REGISTRY | Select HOLDINGS on the left navigation. The 10,000 BOND is there. Click TRANSFER. Input investor2’s pa

Token Details (MainNet) On Canton Network, the uniqueness of the token is the combination of the token’s Instrument Id and the party ID of the token’s admin (registrar). Below are these details for USDCx. Only the USDCx that contains these details is the official USDCx on the Canton Network. I

Applications (such as wallet providers and exchanges) can integrate and interact with the xReserve solution and/or USDCx via API. There are three options for supporting USDCx on the Canton Network: • Transfer & hold USDCx - Since USDCx is a token standard CIP-56 compliant asset, any wallet that sup

Preparing credentials for token transfer. Registrar offers credential of token holder to Investor2 Registrar (of BOND) offers a free credential to Investor2 (as a holder of BOND). Actor | Utility Module | Registrar | CREDENTIAL | Investor2 accepts credential offer Investor2 accepts the c

Issuer requests token issuance (minting) Issuer (as the issuer of BOND) requests issuance (minting) of 10,000 BOND. Actor | Utility Module | Issuer | REGISTRY | Registrar accepts and tokens are issued Registrar (as the registrar of BOND) accepts the mint request. Actor | Utility Module |

Credential Preparation for Token Issuance and Transfer Registrar specifying the requirement of the BOND token Here Registrar of BOND specifies the credential requirement, i.e. what credentials are needed in order to issue or hold the BOND tokens. Actor | Utility Module | Registrar | REGISTRY

This tutorial details the steps to redeem a tokenized instrument using the Credential and Registry utilities. Instrument The tokenized instrument redeemed is called BOND. Roles Roles in Tokenization Utility | Entity | Roles in Asset BOND | Provider (onboarded by DA) | Provider | Registra

0.3.0 UI • Sources the required disclosed contracts from the utility backend’s new API endpoint burn-mint-instruction/v0/burn-mint-factory. • The UI now requires the URL of the utility backend to be provided as an environment variable. This is included in the Helm chart and compose file config

This tutorial details the steps to transfer a tokenized instrument from Investor1 to Investor2 using the Credential and Registry utilities. Instrument The tokenized instrument transferred is called BOND. Roles Assumptions: • Investor1 is already onboarded. • Investor2 is not yet onboarde

As digital assets move through complex operational and regulatory lifecycles, issuers occasionally need the ability to immediately halt activity on an instrument—whether to respond to a security incident, a regulatory hold, or an internal operational review. Relying on off-chain coordination to stop

Canton release notes are reproduced below from the published Canton release bundles. Releases • Canton 3.7.2 • Canton 3.7.1 • Canton 3.7.0 • Canton 3.6.4 • Canton 3.6.3 • Canton 3.6.2 • Canton 3.6.1 • Canton 3.5.19 • Canton 3.5.18 • Canton 3.5.17 • Canton 3.5.16 • Canton 3.5.15 • Cant

Release of Canton 3.7.2 Canton 3.7.2 has been released on November 04, 2026. Summary This is a maintenance release that fixes a resource leak on sequencer nodes and updates the base Docker image to address security vulnerabilities. Sequencer node operators should upgrade. What’s New Minor

Canton uses a structured error code system across all components. Every error logged or returned via the API follows the format ERROR_CODE_ID(category_id, correlation_id_prefix): human-readable message. This page explains how to read these errors, which categories require operator action, and what

Versioning All Canton and Daml SDK components are versioned according to Semantic Versioning . In short, there is a well defined “public API”, and the version number is intended to signal changes or breakages to it. Stable releases have versions MAJOR.MINOR.PATCH. Segments of the version are incr

Back to overview Protobuf Package com.digitalasset.canton.admin.participant.v30 12 services, 81 endpoints, 193 messages, 9 enums gRPC Added 3.7.0 Updated 3.5.1 Methods removed in 3.5.1 Files 14 Services 12 Endpoints 81 Messages 193 Enums 9 Source Files community/admin-api/src/main/pro