Maturity Redemption
How DALP handles bond maturity redemption: operator maturity actions, treasury funding and allowance readiness, indexed solvency signals, and holder redemption after maturity.
Maturity Redemption gives a bond-style token a controlled end state. Before maturity, holders can transfer tokens normally. At maturity, you trigger the transition through an authorised operator call. After that, ordinary transfers stop and holders redeem tokens for the denomination asset at the configured face value.
Use this feature when you need maturity to be explicit: the date alone does not end the instrument, and holders can only redeem once an authorised operator call has moved the token into its redemption state. DALP enforces the token-state transition and records maturity and redemption events. As the issuer, you still run the surrounding processes: cash management, treasury funding, investor notices, accounting, and legal-register updates. For the fixed-income templates that attach maturity-redemption to a new asset, see the fixed-income section of the system templates catalog.
Lifecycle model
Maturity Redemption separates three steps: the bond date, the operator call, and the holder payout. The date defines when scheduled maturity is allowed. The operator call records that the bond has matured. The payout burns redeemed tokens and pays denomination asset from your configured treasury.
| Phase | What happens | User impact |
|---|---|---|
| Pre-maturity | The token is active. Transfers follow the normal feature and compliance stack. | Holders can transfer tokens when the rest of the asset configuration allows it. |
| Maturity trigger | An authorised operator calls mature() after the scheduled date, or an emergency operator calls matureEarly() before it. | The token enters the redemption state. This transition is irreversible. |
| Post-maturity | The feature blocks ordinary transfers and enables holder redemption. | Holders call the redeem route to burn tokens and receive the denomination asset from treasury. |
The bond does not mature automatically when the date arrives. Your off-chain operator process or an authorised user must call mature() to make the change. Until that call lands, normal transfer behaviour continues for the token.
Interface capabilities
The table below lists each operation, who can call it, and what it does.
| Capability | Who can call | Inputs | Effect | Emits | Notes |
|---|---|---|---|---|---|
| Trigger maturity | GOVERNANCE_ROLE | None | Transitions token to the matured state | Matured | Only after the configured maturity date |
| Trigger early maturity | EMERGENCY_ROLE | None | Forces the matured state before the scheduled date | MaturedEarly | Emergency path only |
| Redeem tokens | Token holder with redeem permission | Amount to redeem | Burns tokens and transfers denomination asset from treasury | Redeemed | Only available after maturity |
| Approve treasury allowance | Treasury wallet | Allowance amount in base units | Lets the feature spend denomination asset from a wallet treasury | ERC-20 Approval | Only the treasury wallet can approve |
| Set treasury address | GOVERNANCE_ROLE | Treasury address | Redirects future redemption payouts | TreasuryUpdated | Fund and verify the new treasury before holders redeem |
| Block transfers after maturity | Automatic transfer hook | Transfer attempt | Reverts non-redemption transfers | None, because the transaction reverts | Burns, mints, forced transfers, and feature-invoked updates can still pass through the hook |
Operator responsibilities
As the issuer or operator, prepare four things before holders can redeem reliably:
- Move the token into the matured state with
mature()after the configured maturity date, or withmatureEarly()through the emergency path. - Ensure the configured treasury holds enough denomination asset to cover expected redemptions.
- If the treasury is a wallet, that wallet must approve the maturity-redemption feature to spend the denomination asset.
- Check the bond-status response for indexed balance, allowance coverage, and treasury classification before announcing that redemption is available.
A wallet treasury and a contract treasury behave differently. A wallet treasury pays through ERC-20 transferFrom, so the feature needs allowance from that wallet. A contract treasury uses the treasury contract's own payout controls, so the wallet-approval route does not apply. The Console hides the approval button unless the connected wallet is the configured wallet treasury and the bond-status response shows an allowance gap for it.
Only the configured treasury wallet can submit the allowance approval. Other token roles, including custodians and admins, cannot approve on behalf of that wallet because ERC-20 approval belongs to the account that owns the funds.
API routes
| Operation | Route | Who signs | Purpose |
|---|---|---|---|
| Trigger scheduled maturity | POST /api/v2/tokens/{tokenAddress}/maturity-redemption/maturations | Authorised governance operator | Move the token into post-maturity state after the configured maturity date. |
| Trigger early maturity | POST /api/v2/tokens/{tokenAddress}/maturity-redemption/early-maturations | Authorised emergency operator | Move the token into post-maturity state before the configured maturity date. Use only under the programme's incident procedure. |
| Set treasury | PATCH /api/v2/tokens/{tokenAddress}/maturity-redemption/treasury | Authorised governance operator | Change the treasury address used for future redemption payouts. |
| Top up treasury | POST /api/v2/tokens/{tokenAddress}/maturity-redemption/top-ups | Any funding wallet | Transfer denomination asset from the caller's wallet into the configured treasury. |
| Approve wallet-treasury allowance | POST /api/v2/tokens/{tokenAddress}/maturity-redemption/treasury-allowance | Treasury wallet | Approve the feature to pull denomination asset from a wallet treasury. |
| Redeem tokens | POST /api/v2/tokens/{tokenAddress}/maturity-redemption/redemptions | Token holder | Burn the holder's tokens and pay denomination asset at face value. |
Submit amounts in base units of the relevant token. For example, the redemption amount is the token amount to burn, and your allowance or top-up amount is the denomination-asset amount in its smallest unit.
Treasury readiness signals
Use GET /api/v2/tokens/{tokenAddress}/stats/bond-status before and after treasury operations. The response separates treasury balance, the ERC-20 allowance from treasury to the feature, treasury classification, feature address, and indexer status. Check both balance and allowance fields: a funded treasury can still fail wallet-treasury redemptions when approval is missing, and a valid approval does not guarantee funds. Each response field is explained below.
| Field | Meaning | Operator use |
|---|---|---|
denominationAssetBalanceAvailable | Denomination asset balance held by the configured treasury | Confirms whether the treasury has funds available for redemption |
denominationAssetBalanceRequired | Denomination asset required to redeem the outstanding token supply at face value | Sets the target balance for full coverage |
coveredPercentage | Balance coverage percentage | Shows balance readiness only, not allowance readiness |
denominationAssetTreasuryAllowance | ERC-20 allowance from treasury to the maturity-redemption feature | Shows whether a wallet treasury has authorised the feature to pull funds |
allowanceCoveredPercentage | Allowance coverage percentage | Shows whether allowance covers the required redemption volume |
treasuryIsContract | true for a contract treasury, false for a wallet treasury, null while classification is pending | Determines whether wallet allowance applies |
solvencyKnown | Whether the indexer has computed the bond-status solvency row | Distinguishes real zero balances from a temporary unknown state |
treasuryAddress | Current maturity-redemption treasury | Identifies the payout source |
featureAddress | Maturity-redemption feature contract | Identifies the spender for wallet allowance |
These values are indexer-backed. A confirmed top-up, treasury change, allowance approval, or redemption can briefly show a stale value while the indexer catches up. Treat solvencyKnown: false as "coverage is not known yet", not as an empty treasury. Treat treasuryIsContract: null as a wait-and-retry state. In both cases, avoid sending approval or redeem requests that the API already knows may fail based on current state.
Holder redemption UX
A holder can see the redeem button when your connected wallet has a redeemable token balance and the wallet has the redeem permission. Before maturity, the button remains visible but disabled with a maturity-specific reason. After maturity, it can still be disabled by treasury or token state:
| Condition | Holder-facing result |
|---|---|
| Token is not mature | Redemption stays unavailable until the maturity transition has been triggered. |
solvencyKnown is false | The UI shows that treasury verification is still in progress. |
| Wallet treasury allowance is zero | The UI explains that treasury allowance is insufficient. |
| Treasury balance is unavailable or empty | The UI explains that treasury funds are missing. |
| Token is paused | Redemption is blocked by the paused token state. |
The redemption request is POST /api/v2/tokens/{tokenAddress}/maturity-redemption/redemptions. The request supplies the token amount to redeem. The API resolves the feature address, checks wallet-treasury allowance when the treasury is a wallet, queues the redemption transaction, and returns the standard queued mutation response.
If a wallet treasury has only partial allowance, the UI can still open the redemption flow. The API calculates the payout for the requested amount and rejects the request when the allowance is below that payout. This keeps partial coverage honest: a small redemption may fit while a larger one does not.
As a first-time holder, the sequence is: wait until the issuer has triggered maturity, confirm the redeem route is available for your connected wallet, enter the token amount to redeem, and submit the queued transaction. The payout depends on the configured face value and the denomination asset, not on market price.
Failure modes and edge cases
| Failure mode | What happens | Recovery path |
|---|---|---|
| Treasury balance is too low | Redemptions revert when the treasury cannot pay the requested payout. Early redeemers can be paid while later redeemers fail if funds run out. | Top up the treasury and wait for bond-status values to update. |
| Wallet treasury allowance is too low | The API rejects wallet-treasury redemptions when allowance is below the calculated payout. | The treasury wallet approves enough allowance for the expected redemption volume. |
| Treasury classification is pending | The approve and redeem routes reject the request until the indexer classifies the treasury. | Wait for indexing to catch up and retry. |
mature() is not called at the scheduled date | The token remains in pre-maturity state and ordinary transfer behaviour continues. | Trigger maturity through the authorised operator process. |
mature() is called too early | The on-chain call reverts. | Use matureEarly() only through the emergency role and process. |
| Face value is wrong | Redemption economics use the configured face value. | Redeploy or provide an external remediation path. The feature does not change face value after deployment. |
| Treasury address changes | Redemption transactions use the treasury configured when the transaction executes, including transactions that were queued before the change. | Pause redemption operations during treasury rotation, then verify funding, allowance, and classification before holders redeem. |
Controls and guardrails
| Role | Call | Guardrail |
|---|---|---|
GOVERNANCE_ROLE | setTreasury() | Use multi-signature approval or equivalent governance, then verify funding and classification before holders redeem. |
| Treasury wallet | Approve denomination-asset allowance for the feature | Approve enough allowance for the expected redemption volume. Use base units and only sign from the configured treasury wallet. |
GOVERNANCE_ROLE | mature() | Trigger only when the configured maturity date has arrived. The chain rejects an early scheduled maturity call. |
EMERGENCY_ROLE | matureEarly() | Reserve for documented emergency procedures before the scheduled date. Once the scheduled date has arrived, use mature(). |
Auditability and operational signals
Maturity Redemption emits events when the token matures, matures early, redeems, or changes treasury. Use those events alongside the bond-status response to reconcile your records:
Matured(maturityDate, triggeredBy)records the scheduled maturity transition.MaturedEarly(originalMaturityDate, actualMaturityDate, triggeredBy)records the emergency maturity transition.Redeemed(holder, tokenAmount, payoutAmount)records each redemption.TreasuryUpdated(sender, oldTreasury, newTreasury)records treasury changes.- ERC-20
Approvalevents from the treasury to the feature feed the allowance value used by bond-status monitoring.
Monitor balance coverage and allowance coverage together. Balance without allowance still blocks wallet-treasury redemptions. Allowance without funds does not enable payouts.
Dependencies
- Denomination asset: the ERC-20 asset paid to holders on redemption. It must be deployed and accessible on the same EVM network as the token.
- Treasury: a wallet or contract that holds denomination asset for redemption.
- Operator process: an authorised process or user that calls
mature()at the scheduled time. - Indexer: the bond-status response depends on indexed balance, allowance, treasury classification, and solvency state.
Compatibility and ordering notes
supportsRewriting = false: the feature does not rewrite transfer amounts.- Place this feature before fee features in your ordered list because it enforces the post-maturity transfer restriction.
- Fixed Treasury Yield can be active on the same bond. Yield claims are pull-based and independent of the maturity state.
- Compliance modules can block transfers before maturity. Maturity Redemption blocks ordinary transfers after maturity regardless of compliance outcome.
- Forced recovery, forced transfer, mint, and burn flows have their own role controls. Treat post-maturity as a holder-redemption state, not a trading state.
Change impact
- Enable at deployment with face value and maturity parameters.
- Removing the feature before maturity removes the future redemption lifecycle.
- Removing the feature after maturity stops transfer blocking and removes the redemption path. Do not remove it after maturity without a replacement redemption process in place.
- Treasury changes affect future redemption calls.
See also
- Token features catalog: return to the full feature catalog.
- Fixed Treasury Yield: understand coupon payments that can coexist with maturity.
- Compliance modules: understand the transfer enforcement layer before maturity.
- System templates: pick a fixed-income template that attaches maturity-redemption to a new asset.
Permit
EIP-2612 gasless approvals for DALPAsset tokens. Holders sign approval messages off-chain, while a relayer submits the permit on-chain without changing transfer compliance.
Fixed Treasury Yield
Fixed-rate yield paid to token holders at periodic intervals from a treasury. Holders claim completed-period yield, and Historical Balances supplies the snapshot data used for entitlement calculation.