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.
DALP is a digital asset lifecycle platform for regulated tokenized assets on EVM-compatible networks. It separates operator workflows, API orchestration, durable execution, smart contract enforcement, indexed chain data, and external infrastructure so each layer has a clear responsibility.
Use this page when someone asks, "Walk me through the architecture." It is an explanation page, not an installation guide or API reference.
The short version
DALP gives issuers and operators a controlled path from asset configuration to on-chain execution. Users work through the Asset Console or Unified API. The DALP Execution Engine prepares and tracks state-changing work. Transactions route through the configured signer or custody provider and reach SMART Protocol contracts on an EVM network. The Chain Indexer reads emitted events and contract state back into DALP views, APIs, and audit workflows.
Three points matter in most reviews:
- DALP is EVM-focused. It does not make non-EVM chains native DALP execution environments.
- DALP separates workflow authorization, transaction signing, and on-chain compliance instead of treating any one layer as the whole control plane.
- DALP stores operational data off chain for workflow and review, while asset ownership and rule enforcement live in smart contracts on the selected EVM network.
What runs inside DALP
| Area | Responsibility | Review question it answers |
|---|---|---|
| Asset Console | Browser surface for issuers, operators, compliance reviewers, and asset servicing users | How do business users configure and manage asset workflows? |
| Unified API | Programmatic entry point for assets, identities, compliance, servicing, and transaction workflows | How do integrations enter the platform? |
| DALP Execution Engine | Durable orchestration for state-changing operations, transaction preparation, retries, and status tracking | What coordinates work before a transaction reaches the chain? |
| Transaction signer or custody provider | Signing handoff and custody-provider policy enforcement | Who controls signing policy and quorum decisions? |
| SMART Protocol contracts | EVM smart contracts for assets, identities, compliance modules, and lifecycle capabilities | What enforces token state and transfer controls on chain? |
| Chain Gateway / RPC | Connection from DALP services to the selected EVM network | How does DALP submit transactions and read chain state? |
| Chain Indexer | Event and state indexing for DALP views, APIs, and review surfaces | How does chain activity become searchable operational evidence? |
| DALP database | Off-chain platform records, workflow status, indexed data, and configuration needed by DALP services | Which data supports platform operation without replacing on-chain asset state? |
Control responsibilities
DALP uses layered controls so a request must pass the right gate for the action it is trying to perform.
| Responsibility area | What DALP checks | Where to continue |
|---|---|---|
| Identity and access | Sessions, API credentials, roles, organisation scope, and resource permissions | Authentication and Authorization |
| Operator confirmation | Wallet verification for browser-session blockchain writes where confirmation is required | Wallet verification |
| Execution and signing | Workflow state, transaction preparation, nonce handling, signer routing, and custody-provider policy | Signing flow and Custody providers |
| On-chain asset rules | Identity claims, compliance modules, asset policy, transfer approval, caps, and time-based restrictions where configured | Identity and compliance and Compliance modules |
| Audit and recovery evidence | Deployment addresses, source verification, indexed events, and transaction history | Source verification and deployment auditability |
This split is important for auditors. Authentication proves who is calling. Authorization decides whether the caller can request an operation. Signing policy decides whether a transaction can be signed. SMART Protocol contracts decide whether the requested state change is valid on chain.
Deployment responsibilities
DALP can run in managed, customer-hosted, hybrid, private-chain, and restricted-network patterns depending on the operating model. The recurring split is the same: DALP services operate the console, API, execution, indexing, database, and integration layer; the selected EVM network, custody provider, RPC service, identity sources, pricing sources, payment rails, and operational approvals remain explicit dependencies.
Use the deployment pages when you need hosting, networking, high availability, backup, recovery, or air-gapped detail. This one-pager only explains the architectural shape.
Reader paths
| If you are... | Start here | Then read |
|---|---|---|
| An integrating developer | Unified API | Signing flow and Key flows |
| A security reviewer | Security overview | Public chain privacy, Compliance and custody split, and Source verification |
| A platform architect | System context | Deployment topology and Operability |
| An auditor or compliance reviewer | Identity and compliance | Compliance modules and Compliance transfer flow |
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, and non-EVM execution environments need their own review. DALP integrates with selected external systems where configured, but integration is not the same as native platform control.
Architecture map
Navigate the DALP architecture documentation by platform layer, reader goal, and integration question.
Capability docs matrix
Map DALP capabilities to the public documentation pages that explain the architecture, operator workflow, API integration path, and review notes for each capability.