DALPAsset: one configurable contract for every token

Recommended configurable asset contract. Attach token-features and compliance modules per instrument; evolve configuration post-deploy under governance controls.

Purpose: The recommended contract type for all new tokenization projects — a single, configurable asset contract that replaces the need for specialized types.

Doc type: Explanation
What you'll find here:
- What DALPAsset is and why it exists
- How token-feature and compliance-module configuration works (architecture-level)
- Why configuration is composable — not limited to presets
- Relationship to legacy specialized types
Does not cover: preset catalog (see Legacy-Equivalent Presets), RBAC role table (see RBAC), deployment steps (see Deployment Architecture)
Related:

At a glance

Configurable post-deployment via SMARTConfigurable — attach/remove token features and compliance modules without redeploying
All configuration changes are governance-gated (require GOVERNANCE_ROLE)
Deployable as upgradeable (UUPS proxy) or immutable — see Deployment Architecture
Feature attachment is composable — not limited to predefined presets
External systems (wallets, indexers, dashboards) interact via standard ERC-20 and ERC-3643 interfaces

DALPAsset extends SMART Protocol (ERC-3643) with the SMARTConfigurable extension, which allows any combination of token features to be attached and reconfigured at runtime — after the token is deployed.

This eliminates the need to commit to a specialized contract type at deployment time. A DALPAsset token can evolve: start as a simple bearer instrument, then have fee features added, governance enabled, or maturity redemption configured — all without redeploying.

How configuration works

Token features

Runtime-pluggable via the ISMARTFeature interface — see the Token Features catalog for all available features
Integrate through six lifecycle hooks: mint, burn, transfer, redeem, update, and attach
Feature ordering is the caller's responsibility — see the Token Features ordering guide
Some features rewrite transfer amounts (e.g., fees); ordering matters for downstream analytics

Compliance modules

Transfer and supply rules enforced by the ERC-3643 compliance engine — see Compliance Modules
Modules can be added, removed, or reconfigured at runtime
Common patterns: capped supply, collateral enforcement, jurisdiction-based investor restrictions

Configuration is composable

DALPAsset is not limited to the seven Legacy-Equivalent Presets. Any combination of token features and compliance modules is valid. The presets exist as proven starting points for teams migrating from legacy types — they are not exhaustive.

What changes mean

Adding/removing features — governance-gated, no redeployment required. Understand what the feature's hooks do before attaching.
Changing compliance rules — transfer rules change immediately for all subsequent transactions. Existing balances are not retroactively affected.
Parameter immutability — some parameters (e.g., face value, maturity date) are immutable by design. Others (fee rates, schedules) are governance-reconfigurable. Check per-feature documentation.
Governance expectations — all changes require GOVERNANCE_ROLE. Multi-sig or timelock recommended for production.

Relationship to legacy

Seven specialized types (DALPBond, DALPEquity, DALPFund, DALPStableCoin, DALPDeposit, DALPRealEstate, DALPPreciousMetal) predate SMARTConfigurable — see Legacy Types
Legacy types are fully supported, not deprecated — no migration required
Legacy-Equivalent Presets recreate legacy behavior on DALPAsset
Choose legacy when compile-time immutability is required by regulation or legal frameworks
Choose DALPAsset for all new projects and when requirements may evolve

DALPAsset