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. The platform keeps operator workflows, API calls, durable work tracking, smart contract checks, indexed chain data, and external infrastructure in separate layers.
Use this page as the architecture map before you inspect deployment, security, API, or operations detail.
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 authorisation, 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.
How to read the architecture in a review
Start with the layer that owns the decision you are checking. A user action normally enters through the Asset Console or Unified API, moves through the execution layer, reaches the signer or custody provider, and is enforced by SMART Protocol contracts on the selected EVM network. DALP then reads chain events and contract state back into indexed operational views.
That flow keeps procurement and security reviews concrete:
| Review topic | Architectural question | Primary docs path |
|---|---|---|
| Bank-grade platform architecture | Which layer owns user action, workflow state, signing, on-chain enforcement, and data? | System context and Components |
| Privacy on public networks | Which data is on chain, and which data stays in DALP or external systems? | Public chain privacy |
| Replay, retries, and idempotency | How does DALP coordinate state-changing work before and after signing? | Signing flow and workflow engine recovery |
| Auditability and source verification | How can a reviewer trace deployed contracts, events, and transaction history? | Source verification and deployment auditability |
| Hosting, backup, and recovery | Which responsibilities belong to DALP services, the deployment model, and the operator? | Deployment topology and Operability |
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? |
| Platform settings and admin guides | Operating model for organizations, users, system roles, API keys, webhooks, providers, and operator wallets | How do platform operators set up the control plane before asset work starts? |
| 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 a 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.
For hosting, networking, high availability, backup, recovery, or restricted-network detail, continue to Deployment topology and Operability.
Reader paths
| If you are... | Start here | Then read |
|---|---|---|
| An integrating developer | Unified API | Signing flow and Key flows |
| A platform operator | Admin operating model | Platform role provisioning, administrator role changes, and Operator wallets |
| 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, non-EVM execution environments, and physical-asset reserve attestations 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.