Composable Token

An issuer brings a new instrument to market by configuring one contract, not by commissioning new contract code. The same model becomes a bond, a fund, a sukuk, or another shape the issuer defines.

Feature order is policy, not presentation. 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 codeCopy Anchor Link

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 rather than rebuilt. Asset Lifecycle makes the same point about the platform as a whole: a new instrument shape is usually a configuration rather than a build. 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. Available features, metadata fields, and compliance modules bound the instrument designs a deployment can issue.

The Instrument TemplateAn Instrument Template lets an issuer configure a new instrument from an approved shape, instead of re-deciding what it records, does, and permits each time.Read the concept, the off-chain product definition that names the required features and compliance choice, records the product shape, and the features hold the behaviour. They are concrete: 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 this model as one configured contract per instrument on an EVM-compatible network.

That keeps the product vocabulary honest. 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 of them differ in their configuration rather than in the contract model behind them.

The business boundary is also clear. 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 worksCopy Anchor Link

A Composable Token is one shared regulated asset contract initialized with the regulated token core, identity and role controls, metadata, pause and custody behaviour, and a per-token compliance contract. The asset factory 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 rather than 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 then runs through that list in three phases, and only the middle one is a pipeline. First every feature is asked whether the operation may proceed, and every one of them is asked about the operation exactly as the caller requested it. Second, the features that rewrite run in list order, and this is where a result is handed on. Each rewriter receives the legs, the individual balance movements the operation settles into, as the previous rewriter produced them, together with the original operation, and may split, resize, or add to them. Each resulting leg is then executed through the token's full pipeline, which asks the first-phase question again for that leg. Last, every feature is notified once, and the notification reports both the original operation and the legs that actually 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.

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 contract's own guidance gives a canonical order: 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 rather than one stage of it. An analytics feature such as a historical-balance or voting-power snapshot cannot record an amount no holder received either, because it is told the executed legs wherever it sits in the list, its position does not change that notification.

An Instrument Template defines the composition off chain, before anything is deployed. A template binds a business grouping, instrument-fact schema, deployable base, required feature identifiers, and a compliance template. The platform checks feature dependencies and incompatible pairs before it publishes or uses that template, and the factory then resolves each feature type to its registered factory and creates the on-chain instances.

System addons sit at a different level of the same deployment. They are shared components registered for capabilities such as settlement or feature factories, and their registry controls which implementations a deployment can use. An addon can supply the factory that creates a feature, while each resulting Token Feature belongs to one token. They are not two options to choose between, and the boundary keeps shared deployment infrastructure separate from per-instrument behaviour.

Issuing from the template catalogCopy Anchor Link

Issuing a Composable Token never starts with a contract request. It 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 catalog is a set of reusable starting shapes. System templates cover common products, while organization templates capture the product designs your own firm has approved. A platform-supplied template stays a shared baseline: it cannot be deleted, edited, or published. A system template answers DALP-0160 for a delete attempt, DALP-0161 for an edit, and DALP-0162 for a publish attempt. What you can change is whether your organization sees it in its own lists. Copy it into an organization template when you need it to differ.

A template is checked before it can be published, and two of those checks are worth understanding. A required feature whose dependency is absent answers DALP-0477, 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 would both account for the same transfer answers DALP-0532; keep one of the pair. 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 assetCopy Anchor Link

Servicing a live Composable Token means driving its feature lifecycle, because the features are where its behaviour lives. Attached features are real 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; there is no position parameter on the request. A rotated feature's replacement instance also joins the end rather than inheriting the old position, so rotating a rewriter that ran ahead of another rewriter changes execution order as well as configuration. No write repositions an existing entry: when position matters, attach or rotate the features you need in the sequence you want them to settle in, because the list only ever grows from the tail.

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.

Detaching costs more than it looks. 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. Reattaching repairs less than the word suggests: totals the feature can recompute from live on-chain state are right again at once, while per-holder derived values catch up only when that holder's balance next moves. Plan the window across a quiet period for the affected feature rather than treating a detach as a toggle. A conversion feature with a pending interest backlog, or a closed conversion window, blocks both a detach and a rotate with a 409; the response names which. A closed window is the same DALP-4057 the on-chain conversion path answers. For the backlog, wait for the accepted settlement batch, inspect the original operation, and check the route's replay contract before sending another request. For the closed window, check its end time and contact the issuer if it should be extended.

Four configuration facts decide what a composable token actually does, and they differ in what it takes to change them.

The integration contractCopy Anchor Link

Developers integrate with Composable Tokens through the generic asset and feature surfaces, not through 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. Two of those parts decide more than they look: the name enters the deterministic deployment address, and the list fixes the execution order the transfer pipeline runs.

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, not on the name.

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.

Two reads are easy to confuse. Listing a token's features through the API returns them sorted alphabetically by name, which is a directory, not an execution order. 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 rather than synchronous, 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 as that specific conflict, not a generic error, and the fix is to rotate the existing instance rather than retry 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 evidenceCopy Anchor Link

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 installed rules for the sender, receiver, amount, and token. A failed check reverts the transfer and leaves balances unchanged.

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.

Composition does not weaken role control. Supply, governance, custody, emergency, and feature operations remain gated by the asset's access manager. A Token Feature can add a regulated behaviour, but it does not gain unrestricted authority over the token.

The evidence boundary follows the same split as the architecture, and an auditor reads three sources, not one.

The chain and the template are both queryable through the platform's own reads. The issuer's records are not, and no DALP implementation is required to change that.

Frequently asked questionsCopy Anchor Link