Token features that behave like instruments

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

Servicing recordsCopy Anchor Link

Fee collections, yield claims, redemptions, and conversions need records that an operator can reconcile. The platform indexes these outcomes alongside the instrument. Review the instrument terms and applicable requirements when using those records for reporting.

Fees with a full audit trailCopy Anchor Link

When a servicer or auditor asks which transfers were charged and which addresses were exempt, the answer cannot be "check the event log." Fee collections are indexed as platform records. You can preview costs, inspect collections, and manage exemptions.

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.

Yield with schedules and claimsCopy Anchor Link

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 →

Redemption per holderCopy Anchor Link

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 →

Conversion that validates itselfCopy Anchor Link

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.

Transfer approval and collateral, fully in the ConsoleCopy Anchor Link

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 batchesCopy Anchor Link

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 placeCopy Anchor Link

Operators can manage a token's on-chain key-value metadata directly from its detail page: add new entries, update existing ones, or remove stale ones. 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 boardCopy Anchor Link

Supported mutation flows run prechecks for permissions, balances, allowances, and indexed state before submission. A precheck can identify a failure earlier, but state can change before execution and the contract still enforces its rules.

Built on open token standardsCopy Anchor Link

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. It has no mechanism to 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 and enforce the required credentials inside every transfer. Credential authorities are declared separately so they can be updated without redeploying the token. Our implementation layers the full ERC-3643 compliance stack on top of OpenZeppelin's ERC-20 base, so the regulated controls added for fees, yield, redemption, and conversion run inside the token's identity and compliance controls.

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.

All five instrument behaviors described above run inside this standards-conformant token: every fee, yield accrual, redemption event, conversion, and transfer approval uses the token's configured controls.

The Console exposes prechecks, batched claims, metadata controls, and indexed servicing records for these features.

CompatibilityCopy Anchor Link

These features are new capability, layered on the standards described above. They change no existing API behavior and deprecate nothing: an instrument issued before 3.0 keeps working with whatever features it was issued with, and adopting fees, yield, redemption, or conversion on a new instrument is opt-in at design time.

Browse the token feature endpoints in the API explorer →