Architecture map
Navigate the DALP architecture documentation by platform layer, reader goal, and integration question.
DALP architecture is easiest to review as a chain of responsibility: request, execution, enforcement, evidence. Operators and integrations start work through the Asset Console or Unified API. The Execution Engine coordinates the transaction path. SMART Protocol contracts enforce configured controls on EVM. The Chain Indexer turns confirmed events into the state used by dashboards, APIs, reports, and operational review.
Platform at a glance
Operators and integrations use the Asset Console or Unified API to start asset, compliance, servicing, and settlement workflows. The DALP Execution Engine coordinates durable operations and signing before state-changing actions reach SMART Protocol contracts. The Chain Indexer makes confirmed on-chain events queryable again, while the Feeds system supplies market data to platform services and contracts that need pricing inputs.
The responsibility split is deliberate:
| Layer | DALP covers | Operator or external systems own |
|---|---|---|
| Interface | Asset Console screens and Unified API entry points for asset, compliance, servicing, and settlement operations | User access policy, approval process, and the systems that call the API |
| Execution | Workflow orchestration, transaction preparation, signing handoff, retries, and transaction status tracking | Custody-provider policy decisions, quorum rules, and off-platform operational approvals |
| Blockchain | SMART Protocol contracts, asset state, identity checks, compliance modules, and configured transfer controls | External bridge, liquidity, redemption, wallet, and chain-validator risk outside the selected EVM networks |
| Evidence | Chain event indexing, API read models, dashboard state, reports, and monitoring inputs | Review process, evidence retention policy, and reconciliation against off-platform records |
| Market data | Feed registration, signed updates, adapter reads, and indexed price data for configured feed topics | Source data selection, pricing methodology, and issuer or provider attestation outside DALP |
This section explains how DALP is structured and where to continue reading. It does not replace the integration, security, or operability pages when you need provider setup, deployment controls, payment-rail design, accounting workflows, or detailed threat review.
This architecture map has four practical takeaways:
- Asset and compliance operations start through a user or API surface, then move through orchestration before on-chain execution.
- SMART Protocol contracts hold the on-chain asset state and enforce transfer compliance where the configured rules apply.
- The Chain Indexer turns confirmed contract activity into operational evidence and read-side visibility.
- Market data is a supporting service, not the only path through the platform.
Required system model
Before you configure, integrate, or audit DALP, treat the platform as a layered asset system, not one undifferentiated application. The model to hold is:
| Work to do | System model you need first | Why it matters |
|---|---|---|
| Configure assets or compliance controls | A DALP system groups assets, identities, roles, compliance modules, trusted issuers, feeds, and factory registries. An issued asset belongs to that system and inherits the controls configured for the system and the asset. | Configuration choices only make sense when you know which controls are system-scoped and which settings belong to the asset. |
| Integrate through APIs or external systems | Requests enter through the Asset Console or Unified API, pass through the Execution Engine for orchestration and signing handoff, then reach SMART Protocol contracts for on-chain state changes. Custody providers, wallets, price sources, and chain infrastructure remain external dependencies. | Integrations must send the right request to the right layer and keep provider, wallet, feed, and chain responsibilities outside DALP. |
| Audit security, compliance, or operations | DALP separates pre-transaction access checks, orchestration controls, custody-provider policy, on-chain compliance enforcement, indexing, market-data inputs, and observability. | Audits need to trace each control to the layer that enforces it instead of treating DALP as one application with one control plane. |
Read System context to place the system scope, Asset model to understand how asset classes, templates, token features, and compliance rules fit together, and Key flows to trace operations across layers.
Choose the right starting point
| Reader question | Start with | Then read |
|---|---|---|
| What is the one-page architecture story for an RFP or security call? | Architecture one-pager | Events catalogue, System context, and Deployment topology |
| What is inside DALP, and what stays external? | System context | Components, Integrations, and Capability docs matrix |
| How do asset class, template, features, and compliance fit together? | Asset model | Tokenization modeling, Asset issuance, and Token features |
| What changes after an asset is issued? | Lifecycle after issuance | Asset detail workspace and Token lifecycle API |
| Which platform operations should a reviewer trace first? | Key flows | Flows and Security |
| Which operational model supports production deployment and review? | Overview | Operability and Deployment topology |
| Which self-hosting pages should an infrastructure team read first? | Self-hosting | Prerequisites, installation process, and high availability |
Architecture sections
| Section | Covers | Use it when |
|---|---|---|
| Start Here | System context, asset model, lifecycle after issuance, key flows, and glossary | You are orienting a new architect or reviewer |
| Overview | Principles, quality attributes, deployment topology, and data domains | You are evaluating platform fit or planning capacity |
| Components | Platform components and responsibility boundaries | You need the owner and integration role of a component |
| Flows | Asset issuance, signing, transfers, feeds, and settlement sequences | You are tracing one operation across platform layers |
| Integrations | External systems, custody providers, compliance providers, and supported networks | You are assessing third-party dependencies or provider handoffs |
| Security | Authentication, authorisation, identity compliance, wallet verification, custody | You are preparing a security review, audit, or control map |
| Operability | Observability model, database architecture, and failure modes | You are reviewing operational readiness or incident preparation |
| Self-hosting | Deployment prerequisites, installation process, OpenShift, and high availability | You are planning infrastructure, environment sizing, or hosting |
Suggested reading paths
First-time orientation:
- Start Here (this page)
- System context
- Asset model
- Tokenization modeling
- Lifecycle after issuance
- Key flows
- Overview
Capability lookup: Capability docs matrix maps common product questions to the architecture, user-guide, and developer-guide pages that answer them.
Security review: Security then Signing flow then Custody providers.
Operational readiness: Operability then Deployment topology then Failure modes.
Deployment planning: Self-hosting then Prerequisites then High availability.
Integration planning: Components then Integrations then Unified API.
Glossary
Buyer-friendly definitions for tokenization, regulated assets, compliance, custody, settlement, and DALP platform terms.
Architecture one-pager
A buyer-safe DALP architecture one-pager for RFP, security, and integration reviews: user surfaces, API, execution engine, contracts, indexer, database, chain gateway, custody, and deployment responsibilities.