# Overview

Source: https://docs.settlemint.com/docs/architects/architecture/components/token-features
Token features attach fees, governance, lifecycle, yield, permit, and conversion behavior to DALPAsset tokens during issuance or later configuration.



Token features attach token-level behaviour to DALPAsset tokens. Asset designers, API integrators, compliance reviewers, and operators use this page to decide whether a behaviour belongs in a feature, a compliance module, a capability, or an instrument template.

Token features are part of the asset configuration. They control token economics, voting snapshots, maturity handling, permit support, yield, and conversion mechanics inside the DALPAsset lifecycle path. They do not own transfer-policy decisions, separate operational workflows, custody policy, off-chain settlement, or non-EVM asset behaviour. Use compliance modules for transfer-policy checks. Use capabilities for workflows such as settlement, distribution, treasury control, token sales, or signed data feeds.

Start with [AUM Fee](/docs/architects/architecture/components/token-features/aum-fee) when you need a fee-bearing asset, [Historical Balances](/docs/architects/architecture/components/token-features/historical-balances) when another feature needs point-in-time supply or balance data, [Conversion](/docs/architects/architecture/components/token-features/conversion) when the asset changes form through a configured lifecycle event, and [Feature constraints](/docs/architects/architecture/components/token-features/feature-constraints) before combining 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 an ordered execution path, not a loose catalogue. DALP creates configured feature contracts first, then attaches the complete ordered list to the asset. That order decides which feature sees a transfer, mint, burn, redemption, or attachment event first.

## Choose the right section [#choose-the-right-section]

| If you need to understand...                                           | Start here                                                                                                                                  |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| The base token, identity registry, roles, and deployment shape         | [Asset Contracts](/docs/architects/architecture/components/asset-contracts)                                                                 |
| Transfer eligibility, approvals, claim checks, or compliance policy    | [Compliance Modules](/docs/compliance-security/security/compliance) and [Asset policy](/docs/architects/architecture/concepts/asset-policy) |
| Token economics, snapshots, maturity, permit, yield, or conversion     | Token Features (this section)                                                                                                               |
| Settlement, distribution, treasury, sales, or signed market-data flows | [Capabilities](/docs/architects/architecture/components/capabilities)                                                                       |
| Operator template choices during asset creation                        | [Instrument templates](/docs/operators/user-guides/asset-creation/instrument-templates)                                                     |

***

## What token features are [#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.

Token features apply to [DALPAsset](/docs/architects/architecture/components/asset-contracts/dalp-asset) tokens. Legacy specialised asset types keep their capabilities in the deployed contract. They do not use this feature system.

<Mermaid
  chart="flowchart TD
  Template[Instrument template] --> Designer[Asset Designer or API request]
  Designer --> Factory[DALPAsset factory]
  Factory --> FeatureFactories[Feature factories]
  FeatureFactories --> Features[Configured feature contracts]
  Features --> OrderedList[Ordered feature list]
  OrderedList --> Asset[DALPAsset]

  Asset --> Precheck[Pre-operation checks]
  Asset --> Hooks[Mint, burn, transfer, redeem, attach hooks]
  Precheck --> Result[Allow, block, or rewrite operation]
  Hooks --> Result"
/>

Features run through lifecycle hooks in the order passed to `setFeatures()`. DALP creates configured features first and then attaches them atomically, so the array order is the execution order.

***

## Selection guide [#selection-guide]

Before choosing a token feature, decide which layer owns the behaviour:

| Reader question                                                                   | Right layer                                                                                        | Why it belongs there                                                                                           |
| --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Should this transfer be allowed, rejected, or routed through an approval process? | [Compliance Modules](/docs/compliance-security/security/compliance)                                | Compliance modules evaluate policy before token movement and keep legal or eligibility checks explicit.        |
| Does the asset need a separate operational workflow?                              | [Capabilities](/docs/architects/architecture/components/capabilities)                              | Capabilities coordinate workflows around the asset instead of changing the token's own lifecycle hooks.        |
| Should the token itself charge, snapshot, mature, yield, permit, or convert?      | Token Features (this section)                                                                      | Token features attach to DALPAsset and run from its lifecycle hooks.                                           |
| Does the setup need to be reused across many assets?                              | [Instrument templates](/docs/operators/user-guides/asset-creation/instrument-templates)            | Templates choose required features and define the feature settings that remain editable during asset creation. |
| Do any selected features require or exclude another feature?                      | [Feature constraints](/docs/architects/architecture/components/token-features/feature-constraints) | Constraint rules explain dependencies, mutually exclusive pairs, and feature-closure expansion.                |

***

## How features work [#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.      |

