Architecture documentation
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.
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
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
| If you need to... | Start here | Then read |
|---|---|---|
| Read the architecture end to end | Architecture overview | System context, then follow the Overview pages in order down to Data domains |
| Look up a fact for an RFP or review | Architecture one-pager | Capability docs matrix to find the page that answers a named capability |
| Review architecture principles and scope | Architecture overview | Principles and scope and Quality attributes |
| Build the mental model for the platform | Concepts: tokenization modeling | Claims and identity and Asset policy |
| Inspect a specific component layer | Component catalog | The platform, infrastructure, asset contracts, token features, and capabilities pages |
| Walk a flow from request to settlement | Flows overview | Signing flow, Asset issuance, and Compliance transfer |
| Decide an integration surface | Integration overview | Custody providers and Compliance providers |
| Reason about read-side consistency | Data availability overview | Ledger Index |
| Plan production operability | Operability overview | Observability, Database, Failure modes, and Backup and recovery |
| Deploy on Kubernetes or OpenShift | Self-hosting overview | Prerequisites, Installation process, and High availability |
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 for API integration work and Compliance and security for control evidence.
Start here
Navigate the architecture documentation by platform layer and reader goal. Start here when you need the overall layout before drilling into a specific area.
Reference: the buyer-safe DALP platform map on one page for RFP, security, and integration lookups.
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.
See how DALP structures institutional asset tokenization end to end. The page covers asset classes, templates, factories, and the deployed contract model.
Identify external actors, operating scopes, trust relationships, and contract layers. Use this page to confirm which boundary each actor operates across.
Read the operating model for managing an issued DALP asset. The page covers dividend events, compliance updates, yield, distributions, and secondary transfers.
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.
Reference definitions for DALP terminology across SMART Protocol, OnchainID, and execution.
Architecture overview
Read the DALP architecture overview for solution leads and reviewers. The overview introduces the platform structure and links to every major guide section.
Inspect the architecture choices DALP makes and the decisions that remain with the deploying organisation. Reviewers use this page to map responsibilities before approval.
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.
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.
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.
Concepts
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.
See how UserOperations move through smart wallets, bundlers, and the EntryPoint. The page traces validation, gas sponsorship checks, and execution sequencing.
Read how DALP uses bundler-compatible discovery behind the platform execution path. The page covers the JSON-RPC endpoint, simulation, and UserOperation submission.
Sponsor eligible advanced accounts transactions without changing identity or asset policy.
Connect participant wallets, OnchainID claims, trusted issuers, and compliance expressions. The platform evaluates this chain before every regulated token operation.
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.
Turn an asset class and template into token metadata, features, and compliance rules.
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.
Review the Console, Platform API, and System Factory entry surfaces. Operators and external integrations enter the system at these surfaces.
Inspect execution services that prepare EVM transactions, route signing, and index events.
Read the SMART Protocol contract layer that enforces token rules on EVM networks. The page covers compliance modules, identity hooks, and upgrade paths.
Attach fees, governance, lifecycle, yield, permit, and conversion behaviour to assets.
Add focused add-on workflows for distribution, settlement, treasury, sales, and feeds. Each add-on registers through the Addon Registry.
Flows
See how a business request becomes a controlled platform operation.
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.
Follow asset deployment from instrument configuration through factory execution to first operations.
Step through identity, module, and policy checks before a token transfer executes. The page shows what the platform evaluates and what triggers a rejection.
See how issuer-signed feed updates reach the platform and contracts that use them.
See how treasury distributions move from operator configuration to investor wallets, covering both airdrop and yield paths.
Coordinate multi-party asset exchanges through local or HTLC settlement.
Integrations
Review supported integration surfaces and operator-configurable seams. The platform defines the contract; your organisation selects and configures each provider.
Connect DFNS, Fireblocks, Luna HSM, browser wallets, and provider approval policy. The page covers the signing delegation model and fallback behaviour.
Onboard identity, business, AML, and wallet-monitoring providers as on-chain claims. Each provider maps to a claim topic and a trusted issuer registration.
Configure built-in viem chains and custom EVM networks with RPC and finality controls.
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.
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.
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.
Run the observability stack with metrics, logs, traces, and Grafana dashboards. The page maps each signal to the component that emits it.
Configure PostgreSQL connection control, TLS, pooling, and health checks.
Review how the platform degrades and recovers when dependencies are unavailable. The page names which operations stall and which continue with cached state.
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.
Check the infrastructure, service, network, and credential requirements before starting an installation.
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.
Deploy DALP on OpenShift with restricted SCCs, Routes, and CSI-backed storage.
Choose an HA and disaster recovery pattern with documented recovery metrics.