Maple Maple withdrawals depend on pool liquidity and the configured redemption route
Maple withdrawals exchange pool shares for underlying assets as liquidity becomes available in the relevant pool. In queue-based pools, lenders submit redemption requests, and processing follows first-in, first-out order. Requesting withdrawal moves selected shares into the withdrawal manager’s custody and establishes their place in line. Low liquidity can leave a request waiting or only partly filled. Automatic redemptions send assets directly to the owner, while configured manual redemptions require a later redemption call. Transferable syrupUSDC also has a market-sale alternative, whose execution depends on trading liquidity. Available pool cash, queue position, and share valuation affect different parts of the exit.
Limited pool cash restricts immediate exits
When loans hold much of a pool’s capital, available cash can support only part of its pending redemptions, even when the pool reports substantial total assets. The pool’s accounting includes cash and assets under management, such as outstanding loan principal and accrued interest. Those lending assets contribute to position value while remaining deployed outside the pool’s immediately spendable balance.
Repayments and returns from deployed strategies can replenish cash available for withdrawals. Earlier queued requests also have a claim on processing capacity. A large portfolio value therefore does not establish the amount available for a particular pending exit. The requested share amount describes the size of that exit; available cash describes its present funding constraint. Neither figure establishes a fixed completion date.
Requested shares move into withdrawal custody
A redemption request specifies how many pool shares the lender wants to exit, and the withdrawal manager holds those shares until redemption or cancellation. Escrow means this temporary custody of the requested shares. The Pool contract records lending shares, while the WithdrawalManager tracks pending requests and their owners.
The pool’s requestRedeem operation transfers selected shares into that custody. A falling wallet share balance at this stage reflects their movement, without establishing receipt of underlying assets. Unrequested shares remain outside the request. An account can consequently have wallet-held lending shares and escrowed shares at the same time, with different actions available for each balance.
Queue order and partial settlement
Earlier requests receive processing priority over later requests, so available pool cash alone cannot show whether a particular pending withdrawal will settle in the next processing transaction. First-in, first-out describes this ordering. Authorized processors select the share amount to process and service requests from the front of the queue.
The processor must select an amount the available liquidity can support. In the upgraded manager, an excessive processing amount causes the transaction to revert.
A processing transaction can fully satisfy earlier requests and redeem only part of the final request it reaches. The unprocessed remainder keeps its original queue position. Partial settlement therefore reduces the pending share amount without sending that remainder to the back of the line. Subsequent processing can redeem more when liquidity and the processing amount permit.
A smaller newly submitted request still enters behind earlier requests. Its size alone does not create priority. Partial payment and continued waiting can coexist within one request, making the remaining share amount relevant alongside any assets already received.
Share valuation changes the assets paid out
The assets paid for redeemed shares depend on the pool’s applicable exit exchange rate, which incorporates its recorded value and any unrealized losses at redemption. An exchange rate here means underlying asset units per pool share. It is a valuation relationship, separate from the cash available to fund the payment.
The withdrawal exchange rate subtracts unrealized losses from total pool assets before dividing by total share supply.
The pool’s convertToExitAssets function applies the exit valuation to a share amount. A conversion estimate describes value; it does not reserve liquidity or establish when the manager will redeem those shares.
An impairment records a potential loss before the final outcome of a troubled loan or strategy. It can reduce withdrawal value while a repayment, restructuring, or collateral liquidation remains unresolved. Deposit valuation and exit valuation can therefore differ during an impairment.
For Syrup lending positions, withdrawing while an impairment remains active crystallizes the reduced value on the shares redeemed. Future recoveries accrue to positions remaining in the pool under the applicable recovery accounting. Waiting preserves exposure to both recovery and further loss; it does not establish repayment. These conditions concern the amount ultimately received, independently of queue delay.
Do pending Syrup withdrawals continue earning interest?
Pending withdrawal requests for syrupUSDC and syrupUSDT continue earning the pool’s applicable interest until processing, with accrued value reflected in the shares’ valuation. Submitting a request therefore does not freeze its underlying-asset amount. This accrual does not override an impairment’s effect on exit value. Once automatic redemption completes, the redeemed shares no longer represent a lending position.
Reducing or cancelling pending requests
The upgraded queue manager lets a request owner reduce or cancel a specific pending request by its identifier before processing consumes the affected shares. The removeSharesById function returns the selected shares to their owner. Removing the entire remaining share amount cancels the request. Removing less leaves the balance in its original position.
Version 2.0.0 supports multiple concurrent requests from one address. Each has its own identifier, so an additional request does not replace every earlier request. Existing requests can shrink; adding more shares requires another request with its own queue position.
Cancellation restores lending shares and preserves their exposure to the pool. It produces no underlying-asset payout, and it cannot reverse a completed redemption.
Withdrawal routes and pending-share controls
Available exit routes and request controls produce different balances: redemption pays underlying assets, cancellation returns lending shares, and a market sale delivers its selected output token. Manual redemption requires an account setting controlled by protocol operators. The crosschain route also depends on its deployed receiver configuration.
| Route or control | Availability condition | Balance change | Constraint or failure condition |
|---|---|---|---|
| Automatic queued redemption | Pending shares and automatic account setting | Redeemed shares become underlying assets | Earlier requests and available cash constrain processing |
| Configured manual redemption | Operators have enabled manual mode | Processed shares become available for a later redemption | Payment requires another call and sufficient liquidity |
| Reduce a specific request | Request owner and unprocessed shares | Removed shares return; the remainder keeps its position | The existing request cannot grow through this control |
| Cancel a specific request | Request owner removes all remaining shares | Pending shares return to their owner | Already redeemed shares are outside the request |
| Pool removeShares compatibility path | Escrowed requests in the upgraded manager | Shares return starting with the latest request | Removal can affect multiple requests in reverse order |
| Market sale of syrupUSDC | Wallet-held transferable tokens and trading liquidity | Shares exchange for the selected output token | Fees and slippage affect received proceeds |
| CCIP receiver redemption | Configured pool, receiver account in manual withdrawal mode, and enabled redemptions | Queued shares redeem into assets returned to the origin chain | Pool settlement and funded return messages remain necessary |
Market sales use trading liquidity
syrupUSDC has secondary-market swap routes through Uniswap and Balancer, where available trading liquidity determines whether an executable sale can deliver the chosen output asset. The swap draws on market liquidity rather than servicing the lender’s withdrawal request. Its execution terms include trading fees and slippage, the change between expected and executed trading amounts.
The withdrawal manager’s custody prevents a wallet from spending the same queued shares in a swap. Only shares available to the selling wallet can fund that sale. A pool valuation can help interpret the value represented by those shares, while the market’s executable quote determines trade proceeds. A quote estimates the sale’s output; successful execution determines the amount received. Selling shares also ends the seller’s claim to their future pool yield.
Automatic settlement and manual claims
Automatic queue processing redeems the processed shares and sends assets to their owner, whereas manual processing makes shares available for a later call to the pool’s redeem function. Manual mode is an internal ERC-4626 compatibility feature enabled by the pool delegate or operational administrator. Automatic settlement remains the default route.
A RequestCreated event records entry into the queue. A RequestProcessed event describes processing, whose meaning depends on the account’s mode. In manual mode, processing can precede asset delivery. A removed request can also reflect cancellation, which returns shares. Successful asset transfer establishes payment for an automatic redemption; manual settlement additionally requires the later redemption to succeed. Queue records alone cannot identify every change in the recipient’s asset balance.
Crosschain exits add a return transfer
Supported crosschain integrations send pool shares to Maple’s configured receiver, which queues their redemption and later returns underlying assets to the origin chain through CCIP. CCIP means Chainlink’s Cross-Chain Interoperability Protocol. It carries tokens and messages between supported chains.
The receiver binds to a specific pool and validates the message sender, pool, and incoming token. Redemptions must be enabled in its configuration. The receiver deducts any configured redemption fee in shares, converting the asset-denominated fee at the exit rate. Incoming shares must exceed the fee shares; otherwise processing fails before a request is created. When this receiver uses the queue manager, operators must enable manual withdrawal mode for its account before queue processing. A designated redemption executor then redeems processed shares and submits the return transfer. The receiver also needs funding for outbound message fees. A queued crosschain request therefore remains subject to pool liquidity as well as the return-transfer mechanism.
Holding a bridged share token on a chain does not establish support for every redemption integration on that chain. The deployed receiver and its supported configuration determine the route. An outbound message identifier records a transfer message; completion on the origin chain establishes delivery of the returned assets.
Access rules and settlement limits
Pool permissions and protocol pauses can prevent a withdrawal operation even when an account owns shares and sufficient underlying cash appears available in the relevant pool. The PoolPermissionManager governs access through the pool’s configured permission rules. These rules can apply to specific functions, so an allowed deposit does not establish permission for every later operation.
Maple’s pause mechanism can act globally, on a contract, or through function-specific exceptions. A paused operation and a pending request awaiting cash consequently require different explanations. For an exit involving partial processing, the unsettled shares remain exposed to the pool, including after cancellation returns them to the owner. Received underlying assets establish payment for the completed portion; the remaining request continues to carry its own liquidity and valuation constraints.
Maple withdrawals - your questions answered
Which pending withdrawal does requestIds return after the queue upgrade?
In the version 2.0.0 queue manager, requestIds returns the account’s latest pending request identifier. It does not enumerate every request when the address has several. The requestsByOwner function returns the owner’s pending request identifiers and corresponding share amounts. Integrations using the older single-request assumption can consequently omit earlier requests from their display even though those requests remain pending.
Why can lockedLiquidity return zero while Maple withdrawals remain pending?
The queue manager’s lockedLiquidity function returns zero as a compatibility value, rather than measuring the cash available for redemption. The function therefore does not show that pending withdrawals have settled or that the pool lacks assets. Available pool cash, pending requests, and any manually redeemable shares are separate state. A dashboard treating this field as a live liquidity balance can misdescribe withdrawal availability.
Can a failed token transfer block automatic withdrawal processing?
A reverting asset transfer can prevent an automatic processing transaction from completing. Automatic settlement sends assets to request owners, so a recipient-specific transfer restriction can affect the queue. Authorized operators have a request-removal mechanism to address a blocking request. Successful removal returns its pending shares; it does not complete the underlying-asset payout or guarantee that another transfer to the affected recipient will succeed.
Is requestWithdraw available in the queue-based withdrawal manager?
The queue-based manager uses share-denominated redemption requests and disables the requestWithdraw and withdraw paths. A wallet interface may label the action Withdraw while submitting a requestRedeem operation underneath. The requested quantity at contract level is shares, and their underlying-asset value follows the applicable exit exchange rate. The presence of an asset-denominated function in the broader Pool interface does not establish support under this manager.
What happens to a failed crosschain withdrawal message when a retry also fails?
A stored message remains FAILED when the receiver’s retry operation reverts. Retrying requires an existing failed message and relies on the receiver’s native-token balance for outbound fees. The separate recovery function attempts a retry first. If it fails, the function submits a CCIP transfer of the original tokens to their sender, with the caller funding return-message fees. An underfunded or reverting return submission leaves the stored message FAILED. Successful submission marks it RESOLVED; delivery still requires execution on the origin chain. These recovery functions address stored message failures, not ordinary withdrawal requests waiting for pool liquidity.