DALP legacy contract types: supported specialized tokens

Specialized contract types (DALPBond, DALPEquity, DALPFund, DALPStableCoin, DALPDeposit, DALPRealEstate, DALPPreciousMetal) are fully supported with compile-time immutability. DALPAsset is recommended for all new projects.

Purpose: Reference catalog for the seven specialized contract types, their compiled-in capabilities, when to choose them over DALPAsset, and how they coexist in mixed deployments.

Doc type: Reference
What you'll find here:
- Support status of all seven specialized types
- Capability and immutability details per type
- Compile-time vs runtime-configurable tradeoffs
- Decision checklists for choosing legacy vs DALPAsset
- Parity notes where legacy features differ from modern equivalents
- Coexistence guidance for mixed-fleet deployments
Related:

Status and support posture

All seven specialized contract types are fully supported, not deprecated, and require no migration. There is no planned deprecation timeline. They continue to receive security patches and compatibility updates alongside DALPAsset.

DALPAsset is recommended for all new projects. Specialized types exist because they predate the SMARTConfigurable extension. Existing deployments that use them and should not be replaced unless new capability requirements demand runtime reconfiguration.

Legacy type catalog

Type	Primary use case	Compiled-in capabilities	Immutability guarantees	Equivalent DALPAsset preset
DALPBond	Fixed-income instruments	SMARTRedeemable, SMARTYield (legacy), SMARTCapped, SMARTHistoricalBalances	Fee structure and maturity terms fixed at deploy	Bond
DALPEquity	Shares with voting	ERC20Votes, SMARTHistoricalBalances	Voting mechanism fixed at deploy	Equity
DALPFund	Investment vehicles	Management fee, ERC20Votes, SMARTHistoricalBalances	Fee rate fixed at deploy	Fund
DALPStableCoin	Fiat-pegged tokens	SMARTCollateral, SMARTHistoricalBalances	Collateral mechanism fixed at deploy	StableCoin
DALPDeposit	General deposits	SMARTHistoricalBalances	Minimal constraints	Deposit
DALPRealEstate	Fractional property	SMARTCapped, SMARTHistoricalBalances, premint mechanism	Supply cap fixed at deploy	RealEstate
DALPPreciousMetal	Tokenized metals	SMARTHistoricalBalances	No supply cap, PAXG-style model	PreciousMetal

All types share the same SMART Protocol (ERC-3643) foundation, RBAC model, and factory deployment pattern as DALPAsset.

Compile-time vs runtime-configurable

The core architectural difference is when capabilities are bound to the token:

	Legacy (compile-time)	DALPAsset (runtime via SMARTConfigurable)
Binding	Features embedded in bytecode at compilation; cannot change	Features attached post-deployment; can be added, upgraded, or reconfigured
Governance	No configuration drift — contract is the complete spec	Configuration changes require role-gated transactions, multi-sig
Audit surface	Simpler — no reconfiguration paths or configuration state	Broader — must review feature attachment, composition, and permissions

Choose legacy when

Use this checklist to determine whether a specialized type is the right choice:

Compliance or legal framework requires that features (fee structure, maturity terms, collateral ratio) cannot change post-issuance
A stronger immutability guarantee is needed for investor trust — the on-chain contract is the complete, immutable specification
A simpler audit surface is preferred — no runtime reconfiguration paths to review
Existing deployments that work correctly and do not need new features

Choose DALPAsset when

Requirements may evolve post-deployment (add fees, governance, yield after launch)
Post-deploy feature attachment is needed for phased rollouts
A modular approach is preferred for multi-instrument deployments using a single contract type
All new projects (default recommendation)

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 (compiled-in 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 compiled-in 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

Mixed-fleet deployments are fully supported. DALPAsset and legacy types can coexist in the same deployment because they share the same foundation:

Same SMART Protocol (ERC-3643) — identical compliance enforcement, transfer rules, and identity registry integration
Same RBAC model — identical seven-role structure with the same role identifiers (see RBAC)
Same factory pattern — deployed through the same factory infrastructure with the same deployment invariants
Same upgradeability model — both support UUPS proxy or immutable deployment (see Deployment Architecture)

No migration is required. An organization can operate DALPBond tokens alongside DALPAsset tokens configured with the Bond preset. External systems (wallets, indexers, compliance dashboards) interact with both through the same ERC-20 and ERC-3643 interfaces.

Legacy Types