Centrifuge redemptions through vaults become claimable after fulfillment
Last updated:Centrifuge redemptions exchange fund shares for assets. Standard V3 vaults use a request-based process. A request becomes claimable after the manager prices and processes the approved shares, and fulfillment reaches the vault holding the request. The controller can then collect the available assets through an authorized claim. Approval alone does not establish a payout balance, and partial fulfillment can leave shares pending. Processing follows the financial product’s settlement terms.
Match the position to its redemption vault
The redemption vault must serve the shares you hold and the payout asset and network you intend to use. Submitting the request moves the selected shares from the owner into the pool escrow.
If cancellation matters, assess its approval boundary before committing shares. Cancellation can recover the unapproved portion; approved shares continue toward settlement.
- Confirm the vault’s share token, payout asset, network, and applicable redemption permissions before submitting a request.
- Identify the controller and any operator authorization; an address supplying shares does not automatically control every resulting claim.
- After submission, wait for a positive withdrawable asset balance before attempting collection. A confirmed, successful request transaction establishes submission.
- If reversal becomes necessary, check the unapproved portion and cancellation state before expecting shares to return.
- Once assets become claimable, collect an allowed amount to an eligible receiver. Reconcile the confirmed asset transfer with the remaining claimable and pending balances.
If the asset transfer or remaining balances do not match the claim, stop before submitting another request. A completed partial claim can leave a separate pending remainder.
Manager approval commits the approved shares
Cancellation applies to the unapproved amount; manager approval commits its allocated shares to processing and removes them from the cancellable balance.
Local pending shares can remain visible while the hub has already approved a portion. The cancellation outcome therefore depends on the hub’s processing state. Submitting a cancellation request does not guarantee the return of every share the local pending view still reports. Centrifuge’s cancellation extension tracks cancellation separately from asset redemption. A pending cancellation blocks new redemption requests for that controller in the affected vault. Fulfillment makes the canceled shares available through the cancellation claim function. That function returns share tokens, while an ordinary redemption claim pays the vault’s asset. The approved portion continues through its existing settlement.
What makes a redemption request claimable?
A request becomes claimable when the local request manager receives fulfillment and records the assets available for its controller to collect.
The hub’s BatchRequestManager groups requests by pool, share class, and asset. Approval establishes the share amount the manager will process. It does not complete the pricing operation or put the resulting assets in the receiver’s wallet.
Revocation applies the execution share price to the approved redemption. The protocol burns the corresponding shares and reserves the payout assets in the local pool escrow. Reserving those assets gives the redemption a defined payout allocation within the pool.
Fulfillment adds the processed asset amount to the controller’s withdrawable balance in AsyncRequestManager. It also reduces the outstanding requested shares by the fulfilled portion. The vault can now expose that entitlement through its claim views.
A hub execution event and a local claimable balance describe different states. Cross-chain notification can separate their appearance when the vault operates away from the hub. The receiver obtains funds through the authorized claim, so a claimable entitlement remains distinct from an asset transfer.
Partial fulfillment leaves a pending remainder
A batch can fulfill part of each redemption when the manager approves less than the total pending share amount in that batch. The approved fraction applies proportionally to its requests. Unprocessed shares remain pending for later settlement, so a controller can have available assets and an outstanding request simultaneously.
The batching sequence determines which requests enter each approval group. Proportional allocation then divides that group’s approved amount among its participants. It does not give the earliest individual request an automatic full payout. Different portions can settle in different batches and at different execution prices. Collecting an available portion leaves the unprocessed remainder intact.
Execution prices determine the redemption proceeds
The payout combines the approved share quantity with the execution share price and the redemption asset’s price in the pool’s denomination. The share price values the fund units; the asset price translates that value into payout units. A pool’s accounting currency and its vault asset therefore have different jobs in the calculation. The batch records the asset price at approval and applies the share price at revocation. An estimate shown before processing can differ from the resulting entitlement because the execution prices can change. Claiming later does not select a new price for an already executed portion.
When several fulfilled portions accumulate before collection, the local request manager combines their asset entitlements and maintains a weighted redemption conversion. The available asset balance represents those processed portions. Multiplying all requested shares by the latest displayed price can include shares still awaiting execution.
The vault fixes the payout asset and network
A local vault claim pays its configured asset on the network hosting that vault, even when the manager operates from another hub. Several vaults can serve one share class, with different assets or networks. Their shared token does not merge each vault’s pending requests and claimable balances. The selected vault identifies the actual payout path; the pool’s denomination identifies the accounting unit.
Controllers authorize claims and receivers receive assets
The owner supplies shares, the controller controls the request, and the receiver is the asset destination when an authorized caller claims. One address can occupy these roles, but the interface permits them to differ. The controller or its approved operator authorizes collection. Operator approval grants operational authority over vault requests; it does not replace the product’s eligibility rules. A permitted controller also does not guarantee every chosen receiver passes the claim’s transfer restrictions.
Read claimable shares separately from payout assets
The request views express different quantities, so an integration must keep share units separate from the assets available through a claim. pendingRedeemRequest reports requested shares still awaiting fulfillment. claimableRedeemRequest and maxRedeem describe the share amount available for collection, while maxWithdraw reports the corresponding payout assets.
The base vault uses request ID 0. The vault address and controller distinguish its request balances, so the returned ID alone cannot identify an individual payout. Integrations also need the token’s decimal precision when displaying raw amounts. Shares and payout assets can use different precisions; matching their raw integers does not establish an equivalent financial value.
withdraw selects the asset amount to collect; redeem selects the fulfilled share amount. Centrifuge’s base implementation favors withdraw for collecting redemption proceeds because share-based conversion can leave rounding dust. Product transfer controls still govern collection, and restricted controller activity can make the maximum claim views return zero. A displayed fund position alone does not establish withdrawal capacity.
Questions worth asking
Are redemptions instant in a Centrifuge synchronous deposit vault?
SyncDepositVault processes deposits synchronously, while redemptions use the asynchronous request and claim model. Its deposit interface follows ERC-4626 behavior, and its redemption interface uses ERC-7540. Receiving shares immediately when investing therefore does not establish immediate withdrawal availability. Redemption assets become available through the manager’s settlement process, with the same claimable-state distinction used by asynchronous vaults.
How long does a pending Centrifuge redemption take to settle?
Settlement timing follows the product’s redemption cycle and the issuer’s processing schedule. A confirmed, successful redemption request transaction only establishes the request, so its confirmation time does not measure the remaining settlement period. The product’s liquidity and offchain settlement terms can affect processing. A pending status by itself supplies neither an exact payout date nor evidence the request has failed.
Does free transferability make fund shares eligible for redemption?
A freely transferable token can still require membership for redemption against its pool. Centrifuge products can apply different rules to transfers, subscriptions, and redemptions. A secondary-market purchase therefore does not automatically satisfy redemption access. Approval also applies per network, so membership elsewhere does not establish eligibility at the selected vault. The applicable product restriction profile governs the action.
Which gas costs accompany a vault redemption?
The investor pays the gas for local vault transactions in the documented V3 flow. Cross-chain request messaging draws funding from the pool’s subsidy balance, which the issuer replenishes. Product-specific redemption charges, if any, follow the offering’s terms and remain separate from network gas. The messaging subsidy does not cover every local transaction.
Can selling shares on a secondary market replace a redemption request?
Selling freely transferable shares offers a separate exit where a suitable market has sufficient liquidity. The sale settles at a market price, while redemption exchanges shares against the product under its execution and settlement terms. Availability depends on transfer permissions and the actual market. A listed share price does not establish a buyer, usable market depth, or a sale price.
Do manager-operated direct redemptions use the same claimable request states?
A manager can process a direct redemption outside the standard investor vault request flow. Direct operations use the applicable execution price and still respect the token’s memberlist. Managers should coordinate direct redemptions with investors because they bypass the standard request flow. A direct redemption therefore should not automatically be interpreted through a vault’s pending and claimable request balances.
What does a reverted redemption preview mean?
The asynchronous redemption interface intentionally makes previewRedeem and previewWithdraw revert. A failed preview alone therefore does not establish a failed redemption or unavailable funds. These functions cannot supply a controller-specific claim quote. The pending and claimable request views describe its state, and maxWithdraw reports the asset amount available under the applicable controller restrictions.