Skip to main content
Redeeming converts fund shares back to assets. Same batched model as depositing, plus a fund stage: capital is often deployed at settlement, so assets must return to the Fund before payout.

​
Timeline

1

Request

Call redeem(asset, shares) on the RedeemQueue for the payout asset you want. Approve the share token first; the queue escrows shares. RiskManager enforces minimums and batch caps. Request joins the current batch.
2

Settle

On report acceptance, the queue transfers batch shares to the Fund (burned) and snapshots the payout — assets owed at the accepted price minus exit fee. Later fee or price changes cannot change that batch’s owed amount.
3

Fund

Settlement records what is owed. The operator returns assets to the Fund (pull from strategies, or inbound from external wallets / bridges) and calls fundRedeem. The batch becomes claimable.
4

Claim

Call claimRedeem(asset, batchId) for your pro-rata assets.

​
Why funding is separate

In a fully on-chain vault, assets often sit in the contract and withdrawals pay immediately. Here capital usually sits in strategies, custody, or another chain. Settlement fixes the amount owed; funding is the operator step that returns assets. Time from settlement to funding depends on how fast the operator can unwind. Funds should document expected redemption timing.

​
Claim math

batchAssetTotals is the payout snapshotted at settlement (net of exit fee).

​
Cancelling

Cancel a current-batch redemption before settlement with cancelRedeem(asset) to get shares back. After settlement, wait for funding and claim. An admin can cancel a stuck request in any unsettled batch and return shares.

​
One request per batch

At most one redemption request per asset per batch.

​
What can block a redemption

See Risk controls.