<Mermaid
  chart="flowchart TD
    A[Operator or API configures a DALPAsset] --> B[Template and feature settings]
    B --> C[Feature contracts are created]
    C --> D[Token receives ordered feature list]
    D --> E[Mint, burn, transfer, redeem, and attach hooks]
    E --> F[Feature state, fees, snapshots, yield, or conversion effects]"
/>

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 array order.

Recommended ordering: transfer-restriction features first, fee collection next, external fee hooks after that, 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()`. Run analytics features after it to observe post-collection supply.

| 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 [#feature-index]

### Fees & charges [#fees--charges]

| Feature                    | Purpose                                                                          | Detail                                                                                                           |
| -------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| AUM Fee                    | Time-based management fee as % of AUM. Mints new tokens to recipient             | [AUM Fee](/docs/architects/architecture/components/token-features/aum-fee)                                       |
| Transaction Fee            | Per-transaction fee deducted from transfer amount; `supportsRewriting = true`    | [Transaction Fee](/docs/architects/architecture/components/token-features/transaction-fee)                       |
| Transaction Fee Accounting | Tracks fees per transaction for off-chain reconciliation; no on-chain collection | [Transaction Fee Accounting](/docs/architects/architecture/components/token-features/transaction-fee-accounting) |
| External Transaction Fee   | Fixed fee in a separate ERC-20 (e.g., USDC) charged on every operation           | [External Transaction Fee](/docs/architects/architecture/components/token-features/external-transaction-fee)     |

### Governance & snapshots [#governance--snapshots]

| Feature             | Purpose                                                                                          | Detail                                                                                             |
| ------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
| Voting Power        | Delegated voting with historical tracking; compatible with Governor contracts                    | [Voting Power](/docs/architects/architecture/components/token-features/voting-power)               |
| Historical Balances | Point-in-time balance and total supply queries via checkpoints; required by Fixed Treasury Yield | [Historical Balances](/docs/architects/architecture/components/token-features/historical-balances) |
| Permit              | EIP-2612 gasless approvals. Sign off-chain, submit on-chain; no hooks                            | [Permit](/docs/architects/architecture/components/token-features/permit)                           |

### Lifecycle & yield [#lifecycle--yield]

| Feature              | Purpose                                                                                               | Detail                                                                                               |
| -------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Maturity Redemption  | Bond maturity lifecycle. Blocks transfers post-maturity; holders redeem for denomination asset        | [Maturity Redemption](/docs/architects/architecture/components/token-features/maturity-redemption)   |
| Fixed Treasury Yield | Fixed-rate yield at intervals from treasury; pull-based (holders claim); requires Historical Balances | [Fixed Treasury Yield](/docs/architects/architecture/components/token-features/fixed-treasury-yield) |

### Transformation [#transformation]

| Feature                                        | Purpose                                                                                                 | Detail                                                                           |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Conversion (Loan) + Conversion Minter (Equity) | Convertible instrument pair. Triggers, burns loan tokens, mints equity; cooperative two-contract design | [Conversion](/docs/architects/architecture/components/token-features/conversion) |

***

## How templates use features [#how-templates-use-features]

Instrument templates can make token features part of an issuance pattern. When a template requires a feature, the Asset Designer 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 supplied 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](/docs/architects/architecture/components/token-features/feature-constraints) for dependency and incompatibility rules, and [Instrument templates](/docs/operators/user-guides/asset-creation/instrument-templates) for the operator workflow.

***

## Access control summary [#access-control-summary]

| Role              | Scope                                                                                          |
| ----------------- | ---------------------------------------------------------------------------------------------- |
| `GOVERNANCE_ROLE` | Configuration and policy changes, including fee rates, triggers, schedules, treasury addresses |
| `CUSTODIAN_ROLE`  | Operational actions on behalf of holders, including forced conversion and early maturity       |

## Operational checks before issuance [#operational-checks-before-issuance]

Before issuing an asset with token features, check four things:

1. The selected instrument template requires the expected features and leaves only the intended settings editable.
2. [Feature constraints](/docs/architects/architecture/components/token-features/feature-constraints) allow the selected feature set and report no missing dependency or incompatible feature pair.
3. Rewriting features run before snapshot, analytics, or governance features that need post-fee balances.
4. The account changing feature configuration has `GOVERNANCE_ROLE`; the account running holder-level operational actions has `CUSTODIAN_ROLE` only where that feature requires it.

For implementation work, continue to [Instrument templates](/docs/operators/user-guides/asset-creation/instrument-templates) for the operator flow or [Token lifecycle API integration](/docs/developers/developer-guides/api-integration/token-lifecycle) for API-driven issuance and updates.