ArchitectureOverview
Data domains
Client-facing data-domain map for DALP, showing which records are on-chain, which are off-chain, which are indexed, and who owns each governance decision.
DALP separates authoritative asset state, platform operating records, and indexed read models. Client operators use that split to assign data ownership, retention, reconciliation, privacy, and reporting responsibilities for a DALP deployment.
Source-of-truth model
Rendering diagram...
| Data class | Source of truth | Used for |
|---|---|---|
| On-chain asset state | EVM contracts | Token balances, roles, compliance module execution, identity-bound checks |
| Off-chain platform records | PostgreSQL application tables | Users, organizations, API keys, transaction requests, audit/action records |
| Durable workflow state | Durable Execution Engine journals and workflow records | Progress, retries, signer waits, recovery, transaction lifecycle |
| Indexed read model | PostgreSQL views and tables derived from chain events and platform data | Operator dashboards, API reads, reporting, reconciliation |
| External-provider state | Custody, RPC, secrets, storage, and observability providers | Signing approvals, network access, secrets, files, logs, metrics, traces |
How to read the model
The EVM network is the source of final asset state. DALP platform records coordinate the work around that state: who requested an action, which workflow is running, and which custody approval is pending. Indexed views make chain and platform records fast to read, but they do not replace the underlying source.
Domain ownership
| Domain | Primary source of truth | DALP-owned responsibility | Client/operator responsibility |
|---|---|---|---|
| Asset supply and balances | EVM token contracts | Contract execution path, indexing, display in console/API | Asset terms, operating approvals, reconciliation policy |
| Asset metadata and lifecycle | EVM contracts plus platform records | Lifecycle workflows, contract configuration, indexed visibility | Instrument setup, business approval, lifecycle operating procedure |
| Identity and compliance claims | On-chain identity/claim contracts and configured trusted issuers | Claim and module integration surfaces, transfer checks, indexed state | Trusted-issuer selection, claim policy, compliance interpretation |
| Roles and permissions | Platform records and contract roles | Role-aware routes and contract role execution | Segregation of duties, user assignment, periodic access review |
| Transaction requests | Platform database plus workflow state | Queue records, workflow progress, transaction status | Operational review, approval policy, exception handling |
| Signing and custody | Signer/custody provider plus DALP transaction records | Signer integration handoff and status tracking | Provider governance, key administration, approval policy |
| Chain events | EVM network | Event ingestion and indexing | Network selection, node/RPC operations where self-managed |
| User accounts and sessions | Platform database and authentication subsystem | Account/session records and route enforcement | User lifecycle policy, access approvals, identity-provider controls |
| Audit and action history | Platform records plus on-chain evidence | Capture and expose operational evidence | Retention, export, downstream audit process |
| Feeds and reference data | Configured feed records and provider inputs | Feed storage, update routes, on-chain update flows where configured | Provider selection, acceptable freshness, exception process |
On-chain, off-chain, and indexed data
| Question | On-chain state | Off-chain platform records | Indexed read model |
|---|---|---|---|
| What is it best for? | Final asset and compliance state | Workflow, users, settings, requests, audit/action records | Fast operating views over chain and platform data |
| Can it be edited? | Only through new transactions and contract rules | Through authenticated platform operations and migrations | Rebuilt or updated from source data |
| What is the normal latency? | Block inclusion and confirmation policy | Database transaction time | Indexer freshness after relevant events are available |
| What happens during a chain lag? | Chain may already have newer state than the indexed view | Requests and workflow state can show progress | Dashboards may wait for indexing before showing the new operating view |
| What is the governance concern? | What data is appropriate to place on-chain | Retention, access, backup, and PII handling | Reconciliation and freshness expectations |
Common reconciliation cases
| Situation | How to read it |
|---|---|
| API accepted an action, but no transaction hash yet | The request is in platform/workflow state and has not reached broadcast visibility |
| Transaction hash exists, but dashboard has not moved | The chain may have a receipt before the indexer-derived read model has updated |
| Dashboard shows old balance after an included transfer | Check indexer freshness, chain receipt, and whether the relevant event was processed |
| Custody approval is pending | The execution path is waiting outside DALP's direct control, but DALP should keep the transaction status visible |
| Compliance failure appears on transfer | The contract or preflight path rejected the operation according to configured identity/compliance controls |
Data-retention and privacy responsibility lines
| Responsibility line | What DALP architecture establishes | What this page does not claim |
|---|---|---|
| On-chain records | Data written to EVM contracts or emitted as events follows the selected network's visibility model | That public-chain data is private or erasable |
| Platform database | Application records, transaction records, indexed state, and audit/action records live off-chain | A specific retention schedule, deletion policy, or regulatory conclusion |
| External providers | Custody, RPC, secrets, storage, and observability systems may hold provider-specific records | Provider contractual terms, uptime, retention, or privacy guarantees |
| Reporting exports | DALP can expose data through console/API surfaces where implemented | That downstream reports are legally sufficient without client review |
Data-governance checklist
| Decision to make | Owner to assign |
|---|---|
| Which data may be written on-chain | Business, legal, compliance, and technology owners |
| Which EVM network is acceptable | Technology, risk, and operations |
| How transaction evidence is retained | Operations, compliance, and records-management teams |
| How indexed-read freshness is monitored | Platform operations |
| How custody-provider evidence is reconciled | Treasury/custody operations and platform operations |
| How API/audit data is exported | Reporting, compliance, and integration teams |
Limits
| Limit | Consequence |
|---|---|
| Indexed data is derived | The indexer read model is not a separate source of asset truth; it is derived from chain/platform data |
| On-chain data is not erasable | Do not put sensitive data on-chain unless the institution accepts the visibility and retention model |
| Provider records are external | Custody, RPC, observability, storage, and secrets providers must be reviewed as part of the deployment |
| No legal retention promise | Retention and deletion policies are deployment and client-governance decisions |
Where to go next
- Database for the platform database and migration model
- Chain Indexer for blockchain-to-database synchronization
- Identity and compliance for identity and claim data
- Public-chain privacy for visibility limits on public networks
Deployment topology
Client-facing deployment topology for DALP, covering runtime zones, network responsibility lines, EVM access, custody and data dependencies, operator ownership, and the recovery points used for HA and DR planning.
Account abstraction model
How DALP uses smart accounts, UserOperations, EntryPoint routing, bundlers, paymasters, and validators without replacing identity or compliance controls.