Redemption burns the bond-style token, and separately the treasury pays the denomination asset at face value, so the two assets never trade places.
A payout-bearing Token Feature never pays a holder from its own balance. Every payout draws from a separately configured treasury, and nothing locks that treasury's balance or allowance, so holders rely on the treasury's owner to keep it funded.
What redemption burns and what it pays are different assets: the surrendered token is destroyed, the denomination asset is delivered.
Maturity freezes the treasury binding of that feature instance. The address can still be funded but cannot be repointed.
Why a payout needs an asset the feature never touches
A denomination asset is the token that a payout-bearing token feature, such as maturity redemption or a yield schedule, pays holders in. It is always a different token from the one being held, and the feature draws it from a treasury the issuer funds.
A bond-style instrument, one that matures and is redeemed at a face value, has its own token, and that token is what a holder trades and holds. It is not money, and Asset Lifecycle names what happens to it at the end of its life: the instrument matures, holders redeem, and their positions burn. Redemption destroys the very token being redeemed, so that token cannot also be what pays the holder. A yield feature meets the same problem earlier in the instrument's life: a coupon or a dividend is value paid on top of a holding, not more of the holding itself. Something has to represent that value in a form redemption or a yield payment never touches. The denomination asset is that something: a currency-like token a payout-bearing Token Feature pays out per unit redeemed or per unit of yield earned.
The feature pays through a treasury and holds no balance of its own. The issuer funds one named treasury for each feature, and every payout is an ordinary transfer from that treasury to the holder. Any rule on the denomination asset applies to that transfer as it would to any other.
Choosing the denomination asset at configuration
An issuer picks the denomination asset once, at instrument configuration, before the bond-style token exists. The Console's “Denomination asset” field rejects an address with no contract deployed at it on the selected network, so a stablecoin or other external token has to exist first. Reusing an established stablecoin means the bond-style token depends on that stablecoin's own issuer and decimals, neither of which it controls. Issuing a purpose-built denomination asset instead avoids that dependency, at the cost of operating its own supply and compliance gating from day one. Reuse an established stablecoin when the instrument can live with a token it does not control. Issue a purpose-built one when the instrument's own compliance rules or liquidity needs cannot bend to somebody else's token. After the feature exists, only its treasury can change, and only until maturity.
One resolution per feature, one of two payout paths
Each payout-bearing Token Feature resolves its own denomination asset. A Token Feature is a unit of behaviour a Composable Token installs, such as Maturity Redemption or a yield schedule. The denomination asset is a property of each feature. The token's Holdings list shows it only when the token also holds a balance of it, flagged as the Redemption or Yield row. A token with two payout-bearing features installed can have two different denomination assets active at once, each with its own treasury to fund.
The feature never custodies the denomination asset it pays out. It always draws from a separately configured treasury, through one of two Treasury Payout Modes: an approval-based pull, or a delegated payout call into a vault contract that implements its own logic and interface. The platform probes automatically for which mode applies, by checking whether the treasury supports that vault interface, and nothing about the feature's own code changes between the two paths. That probe runs when the treasury is configured and again at the maturity call, and the resolved mode is cached in between instead of recomputed on every payout. A treasury that gained or lost vault support since configuration is therefore picked up at maturity.
Approval pull
The treasury is an externally owned wallet with a standing approval to the feature, or a contract that grants that approval itself. Either way the feature pulls the payout with that allowance. An externally owned treasury approves through the platform's own control. That control signs with the acting wallet, so a smart-wallet treasury the platform operates can use it too. Any other contract treasury calls approve itself instead, through whatever admin or governance flow it exposes.
Vault call
The treasury is a contract that implements the ITreasuryPayer interface, and the feature calls its payout(token, to, amount) function instead of pulling funds itself. Choose it when the payout needs logic a plain balance and allowance cannot express: a multi-signature release, its own internal accounting, or a rate limit on how fast it pays out. That logic is a contract you write and keep correct.
A Maturity Redemption feature rejects a denomination asset that equals its own token when the feature is configured. It also rejects a zero denomination address. Paying out the same token the feature is burning would break the redemption invariant: a redeemer's balance would grow at the face-value rate while total supply shrinks from the same burn.
Fund the treasury before maturity, or redemptions stay closed
The treasury needs enough of the denomination asset funded before maturity. The platform blocks the normal maturity call if the treasury balance falls short of the whole supply at face value: the token's supply counted in whole tokens, times the face value.
Funding the balance is not enough on the approval-pull path, where the treasury lets the feature pull funds up to an allowance. The maturity gate checks only the treasury's balance of the denomination asset, never its allowance to the feature, so a treasury that holds the full amount but never approved the feature passes that gate cleanly. Every redemption then reverts with DALP-9481, because payout pulls funds through that same allowance, and a standard token approval overwrites rather than adds to what is already granted, so a top-up must state the new total allowance. Approve at least the amount needed to redeem the whole supply. Only the treasury's own wallet can approve, and the treasury allowance endpoint sets the allowance before or after maturity, which makes it the fix for an externally owned or platform-operated treasury once redemptions start failing this way.
An emergency early maturity skips the solvency check, so redemptions open on a treasury that may already be short. Either path pays out only on tokens destroyed, and not on the amount a holder requested.
Read the denomination asset on the feature, not the token
An integrator reads the denomination asset per feature, not per token. The feature configuration endpoint returns each attached feature's own denominationAsset, alongside its faceValue and treasury, since there is no token-level or Holdings-level accessor for any of them. Preview a Maturity Redemption payout before submitting one with the feature contract's calculatePayout(), which returns the redeemed token amount times the face value, divided by ten to the power of the token's decimals.
A live redemption's actual payout can come in lower than the preview. A co-installed fee feature can divert part of the requested burn, so only the net amount destroyed earns denomination. Read the emitted Redeemed event's payout amount as the actual figure, instead of a value recomputed from the request.
The feature contract also caps total payouts at face value times the supply at maturity. Each payout is for the net amount burned, so the cap acts as a backstop. When a payout would pass the cap, the feature pays only what is left of the budget and still burns the tokens redeemed.
Custody stays with the treasury
For a compliance review, the feature that pays out the denomination asset never holds it. Every payout-bearing feature draws from a separately configured treasury, so the funds move only from the treasury to the holder. The holder starts that movement, or, for a delegated redemption, an account with the token's Custodian role does.
Which of the two maturity paths opened redemptions is itself a compliance-relevant fact, because the two paths give a reviewer different assurances to weigh:
Normal maturity
Callable by the token's governance role, which administers its features, from the maturity date onward, once the treasury has passed the solvency check that gates a normal maturity call.
Emergency early maturity
Callable by the token's emergency role, which can also pause the token, before the maturity date. It skips that check by design, so redemptions can open on a treasury already short. Redemptions are served first-come, first-served against the treasury balance, and one the balance cannot cover reverts with the holder's tokens unburned.
The normal-path solvency check runs once, at the maturity call: the treasury is an external address, and nothing stops it from being drained after maturity passes. Every redemption, on both paths, checks the treasury's live balance for its own payout and blocks that payout when the balance falls short. A later shortfall reverts the whole redemption, so the holder's tokens are not burned and nothing is paid from a balance that is no longer there. Until every holder has redeemed, keep the treasury funded for the supply still outstanding and keep its allowance in place: only the amount above that is surplus.
The payout is a transfer of the denomination asset, so that asset's own rules apply to it. Before calling mature, confirm that the treasury and every holder's wallet are accepted by any allow list on the denomination asset. A payout the asset rejects reverts the redemption with the holder's tokens unburned, and the matured token cannot be sold on instead. After maturity, funding the treasury and, on the approval path, setting its allowance still work. The platform cannot override another token's rules, so a reused stablecoin's own issuer has to admit a rejected wallet.
Review redemptions opened through the emergency path as a possible shortfall event.
Frequently asked questions
Does the denomination asset have to be a stablecoin?
No. Any deployed ERC-20 can serve, and dividend yield and interest yield also refuse a registered fee-on-transfer or rebasing token. Token creation enforces metadata: the platform does not create a token whose denomination asset does not expose a readable ERC-20 symbol and decimals. The check lands before anything deploys, so a wrong address fails the creation call instead of the first payout. Stablecoins are the usual choice because holders expect a currency-like payout.
Can the treasury address change after it is configured?
Before maturity, yes. The governance role can repoint the treasury to a new address, and every repointing re-detects which payout path applies. Because the platform caches that detection between checks, repointing the same address again is also how you force a fresh probe after a treasury contract changes what it supports. Maturity removes that option: it freezes the treasury binding, so a vault that later loses its payout interface, or a plain treasury that turns into one, is stuck on whatever mode was last resolved, with no later way to repoint it. The token's governance role can still replace the matured feature with a new instance that has its own treasury. Confirm the treasury still supports the mode you expect before calling mature, because that call is the last chance to fix it.
Can a holder still transfer a bond-style token after maturity?
No. Maturity freezes the token itself: regular transfers are blocked, and so are new mints, so the supply that redemption prices against stays fixed. Four moves remain. A holder can redeem, an account with the Custodian role can redeem on a holder's behalf, a custodian can still execute forced transfers, and a co-installed feature can still move tokens it triggers itself. The block lasts while maturity redemption stays attached. If the governance role detaches the feature, transfers and mints work again.
What happens to denomination asset left in the treasury after redemptions?
It stays where it is. The maturity feature moves treasury funds only when a redemption pays out, and only for the exact amount that redemption owes, so nothing sweeps the account when redemptions wind down. A treasury funded above face value times supply keeps the surplus under its owner's control. The platform also caps the total paid across all redeemers at face value times the supply at maturity, so overfunding never inflates what holders collectively receive.
What unit is the face value stated in?
Face value is an amount of the denomination asset, stated in that asset's smallest unit, per whole token, so the gross payout for one whole redeemed token is the face value. A zero face value is refused at construction, so a deployed feature always has a real payout rate.