System context
System context for DALP architecture, including external actors, operating scopes, trust boundaries, and the contract layers that keep assets, identities, compliance rules, and factory registries separated by system.
DALP separates user interfaces, API orchestration, and on-chain enforcement into clear operating scopes. A DALP system owns the infrastructure that keeps assets, identities, roles, compliance rules, feeds, trusted issuers, and factory registries tied to the right operating context.
Read this page first when you need to place a DALP capability in the architecture. Use it to identify the actors, integration points, pre-transaction controls, and system boundaries that apply before a transaction reaches the chain.
Related: Architecture map | Key flows | Security | Tokenization modeling | SMART Protocol integration (ERC-3643)
External actors
| Actor | Interaction | Entry point |
|---|---|---|
| Asset Issuers | Configure and issue tokenized financial instruments, manage lifecycle events | Asset Console, Unified API |
| Investors | Participate in offerings, hold assets, receive distributions | Asset Console (read-only views), custodian wallets |
| Compliance Officers | Define compliance rules, manage identity claims, review audit trails | Asset Console, Unified API |
| Platform Operators | Deploy infrastructure, monitor health, manage access control | Helm charts, observability dashboards, Unified API |
| External Systems | Wallets, exchanges, custodians (DFNS, Fireblocks), EVM RPC nodes, oracle services | Unified API, Chain Gateway, Feeds system |
Trust boundaries
Three trust boundaries separate external actors from the blockchain state that DALP manages.
The control path is deliberately split:
- Authentication and authorization are checked before an operation reaches the orchestration layer.
- The Execution Engine coordinates retries, nonce ordering, transaction signing, and custody policy checks for state-changing work.
- The SMART Protocol enforces identity and compliance rules on-chain before the asset state changes.
Boundary details
| Boundary | Controls | Enforced by |
|---|---|---|
| 1 - Authentication | Session auth (Better Auth), API key validation, rate limiting | Asset Console, Unified API |
| 2 - Orchestration | Custody policies, nonce management, gas estimation, retry logic | DALP Execution Engine (Durable Execution Engine workflows) |
| 3 - On-chain | Identity verification, compliance modules, transfer restrictions | SMART Protocol smart contracts |
Five-layer smart contract architecture
The on-chain side of DALP follows a layered architecture. Each level builds on the one below it. Lower layers are more stable and shared; upper layers are more specific and change more frequently.
The layers separate shared infrastructure from system-scoped and asset-scoped behaviour:
- The SMART Protocol foundation is shared across deployments and defines the ERC-3643 token framework.
- Global and System layers provide infrastructure: once per chain for global services, once per system for tenant-specific registries and controls.
- Assets and Addons carry the business logic that issuers configure per financial instrument and operational workflow.
Layer summary
| Layer | Purpose | Key components |
|---|---|---|
| SMART Protocol | ERC-3643 token framework with modular compliance, identity management, and extension system | Core token, compliance engine, identity registry interfaces |
| Global | Platform-wide infrastructure shared across all system instances on a given chain | Central directory, identity factory, identity implementations |
| System | Per-system infrastructure managing identity registration, compliance, access control, and token factory scope | Identity registry, compliance orchestration, access manager, factory registries |
| Assets | Deployed tokenized financial instruments built on the SMART Protocol and created through the system's registered factories | DALPAsset, Bond, Equity, Fund, Deposit, StableCoin, RealEstate, PreciousMetal |
| Addons | Operational tools that extend assets with distribution, settlement, and treasury capabilities | Airdrop, Vault, XvP Settlement, Token Sale (DAIO), Yield |
How layers interact
A user request flows top-down through the stack:
- An addon (e.g., Airdrop) or direct API call triggers an operation on an asset (e.g., Bond)
- The asset delegates identity and compliance checks to the system layer
- The system resolves implementations through the global directory
- The SMART Protocol executes the compliant transfer or state change
System factory and system isolation
The System Factory creates a system with its own access manager, identity registry, compliance orchestration, and factory registries. After creation, the directory remains the discovery point for platform-level factory and implementation addresses. Each system becomes the boundary for the assets, identities, roles, compliance modules, feeds, and trusted issuers configured inside it.
A created system is the scope for its own registries and controls:
- The directory and System Factory are shared infrastructure for implementation discovery and system creation.
- Each created system has independent registries for assets, identities, roles, compliance modules, feeds, trusted issuers, and factories.
- System-scoped reads and writes must use the intended system address so operations stay inside the correct operating context.
Multi-tenancy boundaries
Each DALP system is a tenant boundary on the same platform infrastructure. Assets created through one system's factory registries stay associated with that system. Identity registration, role assignments, trusted issuer configuration, compliance modules, feeds, and asset lifecycle operations are evaluated against the active system context instead of a global asset pool.
Factory registries are part of the isolation boundary. If a system has no registered token factories, token reads that depend on factory scope fail closed instead of showing assets from another system. When operating through the CLI or API, read the target system first and use that system address consistently for follow-on commands.
Architecture routing
Use the system context as the map, then move to the page that answers the next question:
| Question | Read next |
|---|---|
| How do the main issuance, transfer, settlement, and distribution flows move through this model? | Key flows |
| Which asset components sit on top of the SMART Protocol? | Tokenization modeling |
| Which controls run before DALP submits an EVM transaction? | Security |
| How does ERC-3643 fit into the contract stack? | SMART Protocol integration |
Next steps
- Key flows to see how the most important operations traverse these layers
- Components for detailed component responsibilities
- Security for authentication, authorization, compliance, and custody controls
Asset model
Understand how DALP turns an asset class, instrument template, token features, metadata, and compliance rules into an issued SMART Protocol asset.
Lifecycle after issuance
How DALP operators manage an issued asset after deployment, from the asset detail workspace through supply, transfer, pause, role, compliance, feature, and audit operations.