Denomination Asset
A Denomination Asset lets a payout-bearing Token Feature, such as Maturity Redemption or a yield schedule, pay holders in a real asset it never custodies.
Redemption burns the bond-style token outright and separately pays the denomination asset from the treasury at face value; 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, so what a holder receives is a real asset the feature itself never touches.
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: the address can still be funded, never repointed.
Why a payout needs an asset the feature never touches
A bond-style instrument's own 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 platform could have let the feature pay straight from its own balance instead of routing every payout through a treasury. It does not, for a compliance reason. An allowlist or a sanctions screen on the denomination asset checks a transfer's two named parties, the sender and the receiver, against a registered identity. A treasury and a holder's wallet both have one. A feature computing a payout mid-transaction does not: it has no identity of its own registered anywhere. Paying straight from feature logic would make the feature the sender, and the compliance check has no registered sender to approve, so the transfer reverts. Routing the payout through a separately configured treasury gives the check a sender it recognizes, which is also why a compliance review of a redemption traces exactly two parties, never a third the platform introduced.
That design answers a broader question for an issuer choosing the platform at all. Asset Lifecycle names the real cost of a tokenized instrument as seam count: a typical programme runs issuance, custody, and settlement in separate systems. Every gap between those systems is a reconciliation where a ledger's state and its legal record can drift apart. A denomination asset kept in a treasury the platform already tracks, checked by the compliance rules that already govern every transfer of that asset, adds no such gap. Choosing a separate payout asset for a bond or a yield-bearing instrument names which of the platform's own tracked assets settles the obligation, rather than adding a second custodian to reconcile against later. The same audit trail that covers issuance covers the payout too.
Choosing the denomination asset at configuration
An issuer picks the denomination asset once, at instrument configuration, before the bond-style token exists. The Asset Designer's denomination 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 stablecoinA Stablecoin lets an issuer declare a currency peg and enforce a collateral check against a signed claim, on the same record as the rest of the token's life.Read the concept means the bond-style token inherits 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. Either way, the choice is made once, up front, not adjusted after holders already hold the instrument.
Fund the treasury before maturity, or redemptions stay closed
Once configured, the denomination asset is something an operator funds and watches, not something set once and forgotten. The treasury needs enough of it funded before maturity: the platform blocks the normal maturity call outright if the treasury balance falls short of face value times the token's current supply.
Funding the balance is not enough on the approval-pull path. The maturity gate checks only the treasury's balance of the denomination asset, never its allowance to the feature, so a treasury that holds face value times supply 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. The treasury allowance endpoint sets that allowance before maturity, and the same call still works after maturity, which is why it is the fix once redemptions start failing this way.
A distressed treasury has one exception: an emergency early maturity trades away that guarantee to open redemptions sooner, for a shortfall already underway rather than funding not yet finished. Either path pays out only on tokens actually destroyed, never on tokens merely requested.
One resolution per feature, one of two payout paths
Each payout-bearing Token FeatureA Composable Token lets an issuer bring a new regulated instrument to market by configuring facts, features, and rules, not new contract code.Read the concept (the unit of behavior a Composable Token installs, such as Maturity Redemption or a yield schedule) resolves its own denomination asset independently. Maturity Redemption and every yield feature each expose their own view of it. The denomination asset is not a single token-wide property, and Holdings, the token's own list of the assets it holds balances in, is not where you resolve it. The token surfaces there only when it happens to also hold a balance of its own denomination asset, flagged as the Redemption or Yield row. A token with two payout-bearing features installed can have two different denomination assets active at once, one per feature.
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 rather than recomputed on every payout. A treasury that gained or lost vault support since configuration is therefore picked up at maturity, not left stale.
The payout mode determines the treasury's approval or contract requirements.
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 implementing the payout interface, and the feature calls its payout 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 to write and keep correct, not a form to fill in.
A Maturity Redemption feature rejects a denomination asset that equals its own token when the feature is configured. 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. The check exists specifically to keep those two movements from colliding.
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.
The feature also rejects a zero denomination address. Both checks apply when the feature is created or replaced.
A live redemption's actual payout can come in lower than the preview alone implies. A co-installed fee feature can divert part of the requested burn, so only the net amount destroyed earns denomination. The aggregate denomination budget, face value times supply at maturity, can also cap the payout further once other holders have already redeemed against the same treasury. Read the emitted Redeemed event's payout amount as the actual figure, not a value independently recomputed from the request.
Custody stays with the treasury, never the feature
A denomination asset's defining property, for a compliance review, is that the feature paying it out never holds it. Every payout-bearing feature draws from a separately configured treasury instead of custodying funds itself, so the identity check on the denomination asset lands on the treasury and the holder, the only two parties who ever touch the funds.
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 governance role, 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 emergency role, before the maturity date. It skips that check by design, so redemptions can open on a treasury already short, paying out first-come, first-served against whatever remains.
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 fails cleanly instead of paying from a balance that is no longer there.
Treat redemptions opened through the emergency path as a possible shortfall event to review, not a routine maturity.
Frequently asked questions
Does the denomination asset have to be a stablecoin?
No. Any deployed token that behaves as an ERC-20 can serve. Token creation enforces metadata instead: the platform will not create a token whose denomination asset does not expose a readable ERC-20 symbol and decimals. That check runs against every feature with a denomination asset field, not only the payout-bearing ones, so a Conversion template's denomination address is checked too even though Conversion itself pays out nothing. It lands before anything deploys, so a wrong address fails the creation call rather than 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. 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. Three moves remain, the ones maturity exists for: a holder can burn tokens through redemption, a custodian can still execute forced transfers, and a co-installed feature can still move tokens it triggers itself. A holder who wants the denomination asset has exactly one path, redeeming, rather than selling the matured token on.
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.