# Overview Source: https://docs.settlemint.com/docs/architecture/flows Explanation of the main DALP operational flows, how platform flows support capability-specific workflows, and which flow page to read for signing, issuance, compliance transfers, data feeds, offerings, distributions, and XvP settlement. DALP flows show how a business request becomes a controlled platform operation. A flow starts when an operator or API client asks DALP to do something, then moves through orchestration, custody signing, on-chain enforcement, indexing, and monitoring until the operation completes or exposes a failure that operators can investigate. Use this overview to choose the right flow page before an architecture review, implementation plan, or incident review. The pages explain where the work starts, which DALP layer owns each control point, and which page to read next for signing, issuance, compliance transfer checks, data feeds, distributions, offerings, or XvP settlement. ## Operating model [#operating-model] The flow pages are explanation docs for architects, operators, and security reviewers. They show the systems involved in an operation, the control points each system owns, and the detail page to read next. They are not API reference pages and do not list every request field, screen, or contract event. Read this section when you need to answer four questions: * which DALP layer starts, coordinates, signs, enforces, indexes, or monitors an operation * where custody, compliance, indexing, feeds, distribution, or settlement logic enters the path * which flows are shared platform mechanics and which flows are business capabilities built on top * which component or security page to read before an implementation or diligence review ## Choose a flow [#choose-a-flow] | If you need to understand | Start with | Why | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | How DALP authorises and submits blockchain writes | [Signing flow](/docs/architecture/flows/signing-flow) | Every on-chain operation depends on custody signing, nonce handling, broadcast, and confirmation tracking. | | How a configured asset becomes a deployed token | [Asset issuance](/docs/architecture/flows/asset-issuance) | Issuance connects asset configuration, token controls, compliance setup, and initial supply. | | How identity and compliance rules affect movement | [Compliance transfer](/docs/architecture/flows/compliance-transfer) | Transfer checks show where identity, claim, and compliance modules can allow or reject movement. | | How signed values enter asset workflows | [Feeds update flow](/docs/architecture/flows/feeds-update-flow) | Feed updates explain validation, indexing, and use of current values by downstream flows. | | How investors subscribe to an offering | [DAIO offering](/docs/architecture/flows/daio-offering) | Offering flows add subscription, allocation, payment, and lock-up mechanics to the platform path. | | How tokens or payments are distributed after issuance | [Airdrop distribution](/docs/architecture/flows/airdrop-distribution) or [Treasury distribution](/docs/architecture/flows/treasury-distribution) | Distribution flows show batch delivery, eligibility, treasury balance, and investor payment movement. | | How delivery and payment obligations are coordinated | [XvP settlement](/docs/architecture/flows/xvp-settlement) | XvP settlement adds matching obligations, approvals, execution, and failure handling around delivery versus payment. | ## Flow map [#flow-map] Most flows follow the same operating path. An operator action or API request enters the platform, the Execution Engine coordinates the work, the signing layer applies custody controls, SMART Protocol contracts enforce token and compliance rules on EVM, and the indexer makes confirmed activity visible to the product and API surfaces. Capability flows reuse that path with their own business logic. A DAIO offering adds subscription and allocation steps. A treasury distribution adds asset treasury and investor payment steps. XvP settlement adds matching delivery and payment obligations. Feed updates add signed value validation before consumers read the latest value. ## Platform flows [#platform-flows] Platform flows are the reusable sequences that other DALP workflows depend on. They describe the common path through the Asset Console or Unified API, the execution runtime, custody providers, the SMART Protocol, and the indexer. | Flow | Trigger | What it explains | | ------------------------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------------------- | | [Signing flow](/docs/architecture/flows/signing-flow) | Any blockchain write operation | How a transaction is authorised, signed by custody, and broadcast | | [Asset issuance](/docs/architecture/flows/asset-issuance) | Issuer creates a new digital asset | How DALP creates the token, configures controls, and mints supply | | [Compliance transfer](/docs/architecture/flows/compliance-transfer) | Token holder initiates transfer | How a transfer is checked against identity and compliance rules | | [Feeds update flow](/docs/architecture/flows/feeds-update-flow) | Issuer publishes signed price data | How signed price data becomes validated, indexed, and available to use | Start with the [signing flow](/docs/architecture/flows/signing-flow) when you are reviewing transaction execution. Start with [asset issuance](/docs/architecture/flows/asset-issuance) when you are reviewing how an asset moves from configuration to a deployed token. Use [compliance transfer](/docs/architecture/flows/compliance-transfer) when the question is whether a movement can pass identity and compliance controls. ## Capability flows [#capability-flows] Capability flows compose the platform flows with business-specific logic. They are useful when you need to explain an investor, treasury, settlement, or distribution process end to end. | Flow | Trigger | What it explains | | ----------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------- | | [DAIO offering](/docs/architecture/flows/daio-offering) | Issuer opens a Digital Asset Initial Offering | How subscriptions, allocations, payment, and lock-up fit together | | [Airdrop distribution](/docs/architecture/flows/airdrop-distribution) | Issuer initiates airdrop to a holder list | How DALP distributes tokens to eligible wallets in batches | | [Treasury distribution](/docs/architecture/flows/treasury-distribution) | Scheduled or manual distribution trigger | How treasury payments move from asset treasury to investors | | [XvP settlement](/docs/architecture/flows/xvp-settlement) | Settlement instruction submitted | How DALP coordinates token delivery against payment between parties | Read capability flows after the platform flow they depend on. XvP settlement depends on transaction signing and compliance checks. Treasury distribution depends on asset state, investor eligibility, and payment execution. DAIO offering depends on the platform path plus subscription, allocation, payment, and lock-up steps. ## Operational ownership [#operational-ownership] | Layer | Owns | Read next | | ---------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Asset Console | Operator initiation, review screens, and visible workflow state | [User guides](/docs/user-guides/introduction) | | Unified API | Programmatic requests, caller permissions, and API responses | [Unified API](/docs/architecture/components/platform/unified-api) | | Execution Engine | Multi-step orchestration, durable workflow state, and retries | [DALP Execution Engine](/docs/architecture/components/infrastructure/execution-engine) | | Transaction Signer | Transaction assembly, nonce handling, signing requests, and broadcast | [Signing flow](/docs/architecture/flows/signing-flow) | | Custody provider | Key control, policy approval, quorum approval, and signed transaction output | [Key Guardian](/docs/architecture/components/infrastructure/key-guardian) | | SMART Protocol | Token, identity, compliance, and settlement enforcement on EVM | [SMART Protocol integration](/docs/architecture/components/asset-contracts/smart-protocol-integration) | | Chain Indexer | Confirmed event ingestion and API or dapp read models | [Chain Indexer](/docs/architecture/data-availability/chain-indexer) | | Observability surfaces | Health, failure, and evidence review for operations | [Observability](/docs/architecture/operability/observability) | This split helps incident review. A failed operation can be a request problem, an orchestration problem, a signing problem, an on-chain validation problem, or an indexing problem. Use the flow page to locate the layer first, then inspect the relevant logs, API response, component page, or monitoring surface. If the failure happens before signing, start with the Asset Console, Unified API, or Execution Engine. If signing succeeded but the product view is stale, start with the SMART Protocol transaction status and Chain Indexer. ## What stays external [#what-stays-external] DALP coordinates and records the platform operation. External providers and the operator organisation still own the systems they bring to the workflow: custody provider policy configuration, EVM network availability, payment rail settlement, bank ledger reconciliation, and any legal or regulatory decision that sits outside the token platform. ## Related architecture pages [#related-architecture-pages] * [DALP Execution Engine](/docs/architecture/components/infrastructure/execution-engine) explains the orchestration runtime used by multi-step flows. * [SMART Protocol integration](/docs/architecture/components/asset-contracts/smart-protocol-integration) explains the on-chain enforcement model. * [Unified API](/docs/architecture/components/platform/unified-api) explains the programmatic entry point for triggering flows. * [Observability](/docs/architecture/operability/observability) explains how operators monitor flow health and failures.