# Architecture documentation

Source: https://docs.settlemint.com/docs/architects
Choose the right DALP architecture guide for the platform map, design
principles, concepts, components, flows, integrations, data availability,
operability, and self-hosting decisions.




Use these guides if you are a solution lead, architect, or review team member scoping DALP for a regulated digital asset deployment. Solution leads map the platform onto a target operating model. Architects inspect components and the seams between them. Reviewers confirm who operates what, how recovery is planned, and where the platform surfaces evidence before approval.

Start with the architecture map for the overall layout and principles. Then pick by need: concepts for the mental model, components for the layer catalog, flows for end-to-end paths, integrations for external systems, data availability for read-side consistency, operability for the production posture, or self-hosting for cluster setup.

<Mermaid
  chart="`
flowchart TD
Reader[&#x22;Solution lead or architect&#x22;] --> Map[&#x22;Architecture map&#x22;]
Reader --> Components[&#x22;Component layers&#x22;]
Reader --> Flows[&#x22;Operational flows&#x22;]
Reader --> Production[&#x22;Production architecture&#x22;]
Map --> Principles[&#x22;Principles, scope, quality attributes&#x22;]
Components --> Layers[&#x22;Platform, infrastructure, asset contracts, capabilities&#x22;]
Flows --> Paths[&#x22;Signing, issuance, compliance, settlement, distribution&#x22;]
Production --> Deploy[&#x22;Integrations, data availability, operability, self-hosting&#x22;]
`"
/>

DALP defines the platform layers, contract architecture, integration seams, indexed read models, operability posture, and the self-hosting reference documented here. Your organisation sets the target operating model, topology, vendor choices, recovery targets, network policy, and governance.

These guides cover the current platform architecture. They do not commit to legal opinions, custody arrangements, SLA terms, non-EVM deployment support, or vendor choices. Treat those as organisation-specific decisions unless a detail page states the DALP behaviour explicitly.

## What DALP covers [#what-dalp-covers]

DALP separates user surfaces, execution services, asset contracts, indexed reads, and integration seams so a reviewer can find which layer owns each decision. The guides explain each layer, its interfaces, the paths that connect them, and the operating posture a self-hosted cluster inherits.

| Area            | DALP defines                                                                                  | Your organisation defines                                                                                  |
| --------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Platform layers | Console, Platform API, Transaction Lifecycle Engine, SMART Protocol contracts, Ledger Index   | Network policy, exposed routes, tenancy choices, and operator access                                       |
| Flows           | Signing, issuance, compliance transfer, feed update, offerings, distributions, XvP settlement | Approval chains, custody policy, settlement counterparties, and operating procedures                       |
| Integrations    | Documented seams for custody, compliance, networks, market data, storage, and observability   | Vendor selection, contractual terms, provider configuration, and integration ownership                     |
| Operability     | Telemetry, PostgreSQL persistence, workflow durability, failure-mode behaviour                | Recovery targets, HA pattern selection, backup retention, and on-call coverage                             |
| Exclusions      | Documented platform behaviour and supported deployment surfaces                               | Legal opinions, SLA commitments, custody arrangements, bridge operations, and non-EVM deployment decisions |

## Pick the right path [#pick-the-right-path]

| If you need to...                        | Start here                                                                         | Then read                                                                                                                                                                                                                                                               |
| ---------------------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Read the architecture end to end         | [Architecture overview](/docs/architects/overview)                                 | [System context](/docs/architects/overview/system-context), then follow the Overview pages in order down to [Data domains](/docs/architects/overview/data-domains)                                                                                                      |
| Look up a fact for an RFP or review      | [Architecture one-pager](/docs/architects/overview/architecture-one-pager)         | [Capability docs matrix](/docs/architects/overview/capability-docs-matrix) to find the page that answers a named capability                                                                                                                                             |
| Review architecture principles and scope | [Architecture overview](/docs/architects/overview)                                 | [Principles and scope](/docs/architects/overview/principles-and-scope) and [Quality attributes](/docs/architects/overview/quality-attributes)                                                                                                                           |
| Build the mental model for the platform  | [Concepts: tokenization modeling](/docs/architects/concepts/tokenization-modeling) | [Claims and identity](/docs/architecture/concepts/claims-and-identity) and [Asset policy](/docs/architecture/concepts/asset-policy)                                                                                                                                     |
| Inspect a specific component layer       | [Component catalog](/docs/architects/components)                                   | The platform, infrastructure, asset contracts, token features, and capabilities pages                                                                                                                                                                                   |
| Walk a flow from request to settlement   | [Flows overview](/docs/architects/flows)                                           | [Signing flow](/docs/architects/flows/signing-flow), [Asset issuance](/docs/architects/flows/asset-issuance), and [Compliance transfer](/docs/architects/flows/compliance-transfer)                                                                                     |
| Decide an integration surface            | [Integration overview](/docs/architects/integrations)                              | [Custody providers](/docs/architects/integrations/custody-providers) and [Compliance providers](/docs/architects/integrations/compliance-providers)                                                                                                                     |
| Reason about read-side consistency       | [Data availability overview](/docs/architects/data-availability)                   | [Ledger Index](/docs/architects/data-availability/chain-indexer)                                                                                                                                                                                                        |
| Plan production operability              | [Operability overview](/docs/architects/operability)                               | [Observability](/docs/architects/operability/observability), [Database](/docs/architects/operability/database), [Failure modes](/docs/architects/operability/failure-modes), and [Backup and recovery](/docs/architects/self-hosting/high-availability/backup-recovery) |
| Deploy on Kubernetes or OpenShift        | [Self-hosting overview](/docs/architects/self-hosting)                             | [Prerequisites](/docs/architects/self-hosting/prerequisites), [Installation process](/docs/architects/self-hosting/installation-process), and [High availability](/docs/architects/self-hosting/high-availability)                                                      |

## Architecture model [#architecture-model]

DALP exposes four architecture-facing layers:

* The platform layer is where operators and external integrations enter the system through the Console, the Platform API, and the System Factory.
* The infrastructure layer coordinates execution services: it preserves workflows, prepares EVM transactions, routes signing, submits chain operations, and indexes events.
* The asset contracts layer enforces token rules on EVM networks through SMART Protocol contracts, identity claims, and compliance modules.
* The capabilities and token features layers add focused workflows around the asset: distribution, settlement, treasury, market data, governance, and yield.

Most reviews touch all four layers. Use the start-here pages for an evaluator overview, then route to the layer or path your review needs. See [Developer guides](/docs/developers) for API integration work and [Compliance and security](/docs/compliance-security) for control evidence.

## Start here [#start-here]

<Cards>
  <Card title="Architecture map" href="/docs/architects/overview">
    Navigate the architecture documentation by platform layer and reader goal. Start here when you need the overall layout before drilling into a specific area.
  </Card>

  <Card title="Architecture one-pager" href="/docs/architects/overview/architecture-one-pager">
    Reference: the buyer-safe DALP platform map on one page for RFP, security, and integration lookups.
  </Card>

  <Card title="Capability docs matrix" href="/docs/architects/overview/capability-docs-matrix">
    Reference: find the documentation page that answers a named capability during a review. Use it when an RFP or security questionnaire names a specific feature and you need the exact evidence page.
  </Card>

  <Card title="Asset tokenization architecture" href="/docs/architects/overview/asset-model">
    See how DALP structures institutional asset tokenization end to end. The page covers asset classes, templates, factories, and the deployed contract model.
  </Card>

  <Card title="System context" href="/docs/architects/overview/system-context">
    Identify external actors, operating scopes, trust relationships, and contract layers. Use this page to confirm which boundary each actor operates across.
  </Card>

  <Card title="Lifecycle after issuance" href="/docs/architects/overview/lifecycle-after-issuance">
    Read the operating model for managing an issued DALP asset. The page covers dividend events, compliance updates, yield, distributions, and secondary transfers.
  </Card>

  <Card title="Key flows" href="/docs/architects/overview/key-flows">
    Index the main DALP system flows from signing to settlement. Each flow links to a detailed walkthrough of the steps, components, and failure modes involved.
  </Card>

  <Card title="Glossary" href="/docs/architects/glossary">
    Reference definitions for DALP terminology across SMART Protocol, OnchainID, and execution.
  </Card>
</Cards>

## Architecture overview [#architecture-overview]

<Cards>
  <Card title="Overview" href="/docs/architects/overview">
    Read the DALP architecture overview for solution leads and reviewers. The overview introduces the platform structure and links to every major guide section.
  </Card>

  <Card title="Principles and scope" href="/docs/architects/overview/principles-and-scope">
    Inspect the architecture choices DALP makes and the decisions that remain with the deploying organisation. Reviewers use this page to map responsibilities before approval.
  </Card>

  <Card title="Quality attributes" href="/docs/architects/overview/quality-attributes">
    Review security, reliability, operability, data consistency, performance, and evidence posture. Use this page when a review asks how the platform meets a specific quality requirement.
  </Card>

  <Card title="Deployment topology" href="/docs/architects/overview/deployment-topology">
    See runtime zones, network paths, EVM access, custody dependencies, and recovery points. This page maps the zones an operator controls from the zones DALP manages.
  </Card>

  <Card title="Data domains" href="/docs/architects/overview/data-domains">
    Map which records are on-chain, off-chain, indexed, and who owns each governance decision. Auditors use this page to trace data residency and retention for each record type.
  </Card>
</Cards>

## Concepts [#concepts]

<Cards>
  <Card title="Advanced accounts" href="/docs/operators/platform-setup/advanced-accounts-control-center">
    Review the operator controls for advanced accounts, smart-account routing, and gas sponsorship. The page covers the settings that enable gasless transactions and multi-approver flows.
  </Card>

  <Card title="UserOperations" href="/docs/architects/components/infrastructure/advanced-accounts/user-operations">
    See how UserOperations move through smart wallets, bundlers, and the EntryPoint. The page traces validation, gas sponsorship checks, and execution sequencing.
  </Card>

  <Card title="Bundlers" href="/docs/architects/components/infrastructure/advanced-accounts/bundlers">
    Read how DALP uses bundler-compatible discovery behind the platform execution path. The page covers the JSON-RPC endpoint, simulation, and UserOperation submission.
  </Card>

  <Card title="Paymasters and gas sponsorship" href="/docs/architects/components/infrastructure/advanced-accounts/paymasters-and-gas-sponsorship">
    Sponsor eligible advanced accounts transactions without changing identity or asset policy.
  </Card>

  <Card title="Claims and identity" href="/docs/architecture/concepts/claims-and-identity">
    Connect participant wallets, OnchainID claims, trusted issuers, and compliance expressions. The platform evaluates this chain before every regulated token operation.
  </Card>

  <Card title="Asset policy" href="/docs/architecture/concepts/asset-policy">
    Combine identity, compliance modules, lifecycle hooks, and governance into per-asset policy. The platform evaluates the full policy on each token operation and enforces it on-chain.
  </Card>

  <Card title="Tokenization modeling" href="/docs/architects/concepts/tokenization-modeling">
    Turn an asset class and template into token metadata, features, and compliance rules.
  </Card>
</Cards>

## Components [#components]

<Cards>
  <Card title="Component catalog" href="/docs/architects/components">
    Find the component layer that owns an architecture decision or evidence trail. Each entry names the layer's responsibilities and links to the detail page.
  </Card>

  <Card title="Platform layer" href="/docs/architects/components/platform">
    Review the Console, Platform API, and System Factory entry surfaces. Operators and external integrations enter the system at these surfaces.
  </Card>

  <Card title="Infrastructure layer" href="/docs/architects/components/infrastructure">
    Inspect execution services that prepare EVM transactions, route signing, and index events.
  </Card>

  <Card title="Asset contracts" href="/docs/architects/components/asset-contracts">
    Read the SMART Protocol contract layer that enforces token rules on EVM networks. The page covers compliance modules, identity hooks, and upgrade paths.
  </Card>

  <Card title="Token features" href="/docs/architects/components/token-features">
    Attach fees, governance, lifecycle, yield, permit, and conversion behaviour to assets.
  </Card>

  <Card title="Capabilities" href="/docs/architects/components/capabilities">
    Add focused add-on workflows for distribution, settlement, treasury, sales, and feeds. Each add-on registers through the Addon Registry.
  </Card>
</Cards>

## Flows [#flows]

<Cards>
  <Card title="Flows overview" href="/docs/architects/flows">
    See how a business request becomes a controlled platform operation.
  </Card>

  <Card title="Signing flow" href="/docs/architects/flows/signing-flow">
    Walk an EVM transaction from request through compliance simulation, custody signing, and broadcast. The page covers each step the platform takes, including retry and failure handling.
  </Card>

  <Card title="Asset issuance" href="/docs/architects/flows/asset-issuance">
    Follow asset deployment from instrument configuration through factory execution to first operations.
  </Card>

  <Card title="Compliance transfer" href="/docs/architects/flows/compliance-transfer">
    Step through identity, module, and policy checks before a token transfer executes. The page shows what the platform evaluates and what triggers a rejection.
  </Card>

  <Card title="Feeds update flow" href="/docs/architects/flows/feeds-update-flow">
    See how issuer-signed feed updates reach the platform and contracts that use them.
  </Card>

  <Card title="Treasury distribution" href="/docs/architects/flows/treasury-distribution">
    See how treasury distributions move from operator configuration to investor wallets, covering both airdrop and yield paths.
  </Card>

  <Card title="XvP settlement" href="/docs/architects/flows/xvp-settlement">
    Coordinate multi-party asset exchanges through local or HTLC settlement.
  </Card>
</Cards>

## Integrations [#integrations]

<Cards>
  <Card title="Integration overview" href="/docs/architects/integrations">
    Review supported integration surfaces and operator-configurable seams. The platform defines the contract; your organisation selects and configures each provider.
  </Card>

  <Card title="Custody providers" href="/docs/architects/integrations/custody-providers">
    Connect DFNS, Fireblocks, Luna HSM, browser wallets, and provider approval policy. The page covers the signing delegation model and fallback behaviour.
  </Card>

  <Card title="Compliance providers" href="/docs/architects/integrations/compliance-providers">
    Onboard identity, business, AML, and wallet-monitoring providers as on-chain claims. Each provider maps to a claim topic and a trusted issuer registration.
  </Card>

  <Card title="Supported networks" href="/docs/architects/integrations/supported-networks">
    Configure built-in viem chains and custom EVM networks with RPC and finality controls.
  </Card>
</Cards>

## Data availability [#data-availability]

<Cards>
  <Card title="Data availability overview" href="/docs/architects/data-availability">
    Understand how EVM events become queryable platform state and where reads can lag. Architects use this page to reason about indexing latency and stale-read conditions.
  </Card>

  <Card title="Ledger Index" href="/docs/architects/data-availability/chain-indexer">
    Inspect how checkpoints, finality, reorg handling, and reindexing affect indexed reads. The page explains what the Ledger Index guarantees and where it can fall behind.
  </Card>
</Cards>

## Operability [#operability]

<Cards>
  <Card title="Operability overview" href="/docs/architects/operability">
    Map telemetry, PostgreSQL persistence, durability, HA handoffs, and failure behaviour. Operators use this page to understand what the platform monitors and where it degrades gracefully.
  </Card>

  <Card title="Observability" href="/docs/architects/operability/observability">
    Run the observability stack with metrics, logs, traces, and Grafana dashboards. The page maps each signal to the component that emits it.
  </Card>

  <Card title="Database" href="/docs/architects/operability/database">
    Configure PostgreSQL connection control, TLS, pooling, and health checks.
  </Card>

  <Card title="Failure modes" href="/docs/architects/operability/failure-modes">
    Review how the platform degrades and recovers when dependencies are unavailable. The page names which operations stall and which continue with cached state.
  </Card>
</Cards>

## Self-hosting [#self-hosting]

<Cards>
  <Card title="Self-hosting overview" href="/docs/architects/self-hosting">
    Deploy DALP in your own Kubernetes or OpenShift infrastructure. This page covers what self-hosting includes, the installation path, and the operator responsibilities it creates.
  </Card>

  <Card title="Prerequisites" href="/docs/architects/self-hosting/prerequisites">
    Check the infrastructure, service, network, and credential requirements before starting an installation.
  </Card>

  <Card title="Installation process" href="/docs/architects/self-hosting/installation-process">
    Walk through SettleMint-managed installation phases for self-hosted deployments. The page covers each phase, the steps the operator must complete, and the verification checks at each gate.
  </Card>

  <Card title="OpenShift installation" href="/docs/architects/self-hosting/openshift-installation">
    Deploy DALP on OpenShift with restricted SCCs, Routes, and CSI-backed storage.
  </Card>

  <Card title="High availability" href="/docs/architects/self-hosting/high-availability">
    Choose an HA and disaster recovery pattern with documented recovery metrics.
  </Card>
</Cards>