Introduction

This guide is designed to help you understand and effectively utilize the application’s capabilities to create/issue tokens (mint), transfer them, and track ownership records. We will explore various workflows from a business perspective and provide workflow examples with diagrams to illustrate each process.

Utility Overview

The Registry utility is a core application for asset tokenization, leveraging Canton and Daml technologies to securely register and manage assets. It provides the foundational infrastructure needed to tokenize assets, ensuring transparency, immutability, and decentralized control.

Traditionally, asset registries are closed systems accessible only to operators. Users interact indirectly through messaging, relying on operators to perform actions and receiving periodic reports. To maintain local access to their data, users often replicate information internally, necessitating frequent reconciliation with the central registry.

In contrast, the Canton-ledger-based Registry provides users with direct access and control over their tokenized assets. This system allows users to perform actions—such as transfers, deposits, or withdrawals—directly through their local participant node, eliminating the need for operator intermediation. This direct access is crucial for asset tokenization, as it enables users to interact with their digital assets seamlessly and securely.

Furthermore, the utility empowers users to delegate specific actions to third-party applications, facilitating more advanced workflows and use cases. For instance, a third-party Delivery versus Payment (DvP) application could use party delegation to settle asset movements across multiple registries atomically, making it ideal for complex tokenized transactions.

The local participant node also ensures that users have a consistent, real-time view of the registry, thanks to the Canton protocol’s guaranteed synchronization. By storing data locally with assured consistency, users no longer need to maintain separate data stores or engage in ongoing reconciliation with the central registry.

As a core application for asset tokenization, the Registry utility enables the creation, management, and transfer of digital assets with the security and transparency necessary for modern decentralized systems. This makes it an essential tool for any organization looking to leverage blockchain technology for asset management.

Use Cases

Streamlined Collateral and Margin Management

A hedge fund uses tokenized assets as collateral for its trading strategies. These assets are tokenized and registered on the Canton Network, allowing the hedge fund to adjust its collateral in real time as market conditions change. The instant, atomic settlement of tokenized assets reduces the time and cost associated with margin calls and enhances the fund’s operational efficiency.

Self-Sovereign Asset Control

A private investor holds a diversified portfolio of tokenized stocks and commodities on the Canton Network. The investor has full control over their assets, managing them directly from their participant node. They can transfer, sell, or lend their tokenized assets without needing to go through a broker, giving them greater autonomy and reducing transaction costs.

Cross-Application Composability

A registered tokenized asset on the Canton Network is used as collateral in a decentralized lending platform. The asset’s token can be seamlessly integrated and used in other DeFi applications, like automated market makers or yield farming protocols, allowing the holder to leverage their assets across multiple financial products and services, increasing the asset’s utility and potential returns.

Enhanced Liquidity in Secondary Markets

A real estate investment trust (REIT) tokenizes its property assets on the Canton Network. Investors can buy and sell fractions of these properties as tokens on a secondary market, allowing for near-instant transactions. This dramatically increases the liquidity of these traditionally illiquid assets, making it easier for investors to enter and exit positions quickly.

Users, parties and credentials

A party in Daml represents a ledger entity with a single set of rights and is universal across participant nodes.

A user is local to a specific participant node. Each user is typically associated with a primary party and is given the right to act as or read as other parties. Each participant node maintains its own mapping from its user ids to the parties that they can act and/or read as. Also, when used, the user’s ids will serve as application ids. Thus, participant users can be used to manage the permissions of Daml applications (i.e. to authorize applications to read as or act as certain parties). Unlike a JWT token-based system, the user management system does not limit the number of parties that the user can act or read as.

The Registry allows the onboarding of user parties with different business roles, which determine what operations they can perform within the application. These roles are defined by respective Daml “Service” contracts, which expose choices to interact with the application.

To determine if a party can be onboarded with a certain role, the Registry Application uses credential contracts issued via the Credential Utility. Moreover, permissions for certain actions across the application (e.g. mints or transfers) are also controlled via suitable Credential contracts.

Roles

An application user can be onboarded and assigned one or multiple business roles, each represented by a corresponding service contract:

../_images/registry_utility.png

Operator

  • Maintains Daml models, provides UI, operates automation on behalf of users

  • Onboards Providers to the Registry Utility

../_images/operator_onboarding_no_header.png

Provider

  • Onboards Registrars and Holders to the Registry Utility

  • Example: Financial Infrastructure Provider, Tokenization Provider

../_images/provider_onboarding_no_header.png

Registrar

  • Maintains ownership records for assets on behalf of Issuers

  • Specifies the requirements to issue and hold asset tokens

  • Example: SS&C, CSDs, custodians

Holder

  • Obtains, holds, and transfers asset within a registry

  • Example: Institutional and Private Investors

../_images/registrar_and_holder_onboarding_no_header.png

The Asset Model

A holding contract instance represents the ownership of a certain number of units of an instrument by an owner at a registrar. Whereas an instrument defines what a party holds (the rights and obligations), a holding defines how much (i.e., the amount) of an instrument and against which party (i.e., a registrar) the instrument is being held. It’s crucial to note that the economic terms of an asset (instrument) are distinct from its representation in a holding. This segregation enables centralized management of instruments (e.g., lifecycling, KYC requirements) and facilitates the reuse of instruments and associated logic across various entities (e.g., custodians). Moreover, it prevents data redundancy by eliminating the need to replicate instrument data and logic in every holding contract.