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 (workflow 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.
What belongs to a system
A DALP system is the operating boundary for the assets and controls created inside it. Use this table to separate shared platform infrastructure from one-system scope.
| Capability | System-scoped behavior | Why it matters |
|---|---|---|
| Asset creation | Assets are created through factory registries associated with the active system. | An issuer works with its own factories and assets instead of a global asset pool. |
| Identities and trusted issuers | Identity registration and trusted issuer configuration are evaluated in the active system context. | Compliance checks can be configured per system without reusing another system's trust boundary. |
| Roles and access | Role assignments are managed through the system's access manager. | Operators can delegate system-level administration without granting access across other systems. |
| Compliance modules and feeds | Compliance modules and feed configuration belong to the system that uses them. | Transfer and lifecycle checks use the controls configured for that system. |
| API reads and writes | Authenticated API routes resolve the organization's system address and apply it to system-scoped queries. | Integrations keep records inside the right system by carrying that context into follow-on reads/writes. |
The smallest way to use this boundary is to resolve the target system, keep its system address, then use that address consistently. Use the same context for asset, identity, role, compliance, feed, and lifecycle operations.
Before production, confirm that every integration path stores the right system context. Operational runbooks should not mix system addresses between issuers, test environments, or chains.
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 are organization systems created and isolated? | System Factory |
| 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
Institutional asset tokenization architecture
See how DALP structures institutional asset tokenization across asset templates, SMART Protocol contracts, identity, compliance controls, custody routing, settlement, monitoring, and APIs.
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.