A template selects the facts, ordered features, and rules for one contract model, which gives product coverage through composition.
A composable token is the one ERC-20-compatible asset contract the platform deploys for every instrument, with identity, role and compliance controls built in and an ordered list of token features that carry its behaviour. An issuer brings a new instrument to market by configuring it, with no new contract code, as long as the platform's features, fact fields and compliance modules cover the design.
Feature order is policy: it decides which feature sees which amount.
A feature attaches at creation or on a live asset. The generic feature lifecycle API replaces its configuration by rotating the instance.
Why a new instrument does not need new contract code
An issuer that wants a new instrument type on a platform built from one contract per asset type waits on a new contract, because coverage only grows when one ships. A Composable Token removes that wait. Every instrument the platform issues, a bond, a fund, a sukuk, a structured note, or a shape an issuer defines, comes from the same regulated contract model, configured instead of rebuilt. The second bond of a given design reuses the first one's template instead of commissioning another contract.
One regulated contract model is deployed for every instrument, and each issued token carries its own configuration of instrument facts, token features, and compliance rules. A token feature is a module that adds one behaviour, such as a fee or a coupon. Available features, metadata fields, and compliance modules bound the instrument designs a deployment can issue.
The Instrument Template is the off-chain product definition. It names the required features and the compliance choice, and so records the product shape. The features hold the behaviour, for example transfer fees, coupon and yield schedules, voting power, conversion windows, historical balance snapshots, and the other regulated behaviours the platform registers. Underneath every entry sits the same regulated token core, the base balance and transfer logic every instrument shares. The platform deploys one instance of this contract model for each instrument on an EVM-compatible network.
A bond, fund, sukuk, loan, structured note, or commodity still names a financial instrument, and the platform still records which one an asset is. Two instruments of different types differ in their configuration, and the contract model behind them is the same.
Responsibilities divide the same way. Composition provides the digital mechanics and policy hooks, and the template records the product shape the platform uses. Legal terms, regulatory classification, and suitability remain issuer responsibilities, detailed in the controls and evidence section.
How composition works
A Composable Token is one shared regulated asset contract initialised with the regulated token core, identity and role controls, metadata, pause and custody behaviour, and a per-token compliance contract. The asset factory, the deployed contract that creates every token, creates configured Token Features and installs their addresses as one ordered set during deployment. The instrument facts come from the template the issuer chose, so the deployment starts from an approved product shape instead of a blank contract.
The list is written as one complete ordered set. The factory creates all requested feature instances first, then sets that list in the same transaction. If a feature factory is missing or creation fails, the transaction reverts instead of leaving an asset with a partial feature set.
An operation runs through that list in three phases. In the first, every feature is asked whether the operation may proceed, and each is asked about the operation exactly as the caller requested it. Only the second phase is a pipeline.
Second, the features that rewrite run in list order, and this is where a result is handed on. Each rewriter receives the original operation and the legs the previous rewriter produced. A leg is one balance movement the operation settles into. The rewriter may split, resize, or add to the legs. Each resulting leg is then executed through the token's full pipeline, which asks the first-phase question again for that leg.
Third, every feature is notified once. The notification reports both the original operation and the legs that executed. These three calls, the question, the rewrite, and the notification, are the hooks a feature receives. The whole run is atomic: the legs settle and every feature sees them, or the operation reverts and nothing changes.
Only the rewriting phase hands a result on, while the question before it and the notification after it reach every feature with the same inputs.
So position is a behavioural choice among the rewriting features and only among them. Put a fee rewriter ahead of another rewriter and the second one works from the legs the first produced, which changes the amounts that settle. The recommended order puts hold first, then transfer restrictions such as maturity blocks and conversion locks first, fee collection next, external fee hooks that account for fees in another token after that, and analytics last. A restriction cannot be outranked by moving a fee feature above it, because a refusal reverts the whole operation, not one stage of it. An analytics feature such as a historical-balance or voting-power snapshot cannot record an amount no holder received. It is told the executed legs wherever it sits in the list, so its position does not change that notification.
An instrument template defines the composition off chain, before anything is deployed. A template binds an asset class, instrument-fact schema, base asset type, required feature identifiers, and a compliance template. The Platform API checks feature dependencies and incompatible pairs before it publishes or uses that template. The asset factory then resolves each feature type to its registered factory and creates the on-chain instances. The factory itself checks neither dependencies nor conflicts.
System addons sit at a different level of the same deployment. They are shared components registered once per deployment, such as the settlement and feature factories, and their registry controls which implementations a deployment can use. An addon is shared deployment infrastructure, and a token feature is per-instrument behaviour. An addon can supply the factory that creates a feature, and each resulting token feature belongs to one token.
Issuing from the template catalogue
Issuing a composable token starts with an instrument template: the reusable product shape that collects the instrument facts, required token features, and compliance choice the creation flow needs. The operator supplies the values this issue needs for the facts the template defines, and deploys the configured asset.
The catalogue is a set of reusable starting shapes. System templates cover common products, while organisation templates capture the product designs your own firm has approved. A platform-supplied template stays a shared baseline: it cannot be edited or deleted, and an attempt answers DALP-14365. What you can change is whether your organisation offers it: unpublish it to remove it from your issuance flow, or hide it to keep it out of the template picker whatever its published state. Copy it into an organisation template when you need it to differ.
Two checks run before a template can be published. A required feature whose dependency is absent answers DALP-14094, for example dividend yield without historical balances, because the feature cannot read the balances it pays on. Add the missing dependency to the template's required features and publish again. A pair of features that cannot run on one token, such as transaction fee with transaction fee accounting, or register lines with a feature that moves units, answers the same DALP-14094. Keep one of the pair. Its data.reason names each feature involved. Both checks run again at creation, where the same conflicting-feature pair answers DALP-0605 instead, so a template edited around a check does not reach a deployed asset.
Editing a template never changes tokens already issued from it. A template configures a deployment. Once an asset exists, its ordered feature list and its own compliance contract live on chain, and editing the template writes nothing there and starts no transaction. The link survives the edit, so those assets stay listed and filtered under the template's current name, slug, and asset class. Changing what a live asset does means changing that asset, by attaching or rotating features on it.
Servicing a live asset
Servicing a live composable token means driving its feature lifecycle, because the features are where its behaviour lives. An account with the token's governance role attaches, detaches and rotates features. It also needs Supply management and Custodian, or the admin role, because a feature acts with those powers. Attached features are on-chain capability contracts with their own state, and the token feature endpoints in the API reference drive all three lifecycle moves. Attach adds a feature, detach removes it, and rotation replaces it with a new instance carrying new configuration. The generic feature lifecycle API changes configuration through rotation, and the replaced instance stays on chain. Feature-specific operations can update settings that the feature permits, such as a treasury address before maturity.
Attach and rotation append an instance to the ordered list. Detach removes an instance. A newly attached feature joins the end, and there is no position parameter on the request. A rotated feature's replacement instance also joins the end instead of inheriting the old position, so rotating a rewriter that ran ahead of another rewriter changes execution order as well as configuration. The Platform API never repositions an existing entry, so when position matters, attach or rotate the features in the sequence you want them to settle in. On chain, an account with those roles can replace the whole ordered list in one setFeatures call, which can reorder, remove or add entries.
Rotation is also the reason a detach is rarely the right tool for a configuration change. A rotate retires the current instance and installs its replacement in the same write, so the hooks keep flowing and no window opens. Reach for a detach only when the behaviour itself must stop.
While a feature is off the list it receives no hooks, so any state it derives from balances stops tracking them, and the missed window is never backfilled. After a reattach, totals the feature can recompute from live on-chain state are right again at once. Per-holder derived values catch up only when that holder's balance next moves. A voting-power feature detached across a mint re-seeds its total supply on reattach and reads a holder's own units live, but a delegate's vote count catches up only when the delegating holder next moves, and votes weighted as of a block inside the window read the wrong totals permanently. Plan the window across a quiet period for the affected feature instead of treating a detach as a toggle. Detaching a restricting feature, such as maturity redemption or hold, also removes its restriction from the next operation on.
Neither the Console nor the Platform API detaches or rotates conversion or the distribution waterfall after issuance. The Platform API also refuses to detach or rotate dividend yield while declared dividends are unclaimed. The token itself does not protect these features: an account with the roles that set the feature list can remove either of the first two on chain with setFeatures.
Rotating a feature keeps hooks flowing, while detaching opens a window in which no hooks arrive and derived state freezes.
Four configuration facts decide what a composable token does, and they differ in what it takes to change them.
When an off-chain register decides every movement
A feature can also refuse every movement the token would otherwise make. The Booked movements feature, which the Features tab lists as “Register lines”, does this for a share class whose legal register a transfer agent or fund administrator keeps off chain. Each change to a holding becomes a movement on the token. An investor requests it or the administrator enters it, and an administrator with the token's Supply management role, which allows minting and burning, books it with the reference of its register entry, which moves the units in the same transaction. The token refuses every other mint, burn, transfer, forced transfer and wallet recovery, and it refuses any other feature that would move units. These refusals last while Booked movements is attached. An account with the roles that set the feature list can detach it, and from then on the token accepts ordinary mints, burns and transfers again. Features that never move the token, such as dividend yield, keep working on the booked balances.
The Share-Class Mirror instrument template issues such a token with Historical balances, Hold and Booked movements attached and no compliance policy, because the register decides who may hold the class. Every recipient still needs a verified identity. Each share class is its own token, so a fund with several classes has one mirror token per class, and every register entry is booked on the token of its class. Hold reserves the units of an open request, which is why Booked movements needs it attached. Features that move units outside a movement, such as Management fee, Conversion, Conversion minter, Supply delegate and Maturity redemption, cannot sit beside it. Booked movements covers the Console workflow, the refusals and the API routes.
The integration contract
Developers integrate with composable tokens through the generic asset and feature surfaces instead of a switch over fixed contract names. Creation input specifies the asset metadata, the concrete instrument type name, initial metadata entries, and an ordered list of feature type and configuration pairs. The name enters the deterministic deployment address, and the list fixes the execution order of the transfer pipeline.
The instrument type name identifies the template-backed shape, even though the implementation is the generic asset contract. Treat it as instrument metadata and deployment identity, never as proof that a dedicated bond or equity implementation exists. Integration code branches on the features it finds attached.
Feature identifiers are registry keys. The asset factory derives the matching feature-factory key, resolves it from the system addon registry, creates the feature, and installs the returned address. Integrations should read attached feature state through the generic discovery surface, then use the interface of the feature type they find. Integration code varies by feature type, not by template.
Listing a token's features through the API returns them sorted alphabetically by name, so that order carries no meaning. When order matters, read the ordered list from the chain through the token's getFeatures() function, because that is the list the transfer pipeline runs.
Do not assume that a feature type appears only once over an asset's life. Detach and reattach operations can leave several historical instances. For a current operation, select the attached instance that most recently became active. For audit or history, retain the detached records.
Feature lifecycle writes are asynchronous, so a caller reads or waits for the settled result instead of treating the initial response as completion. Attaching a feature the token already holds is refused with the reason already-attached. Rotate the existing instance instead of retrying the attach. The exact status codes, headers, and response shapes for these calls are in the token feature endpoints in the API reference. After settlement, list the token's features to read the deployed address instead of deriving it.
Creation has its own rejections worth designing for. A request without an instrument template answers DALP-0316, because there is no template-free creation path. A token type with no registered factory in the active system answers DALP-0314. Choose a type the deployment registers. A denomination asset that does not expose readable ERC-20 symbol() and decimals() answers DALP-9073, because maturity and coupon features read that metadata on chain after the asset deploys.
Controls and evidence
Each composable token has its own compliance contract, so one instrument's policy does not become an implicit rule for every asset in a deployment. Before balances change, that contract checks the token's installed rules and the system-wide rules for the sender, receiver, amount and token, and a failed check reverts the transfer. A custodian forced transfer and a wallet recovery skip those rules. The check that the recipient has a verified identity still runs, and attached features still see the operation with a forced flag, so a feature such as Booked movements can still refuse it. The token's governance role can install, turn off, reconfigure or remove its rules, and it can point the token at a different compliance contract.
The instrument template links the product shape to a selectable compliance template. The platform rejects a draft compliance template, an unsupported module-set version, or an incompatible module set before the link becomes deployable. This moves a class of configuration failures ahead of asset creation.
Supply, governance, custody and emergency operations stay gated by the asset's access manager, the contract that holds its role assignments. An attached feature acts with the token's authority: it can move units between any two accounts, mint, burn and set an allowance, and each move still runs the token's identity and compliance checks. The token accepts any contract that names it as a feature, so setting the feature list needs the governance role together with Supply management and Custodian, or with the admin role. Whoever chooses which contracts hold that authority must already hold those powers or be able to grant them to itself.
Every composable token runs the implementation its asset factory names. A system manager can replace that implementation, which changes the code of every composable token in the system at once, and the factory emits Token with the old and new address.
The evidence follows the same split as the architecture. An auditor reads three sources.
Frequently asked questions
Can a standard ERC-20 wallet hold a Composable Token?
Yes. The asset contract implements the ERC-20 interface, so wallets, explorers, and existing token tooling read balances and submit transfers without any DALP-specific software. The difference is what happens after submission: every transfer runs the identity, compliance, and feature checks this page describes, so a transfer a plain ERC-20 contract would settle can revert here. The wallet must satisfy the asset's recipient identity requirements to receive tokens.
Does the 32-entry ceiling count detached features?
No. The ceiling measures the list installed on the token at one moment, because the contract stores the ordered set in a fixed array of 32 slots. A detach frees the entry it held, and a rotation swaps one entry for its replacement, so historical instances cost no capacity. What grows over an asset's life is the population of on-chain instances, one more with every rotation, while at most one instance of each type is attached.
Do transfer fees apply to a forced transfer or a recovery?
No. A custodian forced transfer and a wallet recovery pass a forced flag into every hook in the pipeline, and the fee features exempt themselves when it is set. The fee rewriter returns the legs unchanged, so the administrative move delivers the exact amount ordered instead of a fee-split remainder. A burn by the Supply management role is an ordinary burn, so a transaction fee with a burn rate takes its fee from it. The flag reaches every feature in all three phases, wherever it sits in the list, so each feature decides its own forced-operation behaviour.
Does rotating or detaching a feature put balances at risk?
The lifecycle write itself moves no units, because balances live in the token contract's own storage, and a feature holds only the state it derives from the hooks it receives. What the write changes is which rules apply. Detaching maturity redemption, Booked movements or hold removes the restriction that feature enforced, from the next operation on, and attaching a feature gives it the token's authority to move units. A badly timed detach also costs derived state, the totals and per-holder values the feature stops tracking during the window.