# Architecture one-pager Source: https://docs.settlemint.com/docs/architects/overview/architecture-one-pager All eight DALP systems, their sub-components, and their external dependencies on one page, formatted for RFP, security, and integration reviews. Read this after the [architecture overview](/docs/architects/overview) when your review asks which system owns a specific decision. The map gives each area a clear owner: operator workspaces, API calls, transaction lifecycle, compliance checks, signing, pricing, on-chain enforcement, indexed evidence, and shared platform services. ## The short version [#the-short-version] Eight systems run the platform. Operators, compliance teams, treasury, and integrators work in the Operations Console, which drives one Platform API. The Transaction Lifecycle Engine runs every write end to end: it checks each transfer with Compliance & Identity, signs through Custody & Settlement, prices with Market Data, and writes to the Asset Registry contracts on your selected EVM network. The Ledger Index reads chain events back for query and audit, and the Core Platform carries all of it. Three points matter in most reviews: 1. DALP is EVM-focused. It does not make non-EVM chains native DALP execution environments. 2. DALP keeps workflow authorisation, transaction signing, and on-chain compliance in separate systems rather than treating any one system as the whole control plane. 3. DALP stores operational data off chain for workflow and review, while asset ownership and rule enforcement live in smart contracts on your selected EVM network. ## How to read the architecture in a review [#how-to-read-the-architecture-in-a-review] Start with the system that owns the decision you are checking. A request enters through the Operations Console or the Platform API and moves through the Transaction Lifecycle Engine. The Workflow Engine gates each transfer through the Compliance Engine, which reaches your compliance and KYC providers where configured. It signs through Key Management under custody-provider policy, prices with Market Data feeds, and broadcasts through your EVM RPC provider to the SMART Protocol contracts in the Asset Registry. The Ledger Index turns emitted events into the read model the Platform API serves, and Event Delivery streams confirmations and webhooks to downstream consumers. The Core Platform carries the data platform, observability, document storage, and shared libraries under all of it. Use that flow to make procurement and security reviews concrete: | Review topic | Architectural question | Primary docs path | | ------------------------------------ | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Bank-grade platform architecture | Which system owns user requests, workflow state, signing, on-chain enforcement, and data? | [System context](/docs/architects/overview/system-context) and [Components](/docs/architects/components) | | Privacy on public networks | Which data is on chain, and which data stays in DALP or external systems? | [Public chain privacy](/docs/compliance-security/privacy/overview) | | Replay, retries, and idempotency | How does DALP coordinate state-changing work before and after signing? | [Signing flow](/docs/architects/flows/signing-flow) and [workflow engine recovery](/docs/developers/operations/workflow-engine-recovery) | | Auditability and source verification | How can a reviewer trace deployed contracts, events, and transaction history? | [Source verification and deployment auditability](/docs/compliance-security/source-verification/overview) | | Hosting, backup, and recovery | Which responsibilities belong to DALP services, the deployment model, and the operator? | [Deployment topology](/docs/architects/overview/deployment-topology) and [Operability](/docs/architects/operability) | ## What runs inside DALP [#what-runs-inside-dalp] | System | Responsibility | Review question it answers | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Operations Console | Browser workspace for issuers, operators, compliance reviewers, and asset servicing users: console, identity & access, developer platform, and deployment | How do business users and platform operators work with the platform? | | Transaction Lifecycle Engine | One Platform API plus the transaction queue, workflow engine, broadcast, confirmation tracking, and event delivery that run every write end to end | What coordinates a transaction from API call to confirmed on-chain state? | | Compliance & Identity | Compliance engine, identity registry, KYC / AML orchestration, and claim issuance that gate every transfer | What decides whether a transfer is allowed, and on which identity evidence? | | Custody & Settlement | Key management, vaults, settlement, and distribution, enforcing custody-provider signing policy | Who controls signing policy and quorum decisions? | | Market Data | Price feeds and FX rates that value and settle assets | Where do prices and rates come from? | | Asset Registry | SMART Protocol contracts, asset classes, and the control plane on your selected EVM network | What enforces token state and transfer controls on chain? | | Ledger Index | Indexing pipeline, read model, and change data capture that turn chain events into queryable evidence | How does chain activity become searchable operational evidence? | | Core Platform | Data platform, observability, document storage, and core libraries that carry the other seven systems | Which shared services keep the platform operable and auditable? | ## Control responsibilities [#control-responsibilities] DALP checks each request through a series of gates before it proceeds. | Responsibility area | What DALP checks | Where to continue | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Identity and access | Sessions, API credentials, roles, organisation scope, and resource permissions | [Authentication](/docs/compliance-security/security/authentication) and [Authorization](/docs/compliance-security/security/authorization) | | Operator confirmation | Wallet verification for browser-session blockchain writes where confirmation is required | [Wallet verification](/docs/compliance-security/security/wallet-verification) | | Execution and signing | Workflow state, transaction preparation, nonce handling, signer routing, and custody-provider policy | [Signing flow](/docs/architects/flows/signing-flow) and [Custody providers](/docs/architects/integrations/custody-providers) | | On-chain asset rules | Identity claims, compliance modules, asset policy, transfer approval, caps, and time-based restrictions where configured | [Identity and compliance](/docs/compliance-security/security/identity-compliance) and [Compliance modules](/docs/compliance-security/compliance) | | Audit and recovery evidence | Deployment addresses, source verification, indexed events, and transaction history | [Source verification and deployment auditability](/docs/compliance-security/source-verification/overview) | This split matters when you review as an auditor: * Authentication proves who is calling. * Authorization decides whether the caller may perform the requested operation. * Signing policy decides whether a transaction can be signed. * SMART Protocol contracts decide whether a state change is valid on chain. ## Deployment responsibilities [#deployment-responsibilities] DALP can run in managed, customer-hosted, hybrid, private-chain, and restricted-network patterns depending on the operating model. The division is consistent across patterns: DALP services operate the eight systems in the diagram. The selected EVM network, custody provider, RPC service, identity sources, pricing sources, payment rails, and operational approvals remain explicit dependencies. For hosting, networking, high availability, backup, recovery, or restricted-network detail, continue to [Deployment topology](/docs/architects/overview/deployment-topology) and [Operability](/docs/architects/operability) for your context. ## Reader paths [#reader-paths] | If you are... | Start here | Then read | | --------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | An integrating developer | [Platform API](/docs/architects/components/platform/platform-api) | [Signing flow](/docs/architects/flows/signing-flow) and [Key flows](/docs/architects/overview/key-flows) | | A platform operator | [Admin operating model](/docs/developers/platform-setup/admin-operating-model) | [Platform role provisioning](/docs/developers/platform-setup/add-admins), [administrator role changes](/docs/developers/platform-setup/change-admin-roles), and [Operator wallets](/docs/operators/platform-setup/operator-wallets) | | A security reviewer | [Security overview](/docs/compliance-security/security) | [Public chain privacy](/docs/compliance-security/privacy/overview), [Compliance and custody split](/docs/compliance-security/security/compliance-custody-boundary), and [Source verification](/docs/compliance-security/source-verification/overview) | | A platform architect | [System context](/docs/architects/overview/system-context) | [Deployment topology](/docs/architects/overview/deployment-topology) and [Operability](/docs/architects/operability) | | An auditor or compliance reviewer | [Identity and compliance](/docs/compliance-security/security/identity-compliance) | [Compliance modules](/docs/compliance-security/compliance) and [Compliance transfer flow](/docs/architects/flows/compliance-transfer) | ## What this page does not claim [#what-this-page-does-not-claim] DALP does not make every external system part of its native platform control. Custody-provider quorum rules, bridge design, liquidity venues, payment rails, source data methodology, public-network validator behaviour, non-EVM execution environments, and physical-asset reserve attestations each need their own review. DALP integrates with selected external systems where configured, but that integration is not the same as native platform control.