Workflows

Create Instrument Configuration

The “Instrument” serves as an identifier of the actual asset being managed.

Within the registry utility, an Instrument Configuration contract is used to establish eligibility criteria (i.e. required Credentials) for holding and issuing tokens on a specific instrument:

• Holder Credential Requirements: Credentials needed for holding and transferring tokens of the instrument.

• Issuer Credential Requirements: Credentials needed for minting and burning tokens.

For each instrument configuration, the following values need to be specified based on the credential model:

• Issuer: The partyId of the issuer of the credential.

• Property: The claim’s property (e.g., “isIssuerOf” or “isHolderOf”).

• Value: The value of the claim property (e.g., the instrument’s name or a unique identifier).

Moreover you need to specify a unique identifier for the instrument.

By correctly configuring these values, you ensure that only authorized parties can hold or issue tokens for a specific instrument, maintaining the integrity and security of the system.

Mint

The registry provides a Mint workflow, which allows a user to create new units, or tokens, of digital assets known as Holdings. Before minting, the Instrument for which you want to create a unit needs to be defined according to the instrument configuration.

To Mint a token, the involved party must be onboarded into the registry utility as a Holder and Registrar, respectively. The minting process follows a request/accept workflow:

1. Mint Request: The party requesting the mint must have the appropriate Issuer credential as defined in the instrument configuration. Additionally, the party that will hold the minted token must possess the necessary Holder credential.

2. Mint Approval: Only the Registrar is authorized to accept Mint requests. Once the request is accepted, the new tokens are created and assigned according to the specified holdings.

The Mint request requires the following input:

• Instrument: The identifier of the instrument that will be minted

• Amount: the amount that will be minted

• Label (optional): an option to tag tokens (UTXO) for accounting purposes (e.g. several tokens that serve a specific purpose)

• Registrar: the registrar of the token that will receive the Mint request and needs to accept it

• Reference

By ensuring that only credentialed parties can request and approve minting, the registry maintains a controlled environment for creating regulated assets which complies with KYC/AML requirements.

Burn

The registry provides a Burn function, allowing users to permanently remove units or tokens of digital assets, known as Holdings, from circulation.

To execute a Burn, the involved parties must be onboarded into the registry utility as a Holder and Registrar, respectively. The burning process follows a request/accept workflow:

1. Burn Request: The party requesting the burn must have the appropriate Instrument Issuer credentials as defined in the instrument configuration. Additionally, the party holding the tokens to be burned must possess the necessary Instrument Holder credentials.

2. Burn Approval: Only the Registrar is authorized to accept Burn requests. Once the request is accepted, the specified tokens are permanently removed from the registry.

The Burn request requires the following input:

• Instrument: The identifier of the instrument that will be burned

• Amount: the amount that will be burned

• Label (optional): if you want to burn a token (UTXO) that is tagged with a specific label, this will be mapped when executing the burn.

• Registrar: the registrar of the token that will receive the Burn request and needs to accept it

• Reference

Transfer

The Transfer function enables users to securely move tokens of digital assets from one party to another at a registrar. Like the minting and burning processes, transferring tokens requires that the involved parties—the sender and recipient—have the necessary permissions, defined by the Instrument Holder credentials in the respective instrument configuration.

Transfers follow a request/accept workflow:

• Transfer Request: The party initiating the transfer (the sender) specifies the following:

  • The instrument being transferred.

  • The recipient’s partyId.

  • The registrar’s partyId.

  • The amount of tokens to be transferred.

  • An optional reference (e.g., reason for payment) for tracking or reporting purposes.

    • If the transfer is associated with a specific label (e.g., categorizing funds for a particular purpose), the transfer will only proceed if there are sufficient holding contracts (UTXOs) with the same label to cover the specified amount.

• Transfer Approval: The recipient has the ability to either accept or reject the transfer request. Upon acceptance, the ownership of the tokens are changed from the sender to the recipient within the registry. Thereby the registrar is not changed.

• Recipient Credential Check: Before the transfer is executed, it is verified that the sender and recipient have valid Instrument Holder credentials for the instrument, ensuring that only authorized parties can send and receive the tokens.

  • If no Instrument Holder credentials are defined in the Instrument Configuration of the instrument, any party is eligible to hold it.

By using the request/accept flow, the registrar guarantees that all transfers are securely managed and authorized, preventing unauthorized or erroneous transactions. This approach helps maintain the integrity and traceability of token ownership within the registry.

Lock/Unlock

The registry utility provides a Lock/Unlock function, allowing holders to offer locks on assets. This feature is useful in scenarios where the holder wants to offer assets as collateral to another party for an underlying use case, such as a loan or a secured transaction.

The lock/unlock process follows an offer/accept workflow:

Lock

• Lock Offer: The holder, who owns the assets, can offer a lock on their assets to another party. The offer includes the following details:

  • Lock Owner: The partyId of the party to whom the lock is being offered.

  • Context

  • Instrument: The type of asset being locked.

  • Amount: The quantity of assets to be locked.

  • Registrar: The partyId of the registrar overseeing the lock.

  • Reference: An optional reference field to provide context, such as the reason for the lock or the agreement under which the assets are being locked.

  • If the lock is associated with a specific label (e.g., categorizing funds for a particular purpose), the lock will only proceed if there are sufficient holding contracts (UTXOs) with the same label to cover the specified amount.

• Lock Acceptance: The recipient party can accept or reject the lock offer. Upon acceptance, the specified assets are locked within the registry, preventing them from being transferred or used by the holder until the lock is lifted.

Unlock

Once the underlying use case is resolved (e.g., the loan is repaid), the assets can be unlocked. This can either be initiated by the party holding the lock or as part of an agreed-upon process. When unlocked, the assets are once again freely available for transfer or other uses.

• Unlock Offer: The party holding the lock, or the registrar, initiates the unlock by specifying the following parameters:

  • Owner (Party Holding the Asset): The partyId of the original owner who holds the locked assets.

  • Context

  • Instrument: The type of asset that is being unlocked.

  • Amount: The quantity of assets to be unlocked.

  • Registrar: The partyId of the registrar managing the unlock process.

  • If the lock is associated with a specific label (e.g., categorizing funds for a particular purpose), the unlock will only proceed if there are sufficient holding contracts (UTXOs) with the same label to cover the specified amount.

  • Reference

• Unlock Acceptance: The owner of the locked assets or the registrar can approve or reject the unlock offer. Upon acceptance, the assets are released from the lock.