Token features overview
Token features attach fees, governance, lifecycle, yield, permit, and conversion behavior to DALPAsset tokens during issuance or later configuration.
Token features are the runtime extension layer for DALPAsset tokens. They attach economics, snapshots, maturity handling, yield, permit, and conversion mechanics to the token lifecycle. Read this section to place an asset behaviour in the right DALP layer.
Token features run inside the DALPAsset lifecycle path, not in the compliance or capability layers.
Compliance modules decide transfer-policy checks. Capabilities coordinate separate workflows such as settlement, distribution, treasury control, token sales, or signed data feeds. Instrument templates package repeatable asset setup choices for operators. Start with AUM Fee for fee-bearing supply models, Historical Balances for point-in-time supply or balance data, and Conversion when the asset changes form through a configured lifecycle event. Check Feature constraints before you combine features on one asset.
Availability: DALPAsset and token features are feature-flagged surfaces. Confirm that the required asset type and feature set are enabled in the target environment before using these pages for an implementation plan.
The feature list is a sequenced execution path, not a loose catalogue. DALP creates configured feature contracts first, then attaches the complete list to the asset in that sequence. Position in the list decides which feature sees a transfer, mint, burn, redemption, or attachment event first.
Choose the right section
Use the table below to find the right documentation for your task.
| If you need to understand... | Start here |
|---|---|
| The base token, identity registry, roles, and deployment shape | Asset Contracts |
| Transfer eligibility, approvals, claim checks, or compliance policy | Compliance Modules and Asset policy |
| Token economics, snapshots, maturity, permit, yield, or conversion | Token Features (this section) |
| Settlement, distribution, treasury, sales, or signed market-data flows | Capabilities |
| Operator template choices during asset creation | Instrument templates |
What token features are
Token features are runtime extensions to DALPAsset through the ISMARTFeature interface. They add fees, yield, governance, maturity, permit support, and conversion handling. They apply only to DALPAsset tokens.
Legacy specialised asset types keep their capabilities in the deployed contract and do not use this feature system.
Features run through lifecycle hooks in the sequence passed to setFeatures(). DALP creates each configured feature contract first and then attaches the full set atomically, so the array position is the execution order.
Selection guide
Before you choose a token feature, decide which layer owns the behaviour. The table below maps each decision to the right section.
| Decision to make | Right layer | Why it belongs there |
|---|---|---|
| Allow, reject, or route transfers through an approval process | Compliance Modules | Compliance modules evaluate policy before token movement and keep legal or eligibility checks explicit. |
| Coordinate a separate operational workflow around the asset | Capabilities | Capabilities coordinate workflows around the asset instead of changing the token's own lifecycle hooks. |
| Make the token charge, snapshot, mature, yield, permit, or convert | Token Features (this section) | Token features attach to DALPAsset and run from its lifecycle hooks. |
| Reuse setup choices across many assets | Instrument templates | Templates choose required features and define the feature settings that remain editable during asset creation. |
| Check whether selected features require or exclude another feature | Feature constraints | Constraint rules explain dependencies, mutually exclusive pairs, and feature-closure expansion. |
How features work
Features integrate through lifecycle hooks and an optional rewrite step:
| Hook | Trigger | What the feature can do |
|---|---|---|
canUpdate(from, to, value, ...) | Before a mint, burn, or transfer | View only. Revert to block the operation before state changes. |
rewriteUpdates(...) | During the update pipeline when enabled | Split, add, filter, or pass through token updates. Called only when rewriting is active. |
onMinted(to, amount) | After minting | Update feature state after new supply is created. |
onBurned(from, amount) | After burning | Update feature state after supply is removed. |
onTransferred(from, to, amount) | After transfers | Update feature state after balances move. |
onRedeemed(from, amount) | After redemptions | Update feature state after redemption. |
onAttached() | After feature registration via setFeatures() | Resolve dependencies or initialise feature state after all features are registered. |
Features with supportsRewriting() = true can modify the transfer amount in flight, for example by deducting a fee before the amount reaches the recipient. Features execute in the configured sequence.
Place transfer-restriction features first, fee-collection features second, external fee hooks third, and analytics or governance features last.
Transaction Fee and External Transaction Fee rewrite amounts. Run analytics features after them to snapshot post-fee balances. AUM Fee mints new tokens through collectFee(). Place analytics features after it to observe post-collection supply. The table below shows position, category, and rationale for each feature.
| Position | Category | Features | Why it belongs there |
|---|---|---|---|
| First | Transfer restriction | Maturity Redemption, Conversion (loan-side) | Blocks or changes lifecycle state before fees are applied |
| After restrictions | Fee collection | AUM Fee, Transaction Fee, Transaction Fee Accounting | Applies token economics after eligibility is known |
| After fee collection | External fee hooks | External Transaction Fee | Charges the separate fee asset after the token amount |
| Last | Analytics & governance | Historical Balances, Voting Power | Records the post-operation state used for lookups |
| Order irrelevant | No-hook utilities | Permit, Conversion Minter | Does not participate in the transfer hook path |
Feature index
Fees & charges
| Feature | Purpose | Detail |
|---|---|---|
| AUM Fee | Time-based management fee as % of AUM. Mints new tokens to recipient | AUM Fee |
| Transaction Fee | Per-transaction fee deducted from transfer amount; supportsRewriting = true | Transaction Fee |
| Transaction Fee Accounting | Tracks fees per transaction for off-chain reconciliation; no on-chain collection | Transaction Fee Accounting |
| External Transaction Fee | Fixed fee in a separate ERC-20 (e.g., USDC) charged on every operation | External Transaction Fee |
Governance & snapshots
| Feature | Purpose | Detail |
|---|---|---|
| Voting Power | Delegated voting with historical tracking; compatible with Governor contracts | Voting Power |
| Historical Balances | Point-in-time balance and total supply queries via checkpoints; required by Fixed Treasury Yield | Historical Balances |
| Permit | EIP-2612 gasless approvals. Sign off-chain, submit on-chain; no hooks | Permit |
Lifecycle & yield
| Feature | Purpose | Detail |
|---|---|---|
| Maturity Redemption | Bond maturity lifecycle. Blocks transfers post-maturity; holders redeem for denomination asset | Maturity Redemption |
| Fixed Treasury Yield | Fixed-rate yield at intervals from treasury; pull-based (holders claim); requires Historical Balances | Fixed Treasury Yield |
Transformation
| Feature | Purpose | Detail |
|---|---|---|
| Conversion (Loan) + Conversion Minter (Equity) | Convertible instrument pair. Triggers, burns loan tokens, mints equity; cooperative two-contract design | Conversion |
How templates use features
Instrument templates can make token features part of an issuance pattern. When a template requires a feature, the Console shows that feature as part of the selected template and collects any settings that the template leaves editable during asset creation.
For DALPAsset creation through the API, templateId is required. The API reads the selected template, combines the template's required features with any feature configuration you supply in the request, and rejects incompatible feature combinations before the token is created.
Template-backed feature setup gives operators two controls:
| Control | What it does |
|---|---|
| Required features | Attach the token behaviours that every asset from the template must include. |
| Editable settings | Decide which feature settings operators can change in the Asset Designer and which settings stay locked on the template default. |
See Feature constraints for dependency and incompatibility rules, and Instrument templates for the operator workflow.
Access control summary
Two roles govern token feature operations.
| Role | Scope |
|---|---|
GOVERNANCE_ROLE | Configuration and policy changes, including fee rates, triggers, schedules, treasury addresses |
CUSTODIAN_ROLE | Operational steps on behalf of holders, including forced conversion and early maturity |
Operational checks before issuance
Before you issue an asset with token features, check four things:
- The selected instrument template requires the expected features and leaves only the intended settings editable.
- Feature constraints allow the selected feature set and report no missing dependency or incompatible feature pair.
- Rewriting features run before snapshot, analytics, or governance features that need post-fee balances.
- The account changing feature configuration has
GOVERNANCE_ROLE; the account running holder-level operations hasCUSTODIAN_ROLEonly where that feature requires it.
For implementation work, continue to Instrument templates for the operator flow or Token lifecycle API integration for API-driven issuance and updates.
Deployment Architecture
Factory deployment pattern for DALP asset tokens, covering CREATE2 deterministic addressing, initialization invariants, deployment failure modes, and custodian administrative controls.
Feature constraints
Understand DALP token feature dependencies, mutually exclusive pairs, feature-closure expansion, validated configuration ranges, and the split between UI, API, and smart-contract enforcement.