Pull capital out of the pool. Asynchronous, FIFO when capped.
Withdraw locks lending-vault shares under an on-chain order; settle(order_id) burns the locked shares and pays out a stablecoin accepted on the destination chain (per the chains catalog) against available pool liquidity, in the same tx. Asynchronous via on-chain order_id; queues with a published position when the pool is at the utilization cap.
The full Withdraw spec lives in the docs
The available-liquidity check, the FIFO queue model, NAV-priced redemption, payout chain selection, and webhook payloads. Python and Node.js tabs, copy-ready.
How withdrawals work
One call. Liquidity check. Payout or queue. NAV-priced and event-driven, the same shape as Redeem.
Submit the withdraw
One POST call with the share amount and the destination wallet. Flo verifies the holder, computes redemption value at live NAV, and inspects available liquidity.
Lock + create-order tx
One on-chain tx atomically locks the lending-vault shares under the order contract and creates an on-chain order_id. Shares are not burned at this step; they are held by the contract pending settlement. Status is "active" once this tx confirms; the stablecoin payout has not happened yet.
Settle on chain — burn and pay out
Flo's keeper calls settle(order_id) on chain once pool liquidity covers the redemption. The contract burns the locked shares and stablecoin lands in the destination wallet — all in the same settle tx. If utilization is at the cap, the order remains active in FIFO order until liquidity arrives. user_cancel(order_id) releases the locked shares back to the source wallet if the recovery window elapses (no re-mint; the shares were never burned).
Symmetric to supply. Same audit trail.
Every state transition is exposed via webhook and API so your books reconcile to Flo's without a manual matching step. Most withdrawals settle in seconds.
Asynchronous, reorg-safe
Withdraw submits one on-chain tx that atomically locks the user's lending-vault shares under the order contract and creates an on-chain order_id. Once pool liquidity covers the order, settle(order_id) burns the locked shares and delivers the stablecoin payout in the same tx. No cooldown periods, no scheduled windows at the API layer.
Deterministic FIFO clearing
If the pool is at the utilization cap, the order remains active at the back of a first-in, first-out queue and clears as borrowers repay or new supply arrives. Queue position is visible via the API and webhook stream. user_cancel(order_id) releases the locked shares back to the source wallet if the recovery window elapses (no re-mint needed; shares were never burned).
Per-chain stablecoin payouts
Receive payout in any stablecoin accepted on the destination chain — published live in the /v1/chains catalog (pay_out_currencies). Cross-chain payout uses the same Bridge primitive used for other Flo redemptions.
NAV-priced redemption
Vault shares burn at the live net asset value at the moment of settlement. Yield accrued up to that moment is included; no separate claim or harvest call.
Suppliers protected before queue
Two-kink utilization curve pulls in new supply and pushes out marginal borrows long before the cap. The queue is the safety valve, not the steady state.
Webhooks for every state
Subscribe to withdraw.queued, withdraw.advancing, and withdraw.settled to drive UI updates. Queue depth, ETA, and live NAV are exposed in the same webhook payload.
When the pool is at the cap
The withdrawal queue activates above 100% utilization, when no free liquidity remains in the pool. Two forces resolve the queue: borrowers repay (rate is at its highest, so repayment is economically attractive), and new supply arrives (yield is at its highest, so supply is economically attractive). The queue is FIFO by submission time. Each queued withdrawal exposes its position and ETA via the API and webhook stream so your UI can show users an honest expected settlement window.
Liquidity on demand, queue as a backstop
Just client.withdraw() and your users get stablecoins on the chain of their choice.