Design, issue, launch, service, retire: every stage writes to the same indexed record, which is what makes the whole life auditable from one place.
One instrument, one record: the same asset carries its rules, its holders, and its history from the first unit issued to the last redeemed.
Every stage after issuance is a role-gated operation on that asset. The contract checks the role and the asset's rules, and the platform adds its own checks, such as signer verification and approvals, on the operations sent through it.
Coupons and maturity redemption are features attached to the token. A holder of the token's governance role, together with Supply management and Custodian or with the admin role, can attach, detach or replace a feature after issuance, and each change is its own recorded governance operation. Maturing a fixed-income instrument closes issuance and fixes the redemption budget to the supply outstanding at that moment, for as long as the maturity feature stays attached.
Issuance and servicing share an asset record
Asset Lifecycle is the whole working life of a regulated tokenised instrument, from design and issuance through day-to-day servicing to final redemption. On DALP one asset record carries the instrument's rules, its holders and its history through all of it. Issuance is the short part, and the cost and risk sit in the years of servicing that follow.
The cost comes from the number of seams between systems. A typical programme runs issuance in one system, identity screening in a second, custody in a third, trading in a fourth, and settlement and reporting in a fifth. Every seam is a reconciliation, and a reconciliation is where an instrument's ledger state and its legal record drift apart.
The platform records issuance and servicing operations against the same instrument. The eligibility registry that decides who may receive the first minted unit also judges a transfer in year three and a redemption payment at maturity, unless a governance-role holder replaces it, which is a recorded governance operation. The roles that govern who may issue supply also govern who may freeze a holding. The record an auditor pulls in year five is the record the issuance team wrote in year one. The second bond of a given design reuses the first one's template, so it needs no new contract.
The platform owns the mechanics: creating the instrument, enforcing its rules, executing its operations, recording what happened. You keep the legal wrapper, the economic terms, the cash rails outside the platform, the accounting treatment, and the regulatory sign-off. The life is bounded at both ends: an asset is created ready to launch, and no operation reverses maturity.
Running an issued asset day to day
The Console shows each issued asset as one workspace with what the instrument is, who holds it, what it has done, and which servicing steps you may take now. Everything you can do to the asset starts there.
The workspace is built from that asset's own configuration, so it shows only what that asset supports. Tabs appear when they apply: the holder register with its frozen amounts, the workflow history, the compliance configuration, the documents and holder notices, price feeds when the deployment installs them, role assignments, and the cash asset a bond-style instrument pays in. The workspace hides a step the asset does not support. It also hides a step that none of your wallets holds the role for, except “Refresh mark”, which stays greyed out. A step whose role sits on another of your wallets is greyed out and names that wallet. A step blocked by the asset's state, such as a halt, is greyed out and its tooltip names the check that blocks it, so you learn before you submit instead of after a transaction reverts. Amount fields on the mint, burn, transfer, forced transfer, partial freeze and redeem steps show the fiat equivalent at the asset's price, or say that the asset has no price.
The layers an instrument is built from
An Asset Lifecycle rests on three layers that meet at creation. The business class is what an operator browses, the instrument template is what an issuer starts from, and the issued asset is what exists on chain afterwards. A new product shape needs a new template.
The template is where the shape is fixed. It binds the business class, the schema of instrument facts to capture, the runtime behaviour the asset must carry, and the compliance choice that governs it. The issued asset inherits all of that at deployment.
Four design inputs bind into one template, and one deployment produces the token with its own identity, roles, rule engine and registries.
Deployment creates more than a token. The factory deploys the token contract, its own on-chain identity, its own role manager, its own rule engine, and eligibility registries scoped to that token alone. Two instruments in the same organisation therefore carry independent role assignments and independent rule state. Revoking a role on one changes nothing on the other.
A token extension and a token feature are different things. A token extension is a capability the contract itself exposes and the platform discovers from the deployed code: pausable, burnable, capped, custodian control, and so on. A token feature is runtime behaviour built by a feature factory and attached at creation or later by governance: maturity redemption, treasury yield, voting power, fee collection, conversion. Features sit in an ordered list, and the order is policy, because feature hooks run on the token's own operations. Minting and burning pass through them, so do transfers and redemptions, and so does every later update or attachment.
A transaction-fee feature, for one, rewrites a burn into a fee transfer plus a smaller net burn, so the amount a holder asked to destroy and the amount destroyed are different numbers. The fee feature's position relative to maturity redemption or a yield feature makes no difference. Neither of those rewrites the amount, so each reads the balance change the fee feature left behind. A redemption's burn gets fee-diverted regardless of list position, which is why the amount a holder is recorded as redeeming and the amount paid out can differ. Order only changes the outcome between two rewriting features, where the first to run sees the original amount and the second sees whatever the first left behind.
Three kinds of configuration answer three questions. Metadata records instrument facts, such as the issuer or the maturity date. Features change what the token does, such as paying a coupon. Compliance rules decide whether an operation may proceed at all. The platform refuses a feature set whose parts cannot work together, at creation and on every later change it sends. The contract does not run that test itself.
Reads do not scrape the chain. On-chain events become typed platform records, which is why an operator screen, an integration, and an audit export give the same answer about the same instrument.
The integration contract
On the platform's application programming interface (API), an Asset Lifecycle is one address and its subresources. The token address that creation returns is the resource root for everything the instrument ever does: supply changes, transfers, rule changes, feature operations, corporate-action runs, and every read.
Read before you mutate. A feature route applies only when the token reports that feature attached, so the attached-feature list gates the call. Detaching a feature later is its own governance operation. The detached row stays in the history with the block it left at, and you must never read it as live configuration. Event history is not current state either: one operation can emit several events, so read state before you act and events to reconstruct what happened.
Read the asset, submit under one idempotency key, and re-read before reporting the step complete, because acceptance is not completion.
Enforcement happens in two places, and the split decides how you handle errors. The route pre-checks the caller's role, signer verification, the asset's lifecycle state, the request shape, and the indexed balance, and rejects with a stable error code before anything is queued. The contract enforces the rest during execution: supply caps, holder eligibility, collateral cover, and the transfer rules. A request that clears every pre-check can still revert on chain. Read the operation's recorded outcome, its Settlement Verdict, to learn whether it settled or reverted. Acceptance is not completion. Resubmitting under the same idempotency key after a revert does not retry the instruction: the platform refuses it, because the key already names a failed operation. Fix what caused the revert, then send the same business instruction under a new key. The platform answers a submission with an identifier and a status address for that operation, and the status's terminal state is the answer.
Send one idempotency key per business instruction. A mint or a burn sent again under the same key with the same request returns the operation already queued or settled instead of writing twice, and the same key with a different request is refused. If the outcome is uncertain, inspect the original operation and the resulting asset or supply before sending another request. A changed wallet selection or payload is a different instruction and needs a new key.
Two limits catch integrators out. Batch ceilings differ per operation: mint and burn accept up to 100 items per request, while standard and forced transfers accept up to 10,000. And amounts are integers in the token's own precision, set at creation and not always eighteen decimal places, so store each instrument's precision beside its address.
Controls across the whole life, and the evidence they leave
Every act on an instrument, from its creation to its last redemption, needs a role and leaves a record. The controls apply per operation and per asset, and the evidence is one indexed trail on the instrument.
Two independent gates sit in front of every privileged operation. The first is the asset role: minting needs supply management, changing policy needs governance, a freeze or a forced transfer needs the custodian role, and launching or applying an emergency halt needs the emergency role. The second is signer verification at the moment of signing: you confirm the operation through your wallet's configured method, a personal identification number, a one-time code, or whatever your custody provider requires. The contract checks only the role. Signer verification is the platform's check on operations sent through it, so a holder of the role's key who calls the contract directly passes the first gate alone.
Asset roles are scoped to one asset, so an asset role on one instrument confers none over another. A holder of the system manager role is the exception: it can point a token factory at new contract code, which changes the code of every token from that factory at once, without any asset role holder's approval.
An asset is created ready to launch, paused. Its configuration is readable, and no ordinary mint or transfer runs until an emergency-role operator launches it. A real estate token is the exception at creation: its full number of fractions is minted to the named recipient in the creation transaction. The gap before launch is a review window by design, and it runs on no clock: the instrument stays ready to launch until someone with the emergency role launches it. After launch, the same role can apply an emergency halt and later resume token operations. Those controls are reversible, while maturing is not.
A recovery returns a lost wallet's holding to its replacement wallet. Recoveries and forced transfers bypass ordinary compliance checks and the sending wallet's freeze, and they run while the asset is halted. The receiving wallet must still pass the applicable identity check, and a forced transfer refuses a receiving wallet whose address is frozen. Each one emits its own on-chain event carrying the acting sender, the source, the destination, and the amount, so every exception is on the record. The holders of an asset's custodian role include the organisation's operations signer once a trading venue listing has granted it that role, so read the asset's role assignments to list them. Ordinary transfers stay under Transfer-Path Compliance, where the rules are checked inside the transfer and a failure reverts it.
Evidence spans the whole life in one place. Creation, role grants and revocations, identity claims, supply changes, transfers, feature operations, corporate-action runs, and redemptions are indexed against the same asset with their transaction references. An auditor can reconstruct the on-chain operations from those records and reconcile them with external evidence.
Metadata entries and a collateral claim recorded against the asset are inputs the contract checks. They prove nothing outside it. A collateral claim states an amount and an expiry that the minting check evaluates against the configured ratio. The bank statement, the custodian report, and the legal title behind it stay in your own evidence file.
Frequently asked questions
Which instrument types can the platform issue?
The platform issues any instrument that its templates, features and compliance modules support, so start from the template that fits. Behaviour is attached at configuration time instead of compiled per product. The platform ships 36 templates across seven business classes: fixed income, equity, funds, cash, real assets, digital assets, and structured products. Fixed-income templates include corporate and sovereign bonds, government securities, treasury bills, commercial paper, syndicated loans, and sukuk ijara and murabaha. Equity templates include SAFEs, warrants, convertible target equity, controlling and economic class shares, and a share-class mirror for a class whose register a fund administrator keeps. Fund templates include funds, money market funds, and ETFs. Other templates cover custody receipts, autocallable and principal-protected notes, carbon credits, spot commodities, tokenised virtual assets, and tokenised art. A named product such as a covered bond is a template. Instrument Templates lists them all.
What happens to an instrument that never matures, such as an equity?
It has no end-of-life step. Maturity and redemption are a feature attached at creation, and an instrument without that feature keeps operating indefinitely, with no scheduled close. Supply can still fall through burns, and a capital decrease or a buyback runs as an announced batch burn against per-holder allocations fixed in the action's plan, but no one-way state ever closes issuance.
Can we change an instrument's rules after it is live?
Yes. Compliance rules change one binding at a time after issuance, and each is a role-gated governance operation on that asset with its own record. The same applies to the instrument's metadata, its eligibility registry, and its ordered feature list. On chain, the governance role can also replace the token's whole compliance contract or its identity registry in one call, and together with Supply management and Custodian, or with the admin role, its full feature list. Treat that role as the instrument's rule-making authority. Some things are deliberately locked instead: template fields marked immutable when the template was published, and the maturity date on most fixed-income templates. A locked field is a design decision recorded at publication, so if a product needs different behaviour the answer is a new template instead of an edit to the live one.
Who holds the assets through all of this?
The holders do, in their own wallets. A wallet must carry a verified identity in the instrument's eligibility registry before it can receive any units. Where its signing key lives changes who can sign. The key can sit in your hardware security module, with a qualified custody provider, or in an encrypted store the platform manages, and with the key in that store the platform signs the holder's transactions. A holder of the asset's custodian role can still move a holding without the holder's signature, and while an order works on a Trading Venue its units sit in the venue's escrow.
How does a dividend or a split run?
The industry name for these is “corporate actions”, and each is a named lifecycle event on a security: a cash dividend, a bond coupon, a stock split, a rights issue, a spin-off, or a decrease of capital. The platform translates the legal event into its economic effect and runs it with the same primitives everything else uses. A record-date snapshot fixes who held what. Batch mints, batch burns, or a yield declaration then apply the terms. No second engine sits behind them, and one record stores the announced terms, the snapshot, the batch progress, and the transaction references.