Legacy types
DALP still supports the seven specialized contract types. Use DALPAsset for new configurable instruments, and keep legacy types when an existing token or fixed feature composition depends on them.
Legacy types are the specialized DALP token contracts that existed before the configurable DALPAsset model. They remain supported for existing deployments and for policies that need a fixed instrument feature set. DALPAsset is the default for new projects because it attaches token features and compliance modules through configuration.
Status and support posture
All seven specialized contract types are supported and do not require migration to DALPAsset. Existing deployments can keep using them when their fixed feature set still matches the instrument policy.
Use DALPAsset for new projects unless the legal, compliance, or audit model specifically requires a specialized type with no runtime feature-composition path. Specialized types predate the SMARTConfigurable extension, so changing the instrument model usually means deploying a new token rather than attaching or reconfiguring features after launch.
Legacy type catalog
| Type | Primary use case | Specialized capabilities | Configuration posture | Equivalent DALPAsset preset |
|---|---|---|---|---|
| DALPBond | Fixed-income instruments | SMARTRedeemable, SMARTYield (legacy), SMARTCapped, SMARTHistoricalBalances | Bond feature set is part of the specialized type | Bond |
| DALPEquity | Shares with voting | ERC20Votes, SMARTHistoricalBalances | Voting support is part of the specialized type | Equity |
| DALPFund | Investment vehicles | Management fee, ERC20Votes, SMARTHistoricalBalances | Management-fee support is part of the type | Fund |
| DALPStableCoin | Fiat-pegged tokens | SMARTCollateral, SMARTHistoricalBalances | Collateral support is part of the type | StableCoin |
| DALPDeposit | General deposits | SMARTHistoricalBalances | Minimal feature set | Deposit |
| DALPRealEstate | Fractional property | SMARTCapped, SMARTHistoricalBalances, premint mechanism | Cap and premint support are part of the type | RealEstate |
| DALPPreciousMetal | Tokenized metals | SMARTHistoricalBalances | No capped-supply feature in this type | PreciousMetal |
All types share the same SMART Protocol (ERC-3643) foundation, RBAC model, and factory deployment pattern as DALPAsset.
Legacy composition model
Legacy types and DALPAsset share the same regulated-token foundation. Legacy types expose an instrument-specific feature set through specialized contracts. DALPAsset attaches instrument-specific behavior through runtime configuration.
Specialized vs runtime-configurable
The architectural difference is when DALP binds capabilities to the token.
| Question | Legacy specialized type | DALPAsset |
|---|---|---|
| When are capabilities selected? | The selected legacy type defines the available instrument feature set. | The token uses SMARTConfigurable so features and compliance modules can be attached through configuration. |
| How does governance change behaviour later? | Governance can use functions already present on the specialized contract. It cannot add a missing feature to that token. | Role-gated configuration changes can attach, upgrade, or reconfigure supported features. |
| What does an auditor review? | The specialized contract, deployed settings, roles, and the fixed feature set. | The base contract, attached features, configuration state, permissions, and later configuration changes. |
Choose legacy when
A legacy specialized type can be the right choice when the instrument already exists or when the issuance policy needs a fixed feature set.
- The deployment already uses DALPBond, DALPEquity, DALPFund, DALPStableCoin, DALPDeposit, DALPRealEstate, or DALPPreciousMetal and the current feature set still fits.
- The legal or compliance model requires the fee, maturity, collateral, cap, or voting behaviour to come from the selected specialized type rather than a later feature attachment.
- The audit review benefits from a smaller configuration surface with no runtime feature-composition path.
Choose DALPAsset when
DALPAsset is the normal choice for new instruments and for deployments that need a shared configurable contract model.
- Requirements may change after deployment, such as adding a fee, governance, yield, or compliance module.
- The rollout needs post-deployment feature attachment or phased enablement.
- The operator wants one configurable contract type across several instrument profiles.
Parity notes
Where a legacy compiled-in feature differs from the modern token feature equivalent:
| Legacy feature | Legacy type | Modern equivalent | Difference |
|---|---|---|---|
SMARTYieldUpgradeable | DALPBond | Fixed Treasury Yield | Legacy uses a different yield distribution mechanism. The token feature uses pull-based claiming from a treasury with scheduled distributions. |
SMARTCollateralUpgradeable | DALPStableCoin | CollateralComplianceModule | Legacy embeds collateral logic in the token contract. The module approach uses the compliance engine with ERC-735 identity claims for collateral proof. |
SMARTCappedUpgradeable | DALPBond, DALPRealEstate | CappedComplianceModule | Same cap enforcement logic, different attachment mechanism (specialized type vs compliance module). |
collectManagementFee() | DALPFund | AUM Fee | Legacy mints fee tokens to the caller (governance role). The token feature mints to a configured feeRecipient address. |
These differences are behavioral. The specialized implementations and the modern equivalents achieve the same business outcome through different mechanisms. When evaluating a migration, review whether the behavioral difference affects downstream integrations (e.g., fee accounting systems that expect minting to a specific address).
Coexistence guidance
DALPAsset and legacy types can coexist in the same deployment because they share the regulated-token foundation.
- Both use the SMART Protocol (ERC-3643) foundation for compliance-aware transfer checks and identity-registry integration.
- Both use the same asset role model. See RBAC for the role identifiers and permissions.
- Both are deployed through DALP factory infrastructure.
- Both can use the deployment model described in Deployment architecture.
No migration is required solely because a token uses a legacy specialized type. External systems such as wallets, indexers, and compliance dashboards should integrate through the ERC-20 and ERC-3643 interfaces that the token exposes.
See also
- DALPAsset - recommended configurable contract type
- Asset Contracts - return to the asset contracts hub
- Legacy-Equivalent Presets - per-instrument DALPAsset configuration spec
- Token Features - runtime-pluggable feature catalog
- RBAC - per-asset role model shared by all contract types
Legacy-equivalent presets
How DALPAsset presets compose token features, compliance modules, and instrument parameters for bond, equity, fund, stablecoin, deposit, real estate, and precious metal assets.
Per-asset RBAC
Per-asset role-based access control separates token governance, supply, custody, emergency, and sale operations. Roles are scoped to one asset contract and do not grant authority over other assets.