# Key flows

Source: https://docs.settlemint.com/docs/architects/overview/key-flows
Index of the main DALP system flows, covering shared platform operations, asset lifecycle capabilities, feed updates, and settlement workflows with links to detailed walkthroughs.



Each key flow traces a request from an operator or API client through signing, on-chain contract enforcement, and indexing to the surfaces that record it.

Use this after [asset tokenization architecture](/docs/architects/overview/asset-model) to follow the request path for the step you are reviewing. Each linked page explains control points, failure handling, and related components. For field-level detail, consult the API or contract reference pages. Continue with [lifecycle after issuance](/docs/architects/overview/lifecycle-after-issuance) when the asset is already live.

Related pages: [Architecture map](/docs/architects/overview), [System context](/docs/architects/overview/system-context), [Post-issuance lifecycle](/docs/architects/overview/lifecycle-after-issuance), [Flows section](/docs/architects/flows), and [Components](/docs/architects/components).

## Platform flows [#platform-flows]

These flows represent core operations. Any lifecycle change you trigger on an asset depends on one or more of them.

| Flow                                                              | Trigger                                               | Outcome                                                                                                | Key components                                                                                                                       |
| ----------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| [Signing flow](/docs/architects/flows/signing-flow)               | Any state-changing operation (transfer, mint, redeem) | Transaction signed by custody provider and confirmed on-chain                                          | Workflow Engine, Transaction Signer, Key Management, Custody Provider (DFNS/Fireblocks), Broadcast, SMART Protocol compliance engine |
| [Asset issuance](/docs/architects/flows/asset-issuance)           | Issuer creates a new tokenized instrument             | Asset contract deployed with compliance rules, identity requirements, and optional features configured | Console/API, Workflow Engine, Factory Registry, System layer, SMART Protocol                                                         |
| [Compliance transfer](/docs/architects/flows/compliance-transfer) | Token holder initiates a transfer                     | Transfer completes if identity and compliance rules pass; reverts otherwise                            | SMART Protocol compliance engine, Identity Registry, Compliance Modules                                                              |
| [Feeds update flow](/docs/architects/flows/feeds-update-flow)     | Issuer signer or oracle operator publishes a value    | Signed price or oracle data is validated, stored, indexed, and made available to consumers             | Feed contract, Feeds Directory, Transaction Signer, Ledger Index                                                                     |

![Asset Designer guides issuers through a structured 7-step creation process](/docs/screenshots/asset-designer/asset-designer.webp)

## Capability flows [#capability-flows]

These flows represent specific capabilities that issuers configure per instrument. They reuse the platform flows above and do not bypass signing, compliance checks, or indexing controls.

| Flow                                                                  | Trigger                                                       | Outcome                                                                                            | Key components                                                               |
| --------------------------------------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| [Treasury distribution](/docs/architects/flows/treasury-distribution) | Scheduled interval or lifecycle event (coupon date, maturity) | Settlement currency distributed from asset treasury to eligible investors proportional to holdings | Asset Treasury, Payment Features (Yield/Coupon/Redemption), Compliance Layer |
| [XvP settlement](/docs/architects/flows/xvp-settlement)               | Counterparties agree to exchange assets                       | Atomic delivery-versus-payment across two asset legs, where both complete or neither does          | XvP Addon, Compliance Layer (both legs), Settlement Engine                   |

![XVP settlement configuration for atomic swap operations](/docs/screenshots/xvp/xvp-setup-1.webp)

## How to read a flow page [#how-to-read-a-flow-page]

Each flow page in the [Flows section](/docs/architects/flows) follows a consistent structure: an overview of what the flow does and why it matters, a numbered-step diagram, a step-by-step breakdown, a section on failure handling, and links to component and API pages.

## Flow dependencies [#flow-dependencies]

All capability flows depend on the signing flow for on-chain execution and on compliance-transfer logic to validate token moves. A deployed asset is a prerequisite: DAIO offerings, airdrops, treasury distributions, and XvP settlement each require one before you can configure them.

<Mermaid
  chart="`flowchart TB
  Signing[Signing flow]
  Issuance[Asset issuance]
  Compliance[Compliance transfer]
  Feeds[Feeds update flow]
  DAIO[DAIO offering]
  Airdrop[Airdrop distribution]
  Treasury[Treasury distribution]
  XVP[XvP settlement]

  Signing --> Issuance
  Signing --> Compliance
  Issuance --> DAIO
  Issuance --> Airdrop
  Issuance --> Treasury
  Issuance --> XVP
  Signing --> Feeds
  Compliance --> DAIO
  Compliance --> Airdrop
  Compliance --> Treasury
  Compliance --> XVP

  style Signing fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style Issuance fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style Compliance fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style Feeds fill:#fff4df,stroke:#b7791f,stroke-width:2px,color:#333
  style DAIO fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#333
  style Airdrop fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#333
  style Treasury fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#333
  style XVP fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#333`"
/>

The signing flow runs whenever any change hits on-chain state. The compliance transfer flow runs whenever tokens move between addresses. A deployed asset is a prerequisite for all capability flows: DAIO offerings, airdrops, treasury distributions, and XvP settlement each require one before you can configure them. The feeds update flow supplies validated values that contracts, adapters, the Platform API, and the Console read. DAIO, Airdrop, Treasury, and XvP are independent flows you configure separately per instrument.

## Next steps [#next-steps]

* [Flows section](/docs/architects/flows) for full walkthroughs of each flow
* [Components](/docs/architects/components) to understand the components referenced above
* [Feeds system](/docs/architects/components/infrastructure/feeds-system) for feed registration, trust model, and consumer reads
* [Security](/docs/compliance-security/security) for how authentication and compliance enforcement work across these flows
