Overview
Principles and scope
Client-facing architecture responsibilities for DALP, written for review teams evaluating regulated digital asset operations on EVM networks.
DALP is built for regulated asset operations where the system must show who acted, which control applied, what reached the chain, and what state is now visible to operators. The platform owns the lifecycle control path for configured EVM assets. The client architecture still owns the selected network, custody policy, legal interpretation, and external integrations around that control path.
Design principles
| Principle | What it means in practice | Why it matters to clients |
|---|---|---|
| EVM-compatible networks only | Transactions, contracts, events, and indexing are built around EVM semantics | Network choice is constrained up front; non-EVM support should not be assumed |
| On-chain controls for asset state | Token balances, identity checks, roles, and compliance modules resolve at contract level | The final asset-state control is not only an application permission |
| Off-chain orchestration for execution | Long-running actions use durable workflows before they become on-chain transactions | Operators can inspect progress, retries, approval waits, and failure states |
| One instrument, one asset responsibility line | A bond, equity class, fund, deposit token, stablecoin, real-estate token, or commodity token has its own asset contract scope | Lifecycle, roles, supply, and compliance can be governed per instrument |
| Indexed reads for operating views | Console and API reads use indexed chain events and platform records rather than ad hoc direct chain reads | Reports and dashboards follow one read model instead of mixing inconsistent sources |
| Explicit integration responsibilities | Custody providers, RPC access, object storage, secrets, identity checks, and observability sit at named responsibility lines | Client teams can assign ownership and review each external dependency |
| API and console share the same backend | Human operators and automated integrations use the same platform control path | Automation does not bypass the main authorization, workflow, and transaction model |
| Fail closed where scope is ambiguous | Reads and writes require the intended system, asset, network, and role context | Tenant and asset responsibility lines are preserved before convenience is optimized |
How the principles fit together
Rendering diagram...
The platform does not treat these as interchangeable controls. Authentication proves the actor. Workflow state proves execution progress. Contract events prove chain execution. Indexed reads provide the operating view.
Key tradeoffs
| Chosen direction | Benefit | Cost or constraint |
|---|---|---|
| Contract-level compliance | Stronger final control over transfers and asset state | More gas usage and more careful module configuration |
| Durable workflow execution | Restart-safe orchestration for multi-step actions | Additional runtime dependency and operational surface |
| Indexed read model | Consistent dashboards, APIs, reports, and reconciliation views | Reads follow indexer freshness rather than instant direct-chain lookup |
| Provider-based signing abstraction | Local, DFNS, Fireblocks, and HSM-backed patterns can share one platform path | Custody-provider policy and availability remain part of the client architecture |
| Per-instrument contract responsibility lines | Clear lifecycle, role, and compliance separation per financial instrument | More contracts to deploy, monitor, and upgrade |
| EVM-only architecture | Clear execution and indexing assumptions | Non-EVM networks require a separate architecture decision |
Operating responsibilities
| Client question | What DALP controls | What the client architecture decides |
|---|---|---|
| Which networks can carry DALP asset actions? | DALP operates on configured EVM-compatible networks and reads their events through the platform indexer. | Selecting, operating, and accepting the finality and visibility model of the chosen network. |
| Does DALP provide blockchain consensus? | DALP submits transactions to the selected EVM network and records the resulting state. | Designing or operating a custom consensus protocol. |
| Does DALP provide a cross-chain bridge? | DALP handles asset lifecycle and settlement flows inside the configured EVM network context. | Bridge infrastructure, external-chain execution, relayers, liquidity venues, and risks on another chain. |
| Who owns custody policy? | DALP coordinates signing through the configured signer or custody provider path. | Key governance, custody approvals, recovery procedures, and provider availability choices. |
| Is DALP a retail wallet or exchange UI? | DALP provides an institutional operator console and API for asset operations. | Retail wallet experiences, public exchange matching, consumer onboarding, and venue operations. |
| Does DALP give legal or regulatory advice? | DALP supplies technical controls, workflow evidence, chain records, and review surfaces. | Legal interpretation, regulatory permissions, policy approval, and formal assurance decisions. |
| Is DALP a market-data terminal? | DALP uses feed infrastructure where configured asset operations need data inputs. | General market-data sourcing, licensing, redistribution, and terminal-style analytics. |
| Does DALP make private-chain data invisible? | DALP follows the selected network's visibility model and documents public-chain privacy limits separately. | Deciding what data may go on-chain, what must stay off-chain, and which privacy controls the selected network provides. |
| Can clients integrate through the database? | DALP exposes the Unified API and platform services as the integration control surface. | Direct database-as-API operation is not the client integration model. |
Review questions
Use these questions to test whether the architecture split is understood:
| Question | Expected architecture answer |
|---|---|
| Where does a transfer become final? | On the EVM network, after the relevant contract transaction is included and indexed |
| Where does an operator see current status? | In the console or API read model, derived from platform records and indexed chain events |
| Where are custody approvals handled? | In the configured signer or custody provider path, coordinated by the execution engine |
| Where are compliance rules enforced? | In SMART Protocol contracts, with configuration and review surfaces in DALP |
| Who decides the legal meaning of a configured rule? | The client and its advisors; DALP provides the technical enforcement and evidence surface |
Where to go next
- Architecture overview for the layer map and ownership split
- Quality attributes for security, reliability, and operability implications
- Deployment topology for runtime responsibility lines
- Security for authentication, authorization, identity, and wallet verification
Architecture overview
Client-facing overview of the DALP architecture: what it is, who it is for, the decisions it supports, core system layers, client responsibilities, limits, and next architecture pages to read.
Quality attributes for regulated operations
Client-facing quality-attribute view of DALP architecture, covering security, reliability, operability, data consistency, performance constraints, and audit evidence without making SLA or legal claims.