Documentation

DARs The 0.14.4 release introduces the following DAR versions: Package | Version | Package Id | utility-registry-app-v0 | 0.9.2 | 1eddd268bdd50d6e262722bea799c9455da032b3f94489e589975151b274b8c0 | utility-registry-v0 | 0.8.2 | 8c654487d9f5fb195fbcdd7b44cd8e365b1ea39c15ae62ce6c7a48343f1210dd

Court orders and regulatory requirements can require an issuer to take back assets from a holder, even when the holder does not cooperate. The DA Registry lets registrars enable force transfer for a new instrument. For an instrument with force transfer enabled, the registrar can force transfer hold

This feature has been introduced with version 0.15 of the Registry App. For an overview of force transfer, see Force Transfer . For Registrars Create an Instrument with Force Transfer Enabled Decide before you create the instrument. You cannot enable or disable force transfer later. • In

Support for the Token Standard V2 interfaces ( CIP-112 ) was added in version 0.14 of the Registry App. Starting with this version, the Registry App provides cross-version compatibility between the V1 ( CIP-56 ) and V2 interfaces. This page clarifies the Registry App specific aspects of two kinds o

CIP-112 support, including accounts, was introduced with version 0.14 of the Registry App. V1 wallets are unaware of accounts, so they may select input holdings with different labels (account IDs). This page outlines the resulting compatibility issue when the transaction runs on a Registry version

cURL cURL curl --request POST \ --url https://api.utilities.digitalasset.com/api/utilities/v0/contract/instrument-configuration \ --header 'Content-Type: application/json' \ --data ' { "registrar": "<string>", "instrumentIdentifier": { "source": "<string>", "id": "<string>",

cURL cURL curl --request GET \ --url https://api.utilities.digitalasset.com/api/utilities/v0/contract/instrument-configuration/all import requests url = "https://api.utilities.digitalasset.com/api/utilities/v0/contract/instrument-configuration/all" response = requests.get(url) pr

cURL cURL curl --request GET \ --url https://api.utilities.digitalasset.com/api/utilities/v0/package/all import requests url = "https://api.utilities.digitalasset.com/api/utilities/v0/package/all" response = requests.get(url) print(response.text) const options = {method:

cURL cURL curl --request GET \ --url https://api.utilities.digitalasset.com/api/utilities/v0/operator import requests url = "https://api.utilities.digitalasset.com/api/utilities/v0/operator" response = requests.get(url) print(response.text) const options = {method: 'GET'

cURL cURL curl --request GET \ --url https://api.utilities.digitalasset.com/api/utilities/v0/openapi import requests url = "https://api.utilities.digitalasset.com/api/utilities/v0/openapi" response = requests.get(url) print(response.text) const options = {me

Overview For compliance reasons, asset issuers might require Know Your Transaction (KYT), Anti-Money Laundering (AML) monitoring, accounting, and other data-driven services to be set up before issuing assets on Canton. On public blockchains, third-party service providers can independently index t

0.14 0.13 0.12

This feature is introduced with version 0.15 of the Registry App. Version 0.9.0 of the utility-registry-v0 package added the underlying isPaused field to the InstrumentConfiguration. A paused instrument cannot be interacted with by non-registrar parties, with narrow exceptions where the regi

The DA Apps team performs weekly maintenance every Thursday from 09:00–10:00 ET / 15:00–16:00 Central European Time / 13:00–14:00 UTC , aligned with Splice upgrades on MainNet. During this maintenance window, individual components may experience brief periods of downtime.

The Operator backend exposes a set of publicly accessible endpoints serving information essential to the fulfillment of the Registry Daml workflows. It is used by the Registry UI to source reference information, such as the party identifier of the operator, as well as the set of available instrumen

This is done by implementing the Splice BurnMintFactory interface in the AllocationFactory template of the Registry App. An off-ledger endpoint provides the necessary contract disclosures in order to execute the BurnMintFactory_BurnMint choice. See the Open API spec for more details.

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