Lidofi withdrawals: requests, market exits and ETH claims

Per-request limits and changing withdrawal estimates

The Ethereum withdrawal contract accepts individual requests from 100 wei of stETH to 1 000 stETH, while withdrawal estimates change with queue demand and available ETH.

These bounds apply to each request’s stETH amount, including the amount obtained from wstETH. They don’t impose the same ceiling on a wallet’s total withdrawal. The request methods can create several requests within a batch, so larger withdrawals can use multiple entries. For wstETH, the contract checks the converted stETH amount against the bounds. Applying the ceiling directly to the wstETH token count would use the wrong unit.

Finalization funds each request completely; it doesn’t pay an unfinished request in installments. Separate requests can become claimable at different times as the queue advances. Splitting a withdrawal doesn’t bypass earlier requests. An estimate for a new request isn’t a deadline for an existing one. The latter already has its own queue position, and later funding or accounting updates can change its remaining wait.

Queued redemption and market sales

Protocol redemption uses Lido’s staking accounting, while market sales use trading prices and liquidity; the routes also differ in who controls assets during the exit.

A market sale can turn accessible tokens into ETH without waiting for this redemption queue. The price that a buyer or pool offers can differ from protocol redemption value. Trading fees and slippage also affect proceeds. A custodial venue adds its own asset-support and withdrawal conditions, so completing a trade there can leave an account balance that still needs an outbound transfer. The supported trading pair and destination network determine whether that transfer delivers the ETH needed.

Token access and Ethereum compatibility

A queue request requires spendable Ethereum stETH or wstETH and authorization for the withdrawal contract to move the selected tokens. The wstETH request method unwraps submitted tokens internally. A separate manual unwrap isn’t required for that method, and the resulting request records a stETH amount.

Allowance approval and a signed permit are alternative authorization mechanisms. An approval can require an earlier onchain transaction; supported permit methods combine the signed authorization with request submission. A permit must be valid, cover the requested amount and not have expired when the request executes. Its signature alone doesn’t establish a queued withdrawal. The request still needs successful execution, sufficient tokens and an unpaused request function. Approval applies to the token and spender that the wallet specifies. Selecting wstETH therefore requires authorization for wstETH, even though the queue subsequently accounts for stETH.

A token balance on another network has different contract and bridge dependencies. The Ethereum queue requires its supported Ethereum token contracts. Returning bridged tokens through a compatible bridge can restore access to that route, subject to the bridge’s settlement conditions and costs. An available local token market offers a separate possibility, with its own liquidity constraints. Neither a bridge transfer nor unwrapping alone completes an ETH redemption.

Vault-owned ETH follows a separate withdrawal path: connected stVaults must satisfy VaultHub’s collateral rules. Funds that remain staged for validator activation also remain unavailable for vault withdrawal. Lido Earn strategy exits can also have their own redemption wait. Those restrictions apply to the underlying product position, while this token-redemption queue acts on stETH or wstETH available to its caller.

Redemption amounts and the cost of leaving

The ETH payout follows the request’s recorded stETH amount and can decrease when protocol losses reduce the applicable redemption rate. For wstETH, that starting amount comes from its stETH conversion when the request executes. A queued request’s ETH payout cannot exceed the stETH amount recorded when that request was created. Waiting doesn’t add staking rewards above the submitted balance. Negative staking accounting can still affect pending requests before finalization. A shortfall caused by protocol losses differs from a secondary-market price discount.

View image file

Lido doesn’t charge a withdrawal-request fee for this token-redemption route. Ethereum gas still applies to request and claim transactions, plus any separate approval. Gas cost reflects the work that a transaction performs and the network fee rate when it executes. An ordinary transaction from an externally owned account needs ETH for gas; submitted staking tokens don’t automatically pay that fee. Multiple requests can share a request transaction, but extra entries still require computation. A withdrawal quote’s gas estimate therefore concerns transaction execution, separately from the ETH amount that the queue reserves.

When does the queue make ETH claimable?

A pending request becomes claimable when the protocol finalizes it, reserves its ETH and burns the underlying stETH, subject to funding and accounting conditions.

Queue processing follows request order. The buffer can draw on new staking deposits, execution-layer rewards and ETH returned by validators. Available buffer funds can serve withdrawals without waiting for a validator exit dedicated to that request. When funds are insufficient, obtaining ETH from validator withdrawals adds upstream Ethereum dependencies. Protocol accounting reports also need valid consensus data. A disruption to reporting can delay the state update that finalizes requests, even when a screen’s earlier estimate has reached zero.

A new-request waiting margin applies during normal Turbo operation. Bunker mode adds constraints that account for severe penalties or expected losses. Those conditions can extend the wait beyond an ordinary estimate. An unfinalized request remains in the queue while its dependencies resolve; paying more gas for a later claim transaction can’t accelerate protocol finalization.

NFT ownership and delivery of claimed ETH

The withdrawal NFT’s current owner controls the claim, and finalization makes reserved ETH available for a later claim transaction. Each request has an ERC-721 withdrawal NFT called unstETH. Transferring it moves the right to claim, including after a request becomes ready. A request identifier records the position; it doesn’t replace ownership. Losing control of the address that holds the NFT can prevent its owner from signing the claim. Granting an operator permission to transfer the NFT also exposes that claim right.

Request status distinguishes waiting, finalized and already claimed positions. The contract’s getWithdrawalStatus method exposes finalization and claim flags, while getClaimableEther reports reserved ETH for eligible requests. A submitted claim transaction needs successful execution before it proves receipt. Completion burns the NFT, marks the request as claimed and transfers ETH to the designated recipient. The owner can use a recipient-directed claim method to send ETH to another address where supported. Choosing that recipient preserves claim ownership until execution; transferring the NFT hands control of the entire claim to its new holder.