# Token features that behave like instruments
Source: https://docs.settlemint.com/docs/changelog/dalp-3-0/token-features
Fees, yield, redemption, and conversion now carry the controls a real financial instrument needs.
**We gave every token feature the operational depth a servicing team actually needs. Fees have audit trails. Yield has schedules and claims. Redemption has per-holder history. Conversion validates its own preconditions before you deploy.**
A token feature is a capability you switch on for an asset. In 3.0, the four that matter most grew from simple on-chain switches into servicing-grade instruments. Each one preflights, audits, and guards itself so your operations team and your auditors read the same record.
A plain ERC-20 moves value. What it cannot do on its own is charge a fee and record who paid, accumulate interest and let a holder claim their share, redeem at maturity and index that event per holder, or convert while enforcing its own prerequisites. In 3.0, those four capabilities crossed that line.
The difference matters most for regulated instruments. A fee fires and disappears: acceptable for a utility token, a liability for a bond or fund share where the questions "who paid, was this address exempt, what rate applied" need a single auditable answer. The same pressure applies to yield. A claim that cannot be reconstructed from platform records forces a reconciliation exercise every reporting period. We built the record in so it does not need to be rebuilt later.
## Why this matters for regulated assets [#why-this-matters-for-regulated-assets]
When institutions ask what changed in 3.0, the answer is not a list of new API endpoints. The answer is that token features now hold themselves to the same standard a regulator or auditor would. Regulated securities carry obligations that go beyond the transfer itself. A fee must be declared and traceable. Interest must be calculated from a stated schedule and paid to the right holders. Redemption at maturity must close positions cleanly and leave a verifiable record. A conversion must happen at the agreed terms, not at whatever the contract happens to do if the prerequisites were silently misconfigured.
None of these obligations disappear because the instrument is on-chain. If anything, regulators expect the on-chain record to be the primary source of truth. Before 3.0, the gap between what lived on-chain and what the operations team needed to answer regulatory questions was real and was bridged by off-chain tooling. Every bridge is a reconciliation risk. We closed those gaps at the source.
## Fees with a full audit trail [#fees-with-a-full-audit-trail]
When a servicer or auditor asks which transfers were charged, at what rate, and which addresses are exempt, the answer cannot be "check the event log." Fee collections are now indexed as platform records. You can preview what a fee will cost before any operation runs, inspect every collection after it settles, manage exemptions per address, and see exactly who paid and who did not.
We cap fee rates at the contract level and reject a zero-address recipient on setup. Fee-recipient behavior is also preserved after a freeze, a pattern that previously required manual inspection to verify. An AUM fee accrues against the token's time-weighted supply, collected through minting new units to the configured recipient. External-fee totals survive a change of fee token because accounting tracks the token separately from the balance.
Configure, preview, and inspect transfer fees with full exemption management.
Collections, exemptions, and accruals, persisted for review. External-fee totals survive a change of fee token.
Assets-under-management fee with rate caps and recipient validation.
Route fees through an external token with full accounting parity.
## Yield with schedules and claims [#yield-with-schedules-and-claims]
Yield is where the gap between token and instrument shows most clearly. A raw on-chain rate tells you how interest accrues per period. It does not tell you who claimed, how much consumed interest was recorded, or whether accrual periods that closed correctly were accounted for. When an investor asks for a year-end statement or an auditor traces a payout discrepancy, that information has to come from somewhere.
Fixed treasury yield now carries the full lifecycle a bond or structured product requires. Set a denomination asset, a rate in basis points, an accrual interval, and a treasury wallet. The feature accrues per holder per block-aware tick. Holders claim their share through the platform. Consumed interest posts to the platform record at claim time and persists for reconciliation. Accrual period boundaries can be tracked, and when the yield end date diverges from the instrument's maturity date, the feature warns you. That last guard closes a class of misconfiguration that was previously silent.
Rate changes are restricted-mutable by design. You plan them around accrual-period boundaries to avoid mid-period ambiguity for holders. If a holder transfers their position, accrual moves with the balance: the source wallet stops accruing at the transfer block, and the destination wallet starts.
[Fixed treasury yield API →](/docs/api-reference/token-features/fixed-treasury-yield)
## Redemption per holder [#redemption-per-holder]
Maturity redemption now preflights allowances and treasury state before the operation runs. The Console shows a live solvency check: while the treasury balance is resolving, the redeem button stays disabled. If the treasury cannot cover the payout, the sheet shows the funding gap with the requested amount and the available balance side by side. The holder cannot proceed until the treasury is adequately funded.
After the treasury check passes and the holder signs, the feature transfers the face value from the treasury to the holder and burns the position. That event indexes per holder in the platform record. The servicing record a bond or debt instrument needs is in the platform, not in a spreadsheet maintained in parallel.
Self-denominated redemption setups are blocked at creation. Feature pairs that are mutually incompatible are caught at design time, not at maturity when it is too late to correct them.
[Maturity redemption API →](/docs/api-reference/token-features/maturity-redemption)
## Conversion that validates itself [#conversion-that-validates-itself]
A convertible instrument carries a structural dependency. The conversion feature requires a counterpart minter on the target token. Without an upfront check, a misconfigured convertible can sit in production for weeks before a conversion attempt surfaces the problem. We moved that check to design time.
When you configure conversion, the platform validates the dependency immediately and rejects the configuration if the counterpart minter is absent. It also validates discount terms at the same step. An out-of-range discount fails at creation, not at execution when a holder is waiting. The target token address is verified against deployed platform tokens before you can proceed: a well-formed but undeployed address is caught in the wizard, not in a failed transaction.
Partial-conversion support, interest-in-conversion inclusion, and conversion-window dates are all configurable. When the conversion window closes, mandatory conversion can force-convert any remaining holdings according to the configured terms.
Discount validation and dependency enforcement for convertible instruments.
The required counterpart to conversion, enforced at design time.
## Transfer approval and collateral, fully in the Console [#transfer-approval-and-collateral-fully-in-the-console]
The second-generation transfer-approval and collateral modules are now fully driveable from the product. A token on the v2 transfer-approval module surfaces its Approve and Revoke Transfer Approval controls in the pending-approvals panel. A token on the v2 collateral module shows a coverage card, a collateral-management control, live collateral-ratio statistics, and a no-claim warning. The underlying contract controls existed before. DALP 3.0 makes them operable without dropping to the API.
## Claim long yield backlogs in bounded batches [#claim-long-yield-backlogs-in-bounded-batches]
Yield claims now cap how many accrual periods a single transaction processes, which makes per-call gas deterministic. A holder who has been idle for hundreds of periods clears the backlog in controlled batches instead of hitting the block gas limit. The Console chains these transactions automatically until the holder is caught up, so operators and holders do not manage the rounds by hand. A holder loses no yield: unsettled periods remain claimable and the next claim picks them up.
Repeatable batched conversion drains the full accrued-interest backlog into target tokens. The final conversion in a sequence reverts with a clear error rather than silently rerouting unclaimed yield to cash.
## Manage on-chain metadata in place [#manage-on-chain-metadata-in-place]
Operators can add, edit, and remove a token's on-chain key-value metadata directly from its detail page. The controls are governance-gated and respect each entry's mutability and the caller's permissions, so reference data lives on-chain with the asset instead of in a side system that drifts out of sync.
## Mutation prechecks across the board [#mutation-prechecks-across-the-board]
Every state-changing operation now runs a preflight before it executes. Burn, transfer, forced-transfer, pause, freeze, balance check, address validation, and indexer-lag checks all fire before the mutation is submitted. Failures surface at the confirmation step, not on-chain. This pattern eliminates a class of transaction failures that previously cost gas and required a support escalation to diagnose.
## Built on open token standards [#built-on-open-token-standards]
Every instrument issues as a fully compliant ERC-20, the foundational fungible-token standard on Ethereum. That means it exposes the `transfer`, `approve`, and `allowance` interface any ERC-20-aware wallet, exchange, or DeFi protocol already understands. Starting from ERC-20 is not a constraint. That foundation is what lets a regulated token plug into the broader network without requiring the network to know what regulations govern it.
ERC-20 alone cannot stop a transfer to a non-verified counterparty, enforce an investor cap, or freeze a balance on a regulatory order. For regulated assets where those controls are mandatory, adding them as one-off overrides produces tokens every issuer writes differently. ERC-3643 solves this at the standard level. It extends ERC-20 with four on-chain components: an identity registry, a trusted-issuers registry, a claim-topics registry, and a compliance module. Together they map each address to a verified identity, record the credential authorities, define which credentials a holder must carry, and enforce those rules inside every transfer. Our implementation layers the full ERC-3643 compliance stack on top of OpenZeppelin's battle-tested ERC-20 base, so the regulated controls we add in fees, yield, redemption, and conversion run inside an audited, standards-conformant token.
ERC-2612, the permit extension standardised by EIP-712 typed-data signatures, removes the two-transaction pattern that ERC-20 approvals normally require. Instead of broadcasting a separate `approve` transaction, the holder signs an off-chain `Permit` message with a deadline and nonce. Any relayer can then submit that signature on-chain in a single call that both approves and acts atomically. For a regulated-asset workflow, the practical benefit is gasless approvals embedded inside a serviced operation: the holder authorises without holding native gas, and the operation executes in one step. Permit is implemented through OpenZeppelin's `EIP712`, `Nonces`, and `IERC20Permit` contracts and supports both ECDSA key signatures and ERC-1271 contract signatures.
The instrument behaviors above, fees, yield, redemption, conversion, and transfer approval, are layered on this standards foundation.
Taken together, the four features now behave the way a servicer expects an instrument to behave: self-describing, self-guarding, leaving a record that survives the next audit. The operational surface grew with them. Prechecks, bounded batch flows, metadata controls, and Console visibility all reduce the gap between "configured on-chain" and "operable by a team that does not live in the API."
[Browse all token feature APIs →](/docs/api-reference/token-features)