> ## Documentation Index
> Fetch the complete documentation index at: https://docs.digitalasset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Asset Lifecycle Workflows

> Understand how the DA Registry enables Registrars to configure instruments, manage token supply and execute compliant transfers.

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.

<CardGroup cols={2}>
  <Card title="Instrument Configuration" icon="gear">
    Define the identity of an asset and establish the precise credential rules required to hold, mint, or burn its tokens.
  </Card>

  <Card title="Supply Minting" icon="plus">
    Increase an instrument's supply via a secure request-and-verify workflow that requires registrar approval.
  </Card>

  <Card title="Supply Burning" icon="minus">
    Permanently retire tokens from circulation to manage redemptions or contract supply safely.
  </Card>

  <Card title="Token Transfers" icon="arrows-left-right">
    Move assets between authorized parties using either explicit multi-party confirmation or automated pre-approvals.
  </Card>
</CardGroup>

## 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.

<Note>
  **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.
</Note>

### 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.

<Tabs>
  <Tab title="Minting Tokens">
    **Safely expand asset supply.**

    <Steps>
      <Step title="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.
      </Step>

      <Step title="Automated Validation">
        The system automatically verifies that the requester holds valid **Instrument Issuer** credentials as defined by the instrument's configuration.
      </Step>

      <Step title="Registrar Review">
        The Registrar reviews the request. Upon acceptance, the tokens are generated and credited to the requester. If rejected, the offer is voided.
      </Step>
    </Steps>

    *Requesters retain the ability to cancel a mint request at any time prior to registrar acceptance.*
  </Tab>

  <Tab title="Burning Tokens">
    **Reduce supply and manage redemptions.**

    <Steps>
      <Step title="Submit Burn Request">
        An authorized issuer requests to remove a designated volume of tokens currently in their possession, detailing the instrument, registrar party, burn amount, and sender label (account ID) for the account to burn from.
      </Step>

      <Step title="Operational Lock 🔒">
        To maintain balance sheet integrity, the targeted tokens are immediately **locked** on the ledger, preventing them from being traded or moved while the burn is pending.
      </Step>

      <Step title="Permanent Retirement">
        Once the Registrar accepts the request, the tokens are permanently removed from circulation. If rejected or canceled, the lock is released immediately.
      </Step>
    </Steps>
  </Tab>
</Tabs>

## 💸 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

<AccordionGroup>
  <Accordion title="Standard Transfer (Offer / Accept)" defaultOpen icon="handshake">
    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.
  </Accordion>

  <Accordion title="Direct Transfer (Pre-Approval)" icon="bolt">
    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.
  </Accordion>
</AccordionGroup>

<Warning>
  **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.
</Warning>