System context

DALP separates user interfaces, API orchestration, and on-chain enforcement into clear operating scopes. Each 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 after principles and scope when you need to understand actors, integration points, pre-transaction controls, and where trust stops before a transaction reaches the chain. Continue with asset tokenization architecture for the model behind issuance and servicing.

Related: Architecture map | Capability docs matrix | System Factory | Key flows | Security | Tokenization modeling | SMART Protocol integration (ERC-3643)

External actors

Trust boundaries

Three trust boundaries separate external actors from the blockchain state that DALP manages. Each boundary enforces a different class of control: who can call the API, how state-changing work is coordinated, and which asset transfers the contracts allow.

The control path is deliberately split:

1. The platform checks authentication and authorization before an operation reaches the orchestration layer.
2. The Workflow Engine coordinates retries, nonce ordering, transaction signing, and custody policy checks for state-changing work.
3. The SMART Protocol enforces identity and compliance rules on-chain before the asset state changes.

Boundary details

Five-layer smart contract architecture

The on-chain side of DALP follows a layered architecture. Each level builds on the one below it. When you integrate with an asset or addon, you inherit everything the lower layers provide. Foundational layers are more stable and shared. Upper layers are more specific and change more often.

The layers separate shared infrastructure from system-scoped and asset-scoped behaviour:

1. The SMART Protocol foundation is shared across deployments and defines the ERC-3643 token framework.
2. Global and System layers provide infrastructure: once per chain for global services, once per system for tenant-specific registries and controls.
3. Assets and Addons carry the business logic that issuers configure per financial instrument and operational workflow.

Layer summary

How layers interact

A user request flows top-down through the stack:

1. An addon (e.g., Airdrop) or direct API call triggers an operation on an asset (e.g., Bond)
2. The asset delegates identity and compliance checks to the system layer
3. The system resolves implementations through the global directory
4. 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 factory and implementation addresses. Each system becomes the scope boundary for everything configured inside it: assets, identities, roles, compliance modules, trusted issuers, and feed configuration.

A created system is the scope for its own registries and controls:

1. The directory and System Factory are shared infrastructure for implementation discovery and system creation.
2. Each created system has independent registries for assets, identities, roles, compliance modules, feeds, trusted issuers, and factories.
3. When you read or write through the API, 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 understand what is shared across all systems and what is scoped to one.

Resolve the target system and keep its address. Every subsequent call requires the same context, whether it is an asset, identity, compliance, or lifecycle operation.

Before production, confirm that every integration path stores the right system context. Do not mix system addresses between issuers, test environments, or chains in operational runbooks.

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. The platform evaluates all operations against the active system context: identity checks, role assignments, compliance module evaluation, trusted issuer lookups, and lifecycle events. Assets do not come from a global 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 you operate 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 your map, then move to the page that answers your next question:

Next steps

• Asset tokenization architecture to see how DALP models instruments before issuance and servicing flows run
• 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