Asset Lifecycle

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, and the asset's own contract decides whether it proceeds.

What an instrument can do after issuance is decided at issuance: coupons and maturity redemption are behaviour attached at creation, never switches flipped later. Maturing a fixed-income instrument then closes issuance permanently and fixes the redemption budget to the supply outstanding at that moment.

Issuance and servicing share an asset recordCopy Anchor Link

Asset Lifecycle is the whole working life of a regulated tokenized instrument, from design and issuance through day-to-day servicing to final redemption, governed end to end on one platform. Issuance is the short part. Cost and risk sit in the years of servicing that follow.

The problem is seam count, not tokenization. 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 judges a transfer in year three and a redemption payment at maturity. 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. 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.

The boundary matters. 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 paused, and a matured instrument cannot be returned to issuance.

Running an issued asset day to dayCopy Anchor Link

Day to day, an Asset Lifecycle is one workspace for each issued asset. It shows what the instrument is, who holds it, what it has done, and which servicing steps you may take right now. Everything you can do to the asset starts there, and everything you cannot is visibly closed rather than missing.

The workspace is built from that asset's own configuration, so it shows only what that asset supports. Tabs appear when they apply: holders and their frozen amounts, the workflow history, the compliance configuration, documents, price feeds when the deployment installs them, role assignments, and the cash asset a bond-style instrument pays in. A step the asset does not support is hidden. A step your role does not allow is disabled, and its tooltip names the check that blocks it, so you learn before you submit rather than after a transaction reverts.

The layers an instrument is built fromCopy Anchor Link

An Asset Lifecycle rests on three layers that meet at creation and must not be conflated. 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, not a new contract.

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.

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.

Two terms that look interchangeable are not. 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: maturity redemption, treasury yield, voting power, fee collection, conversion. Features sit in an ordered list, and the order is policy rather than presentation, 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 actually destroyed are different numbers. Where the fee feature sits relative to maturity redemption or a yield feature makes no difference: neither of those rewrites the amount itself, so each still reads whatever 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 actually 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 different questions, and conflating them is the common modelling mistake. 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 tests the combination before it deploys anything: a feature set whose parts cannot work together is refused at creation, so no instrument goes live carrying a contradiction for a later operator to find.

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

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 rather than documenting it. 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.

Enforcement happens in two places, and the split decides how you handle errors. The route pre-checks the caller's role, signer verification, the paused 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, so read the operation's recorded outcome as a Settlement VerdictA Settlement Verdict lets you report success only when an operation actually happened, not from acceptance alone, across four recorded end states.Read the concept, the recorded end state that says whether the operation settled or reverted, instead of treating acceptance as completion. Resubmitting under the same idempotency key after a revert does not retry the instruction: it returns that recorded failure again. 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; you watch that status until it reaches a terminal state, and the terminal state is the answer.

Send one idempotency key per business instruction. The transaction queue can recognize the same key and write after admission, but token creation and minting are not declared safe to replay at the API route. 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 leaveCopy Anchor Link

For a control function, an Asset Lifecycle is the question of whether every act on an instrument, from its creation to its last redemption, was authorized and left a record. The controls apply per operation and per asset, and the evidence is one indexed trail on the instrument itself.

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 pausing 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. Holding the role is not enough on its own. Roles are scoped to one asset, so authority over one instrument confers none over another.

An asset is created paused. It exists, its configuration is readable, and no unit can be issued or moved until an emergency-role operator unpauses it. That gap is a review window by design, not an accident of the deployment, and it runs on no clock: the instrument stays paused until someone with the emergency role unpauses it. Pausing and unpausing are reversible; maturing is not.

Privileged recovery and forced-transfer operations bypass ordinary compliance and freeze checks. The receiving wallet must still pass the applicable identity check. Each one emits its own on-chain event carrying the acting sender, the source, the destination, and the amount, so the exception lands on the record by construction rather than by policy. 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 platform's operations from those records and reconcile them with external evidence.

One limit deserves stating in writing. Metadata entries and a collateral claim recorded against the asset are inputs the contract checks, not proof of anything 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 questionsCopy Anchor Link