# Overview

Source: https://docs.settlemint.com/docs/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. This overview is for asset designers, API integrators, compliance reviewers, and operators who need to decide whether token-level behaviour belongs in a feature, a compliance module, a capability, or an instrument template.

Token features are owned as 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/architecture/components/token-features/aum-fee) when you need a fee-bearing asset, [Historical Balances](/docs/architecture/components/token-features/historical-balances) when another feature needs point-in-time supply or balance data, [Conversion](/docs/architecture/components/token-features/conversion) when the asset changes form through a configured lifecycle event, and [Feature constraints](/docs/architecture/components/token-features/feature-constraints) when you need to validate dependencies or mutually exclusive feature pairs.

> **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/architecture/components/asset-contracts)                                                          |
| Transfer eligibility, approvals, claim checks, or compliance policy    | [Compliance Modules](/docs/architecture/security/compliance) and [Asset policy](/docs/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/architecture/components/capabilities)                                                                |
| Operator template choices during asset creation                        | [Instrument templates](/docs/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/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/architecture/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/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/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/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 six lifecycle hooks:

| Hook                              | Trigger                                        | Notes                                     |
| --------------------------------- | ---------------------------------------------- | ----------------------------------------- |
| `canUpdate(from, to, value, ...)` | Pre-check before any operation                 | View only. Reverts to block the operation |
| `onMinted(to, amount)`            | After minting                                  |                                           |
| `onBurned(from, amount)`          | After burning                                  |                                           |
| `onTransferred(from, to, amount)` | After transfers                                |                                           |
| `onRedeemed(from, amount)`        | After redemptions                              |                                           |
| `onAttached()`                    | After feature registration via `setFeatures()` |                                           |

<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/architecture/components/token-features/aum-fee)                                       |
| Transaction Fee            | Per-transaction fee deducted from transfer amount; `supportsRewriting = true`    | [Transaction Fee](/docs/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/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/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/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/architecture/components/token-features/historical-balances) |
| Permit              | EIP-2612 gasless approvals. Sign off-chain, submit on-chain; no hooks                            | [Permit](/docs/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/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/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/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/architecture/components/token-features/feature-constraints) for dependency and incompatibility rules, and [Instrument templates](/docs/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       |