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.
DALP is a Digital Asset Lifecycle Platform for regulated tokenized assets on EVM-compatible networks. It gives banks, asset managers, fund administrators, and their operators one control plane for issuing assets, enforcing eligibility, submitting lifecycle actions, and reading operational state.
The architecture has one practical job: keep the responsibilities for user actions, workflow execution, on-chain enforcement, indexed reads, and external integrations clear enough for a bank-grade review.
Who this is for
| Reader | What they are deciding |
|---|---|
| Business sponsor | Whether DALP matches the institution's digital-asset operating model |
| Technology architect | Where DALP sits relative to identity, custody, EVM network access, data stores, and observability |
| Operations lead | Which teams own day-to-day actions, approvals, monitoring, reconciliation, and incident response |
| Compliance or risk reviewer | Which controls are enforced on-chain, which controls are off-chain, and where audit evidence is formed |
This page gives review teams the responsibility map before the component, deployment, security, and self-hosting pages add implementation detail.
If you have only a few minutes, confirm three points first:
- DALP is the control plane.
- SMART Protocol contracts enforce the configured on-chain rules.
- The institution still owns custody policy, network choice, legal sign-off, and operating procedures.
What DALP is
DALP is a full-stack platform with five cooperating layers.
| Layer | Client-facing role | Primary evidence it produces |
|---|---|---|
| Asset Console | Human operators configure assets, review actions, manage users, and monitor status | User-visible action history and operational state |
| Unified API | Systems integrate with DALP through authenticated API routes and generated API documentation | Request validation, transaction-request records, API audit trails |
| Execution Engine | Long-running blockchain actions are journaled, retried, signed, submitted, and reconciled | Durable workflow state and transaction status |
| SMART Protocol contracts | Asset rules, identity checks, compliance modules, roles, and token balances are enforced on-chain | EVM transactions, contract storage, and events |
| Chain Indexer | On-chain events are transformed into queryable platform state for the console, API, reports, and monitors | Indexed PostgreSQL views derived from chain events |
The table is the short version of the mental model. Human and API users start work through DALP. The execution layer prepares and tracks the transaction. SMART Protocol contracts enforce configured asset, role, identity, and compliance rules on-chain. The indexer then turns emitted events into the state operators see in dashboards, reports, and API reads.
External systems connect at explicit handoff points. Custody providers sit in the signing path, compliance providers can support issuer and claim workflows, EVM RPC providers or nodes carry transactions to the selected network, and downstream systems consume API or report outputs. DALP documents those handoffs as integration responsibilities, not as implicit platform ownership.
How to read the overview schematic
The schematic is a review aid, not a deployment diagram. Read it from left to right when you need to explain how an operator action becomes controlled platform state.
| Schematic element | What it means in review | What it does not claim |
|---|---|---|
| Asset Console | Human operators use DALP to configure assets, review actions, and monitor status | A retail investor channel or a replacement for institution-specific operating policies |
| Unified API | Integrations use authenticated API routes and generated API documentation | A bypass around authorization, tenant context, validation, or approval requirements |
| Execution Engine | Accepted actions become durable workflows for signing, submission, retries, and status | A finality layer, custody policy, or provider availability commitment |
| SMART Protocol | EVM contracts enforce configured token, role, identity, and compliance rules on-chain | Native support for non-EVM ledgers or private-chain confidentiality by default |
| Chain Indexer | Contract events become queryable read state for the console, APIs, reports, and monitors | A separate source of truth that can overrule accepted on-chain state |
Use this page when a review needs the top-level control model. Use the linked detail pages when the review needs deployment topology, data ownership, cross-chain responsibilities, or specific security controls.
What changes and where it is controlled
| Architecture concern | Where DALP controls it | What the client still decides |
|---|---|---|
| Who may act | Authentication, authorization, tenant context, role checks, and API validation | User lifecycle, segregation of duties, and approval policy |
| What may transfer | SMART Protocol roles, identity checks, compliance modules, and token configuration | Which compliance rules to configure and which issuers or providers to trust |
| How transactions leave the platform | Durable execution, signer abstraction, transaction preparation, status tracking, and retries | Custody model, quorum policy, HSM or provider administration, and signer governance |
| What evidence is available | API records, workflow state, EVM transactions, contract events, indexed reads, and audit surfaces | Retention policy, evidence pack assembly, downstream reporting, and operating procedures |
How a state change works
DALP separates write execution from read visibility. That separation matters during review, because an action is not treated as operationally visible just because an HTTP request was accepted.
| Step | What is controlled there |
|---|---|
| Request acceptance | Authentication, authorization, tenant/system context, input validation |
| Durable execution | Workflow progress, retries, transaction queueing, nonce ordering, custody path |
| On-chain execution | Token state, compliance checks, identity claims, role checks, final events |
| Indexed visibility | Operator dashboards, API reads, reports, reconciliation, monitoring |
Example review path: transfer approval
A transfer approval review uses the same control split:
- An approval authority grants or revokes approval through the platform API or console.
- The execution path prepares and signs the transaction through the configured signing model.
- SMART Protocol compliance checks validate sender identity, recipient identity, approved value, expiry, and consumption mode before the transfer can complete.
- Contract events and indexed approvals give operators the current review queue and the event trail for evidence packs.
Use Transfer approval for approval modes, emitted events, API surfaces, and evidence records. Use Data domains to decide which approval records are on-chain, off-chain, indexed, or provider-owned.
Who owns what
DALP is designed so ownership can be assigned without guessing which layer is responsible.
| Area | DALP platform owns | Client or operator owns |
|---|---|---|
| Asset lifecycle | Asset factories, lifecycle workflows, transaction orchestration, on-chain state transition routes | Business approval policy, asset terms, role assignment, operating procedures |
| Compliance controls | Identity-bound transfer checks, compliance module execution, trusted-issuer configuration surfaces | Which controls to configure, which issuers are trusted, how exceptions are approved and documented |
| Key and signing path | Signer abstraction, transaction preparation, status tracking, local development signer | Custody-provider selection, approval policies, HSM or provider administration, signer key governance |
| Network access | EVM RPC client integration, chain gateway, transaction submission, indexer ingestion | Which EVM network is used, RPC provider or node operations, confirmation policy for the operating entity |
| Platform data | Database schema, indexed read model, audit events, API records | Data-retention policy, backup operations, downstream reporting controls |
| Operations visibility | Health checks, observability hooks, failure-mode pages, status surfaces | Alert routing, runbooks, support model, incident command |
Partner delivery model
A delivery partner can implement, configure, and operate the DALP product surfaces described above. The partner can connect custody providers, compliance providers, EVM RPC access, observability, reporting exports, and downstream systems through the documented integration points. The client or operator still owns legal interpretation, custody policy, network selection, retention policy, incident command, and regulated operating procedures.
Decide the documentation channel before drafting partner-delivery content:
| Question to answer | Use DALP product docs when the answer is about | Use another channel when the answer is about |
|---|---|---|
| Is the claim a platform behaviour? | Product behaviour, supported configuration surfaces, integration handoff points, audit evidence, or EVM scope | Commercial packaging, reseller roles, partner staffing, legal advice, sales qualification, or contractual obligations |
| Can a reviewer verify it from this corpus? | Architecture, integration, deployment, security, quality, API, or evidence pages | Partner playbooks, delivery methodology, customer-specific statements of work, enablement decks, or sales narratives |
| Does it help someone operate DALP? | Asset configuration, transaction submission, custody handoff, provider integration, observability, or evidence | Partner onboarding, implementation resourcing, support escalation, pricing, SLA terms, or privacy commitments |
Use this split after product docs are the right channel:
| Delivery question | What DALP covers | Partner or client responsibility |
|---|---|---|
| What can be configured? | Asset factories, token configuration, compliance modules, roles, workflow routes, and integration points | Asset terms, policy choices, trusted issuers, provider selection, and approval procedures |
| How does a transaction leave the platform? | Durable execution, signer abstraction, status tracking, retries, and EVM transaction submission | Custody quorum, key governance, provider administration, network confirmation policy, and operational sign-off |
| Where does integration evidence come from? | API records, workflow state, indexed reads, webhook delivery evidence, contract events, and audit logs | Evidence-pack assembly, retention periods, downstream reconciliation, and regulator or auditor handoff |
For implementation detail, read Integrations for provider handoff points, Deployment topology for runtime placement, and Quality attributes for availability and recovery responsibilities.
Architecture decisions this page supports
The table below maps each decision to the architecture answer and the next detail page. Use it as the first-pass review map before opening component, security, deployment, or operability pages.
| Decision | The architecture answer | Read next |
|---|---|---|
| Platform fit | DALP is an EVM-only lifecycle platform for regulated assets, not a retail wallet or cross-chain bridge | Principles and scope |
| Deployment planning | Runtime zones separate public console, backend services, durable execution, data stores, and EVM access | Deployment topology |
| Control review | Authentication and orchestration happen off-chain; asset and compliance finality happen on-chain | Security |
| Operational readiness | Durable workflows and indexer-derived reads define the normal recovery and reconciliation model | Quality attributes |
| Data governance | On-chain state, off-chain records, and derived indexed data have different sources of truth | Data domains |
| Integration responsibility | Custody, compliance providers, RPC nodes, object storage, secrets, and observability are explicit ownership points | Integrations |
Start a bank-grade review
Start with the decision the review must close. Do not read the architecture pages in order unless the review is exploratory.
| Review need | First question to answer | Start with |
|---|---|---|
| Product fit | Does the operating model need an EVM lifecycle control plane? | Principles and scope |
| Technical design | Which DALP services, stores, contracts, and integrations are in scope? | Components |
| Controls and risk | Which checks happen off-chain, on-chain, and at provider handoff points? | Security |
| Operations and recovery | How are workflows, indexing, health checks, and recovery handled? | Operability |
| Data ownership and evidence review | Which records are on-chain, off-chain, indexed, or exported? | Data domains |
Review answers before detail pages
| Review question | Architecture answer on this page |
|---|---|
| What runs in DALP? | The console, API, execution engine, SMART Protocol contract integration, chain indexer, and supporting platform services. |
| What changes asset state? | Authenticated requests create durable workflows that prepare, sign, and submit EVM transactions to SMART Protocol contracts. |
| Who controls final asset rules? | Contract roles, identity checks, compliance modules, and token configuration enforce the final on-chain rule set. |
| Who controls operational policy? | The institution or operator owns asset terms, business approvals, custody policy, network choice, retention, and runbooks. |
| Where does evidence come from? | API records, workflow state, transaction status, EVM receipts, contract events, indexed reads, and audit surfaces. |
| What is intentionally not covered here? | SLA commitments, legal opinions, privacy guarantees, custody operating policy, retail distribution, and bridge architecture. |
Client decisions outside this overview
The overview is deliberately narrow:
| Limit | Meaning for client evaluation |
|---|---|
| EVM-only | DALP operates with EVM-compatible networks. Non-EVM ledgers are outside this architecture. |
| No bridge architecture | DALP does not present a bridge, cross-chain settlement layer, or non-EVM interoperability layer in these docs. |
| Not a legal opinion | Compliance modules provide technical enforcement points. Legal interpretation and regulatory sign-off remain client responsibilities. |
| Not an SLA | Reliability patterns are described as architecture, not contractual availability or support commitments. |
| Not a privacy guarantee | Public-chain privacy limits depend on the selected network and data placed on-chain. |
| Not a retail front end | The Asset Console is built for institutional operators. Retail investor experiences are integration-specific. |
These limits are part of the architecture, not footnotes. They keep the overview from implying that DALP is also a bridge, legal opinion, privacy layer, SLA, custody policy, or retail channel.
Where to go next
Start with the page that matches the review underway:
| Review track | Recommended path |
|---|---|
| Executive architecture | This page → Principles and scope → System context |
| Technical architecture | This page → Components → Flows |
| Security and risk | This page → Security → Identity and compliance → Asset policy |
| Deployment and operations | This page → Deployment topology → Operability |
| Data governance | This page → Data domains → Database |
Compatibility paths remain available for older bookmarks. The former principles route routes to Principles and scope. The SMART Protocol overview route routes to the asset-contracts reference.