Skip to main content
The DA Registry Workflows provide a structured, permissioned framework for managing digital assets throughout their lifecycle. Operating on the Canton Network Token Standard, these workflows automate compliance checks and coordinate multi-party actions seamlessly.

​
Capabilities Overview

The DA Registry provides four primary capabilities to help you manage digital assets while ensuring compliance and operational control.

Instrument Configuration

Define the identity of an asset and establish the precise credential rules required to hold, mint, or burn its tokens.

Supply Minting

Increase an instrument’s supply via a secure request-and-verify workflow that requires registrar approval.

Supply Burning

Permanently retire tokens from circulation to manage redemptions or contract supply safely.

Token Transfers

Move assets between authorized parties using either explicit multi-party confirmation or automated pre-approvals.

​
Instrument Configuration & Compliance

Before any token operations can occur, an authorized party with the Registrar role must establish an InstrumentConfiguration. This contract serves as the regulatory template for the asset.

​
Key Operational Benefits:

  • Rule Enforcement: Define specific Holder and Issuer credential requirements. The ledger automatically enforces these rules, ensuring that only verified parties can interact with the asset.
  • Legacy System Mapping: Optionally include traditional identifiers such as ISIN or CUSIP to streamline reconciliation with external financial systems.
  • Transparent Ruleset: Once created, configurations are explicitly disclosed to the network, ensuring all participants operate under identical compliance parameters.
Automated Guardrails: If a user does not possess the credentials specified in the instrument configuration, the system will block them from holding or transferring the token at the ledger level.

​
Accounts & Labels

The holding label corresponds to the account ID field in the Token Standard v2 holding view (also encoded in the meta field of Token Standard v1 holding view). Labels are used to identify holdings across workflows.
  • Mint: the receiver label sets the account ID of the newly minted holding.
  • Burn: the sender label identifies the account to burn from.
  • Transfer: the sender label identifies the account to send from, and the receiver label is used to set the account ID on the received holding.
  • Direct pre-approvals: the receiver label must be empty ("") for the pre-approval to take effect.
For any workflow where input holdings are provided, the sender label may be specified. If no label is specified, it defaults to the empty string (""). The receiver label can similarly be specified in workflows with output holdings. Output holdings receive the specified label, or default to the empty string ("") if unspecified. The input holdings may originate from any account and are faded in to the specified sender account before the burn, transfer, or allocation is executed. This fade-in behavior is reflected in transaction history v2, which logs the account-level movement: first the fade-in to the sender account, then the operation to the destination. Each application is responsible for filtering which input holdings to provide. The Registry App UI enforces a strict filtering of input holdings to match the sender label specified.

​
Supply Management (Mint & Burn)

To maintain precise control over token economics, the supply of any instrument can be adjusted using a secure Request/Accept architecture. This prevents unauthorized issuance or accidental supply inflation.
Safely expand asset supply.
1

Initiate Request

An authorized party requests a specific mint volume, detailing the instrument, registrar party, target amount, and target label (account ID) for the minted holding.
2

Automated Validation

The system automatically verifies that the requester holds valid Instrument Issuer credentials as defined by the instrument’s configuration.
3

Registrar Review

The Registrar reviews the request. Upon acceptance, the tokens are generated and credited to the requester. If rejected, the offer is voided.
Requesters retain the ability to cancel a mint request at any time prior to registrar acceptance.

​
💸 Compliant Token Transfers

Moving assets between participants can be adapted to fit different operational velocities, depending on the relationship and trust level between counterparties.

​
Transfer Methods

Standard Transfer (Offer / Accept)

Designed for transactions requiring explicit bilateral consent.
  • Sender and Receiver Labels: The sender label specifies the account to send from, and the receiver label sets the account ID on the received holding.
  • Asset Locking: When a sender initiates a transfer, the required tokens are automatically selected and locked, preventing double-spending.
  • Bilateral Control: The receiver must explicitly accept the transfer for ownership to change. If the receiver rejects the offer, or if the sender withdraws it before acceptance, the tokens are safely unlocked and returned to the sender.
Optimized for high-frequency operations or automated settlement pipelines.
  • Sender and Receiver Labels: The sender label specifies the account to send from. To enable pre-approvals, the receiver label must be set to the empty string (""), otherwise the transfer defaults to standard offer/accept.
  • Proactive Authorization: A receiving party can set up a TransferPreapproval contract ahead of time for up to 10 specific instrument IDs (or all instruments managed by a specific admin).
  • Straight-Through Processing: When a sender initiates a transaction that matches a valid pre-approval, the system bypasses the manual acceptance step entirely. The transfer settles instantly and updates token ownership in real-time.
Transfer Prerequisites: For any transfer workflow to succeed, a valid TransferRule must be active, and both the sending and receiving parties must meet the Instrument Holder credential requirements established during instrument configuration.