ArchitectureOverview
Principles and out-of-scope items
Architecture principles and explicit out-of-scope items for DALP, written for client 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.
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 |
Explicit out-of-scope items
| Out-of-scope item | What DALP does instead |
|---|---|
| Custom blockchain consensus | Runs against configured EVM-compatible networks and existing client/RPC infrastructure |
| Cross-chain bridge | Handles EVM asset lifecycle and settlement flows inside the configured network context |
| Retail wallet or exchange UI | Provides an institutional operator console and API; retail experiences are outside this documentation |
| Legal or regulatory advice | Supplies technical controls and evidence points; legal interpretation remains with the client |
| Guaranteed market-data platform | Uses feed infrastructure where asset operations require configured data; it is not a general market-data terminal |
| Blanket privacy promise | Documents public-chain privacy limits separately; data placed on-chain follows the selected network's visibility model |
| Hardcoded custody model | Supports signing abstraction and provider integration; custody policy is selected and governed by the operator |
| Direct database-as-API operation | Uses the Unified API and platform services as the control surface; database access 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, ownership responsibility lines, limits, and next architecture pages to read.
Quality attributes
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.