Lido withdrawals turn queued stETH requests into claimable ETH after finalization
Updated ·
Lido withdrawals return ETH through a queued redemption that requires finalization and a separate claim transaction. The protocol accepts stETH and supported wstETH on Ethereum, unwrapping wstETH within the request. An unstETH withdrawal NFT represents the queued position. Once the protocol reserves ETH for that request, its current owner can claim the funds; finalization alone does not send ETH to the wallet.
A market sale offers another exit, with pricing that follows available liquidity. Native redemption follows the withdrawal queue’s accounting rules. The choice changes once tokens enter the queue, because an accepted request cannot be cancelled to recover the submitted tokens.
Request size and finalization have different limits
The contract limits each request’s size, while finalization also requires sufficient ETH, an eligible request timestamp and an accepted accounting report.
Bounds for an individual request
The withdrawal contract accepts at least 100 wei of stETH and at most 1 000 stETH per request, including both endpoints. Larger totals require several requests. These bounds apply to each queued entry, rather than the wallet’s entire balance or a daily withdrawal allowance. A single request transaction can create multiple entries.
Conditions for entering the queue
New requests require an active queue, sufficient transferable tokens and authorization for the withdrawal contract to spend them. The wstETH path checks the resulting stETH amount after unwrapping. A valid amount does not reserve immediate ETH or bypass earlier requests.
Conditions for claiming
A claim requires an existing, finalized request that has not already been claimed. The claim call must come from its current owner. These conditions apply separately to each request, so ownership of one claimable NFT does not establish that another entry is ready.
Choose an exit that matches the balance and queue state
An unlocked token balance permits different actions from a pending withdrawal NFT, and the queue’s pause state changes whether a new request can enter.
- If the balance sits on another network, a compatible bridge must return the supported token to Ethereum before native redemption. A supported local market swap is a separate alternative.
- When new requests are enabled, authorize and submit amounts within the contract’s bounds. Confirm that the successful transaction created the expected request IDs and withdrawal NFTs.
- If request placement is paused, wait for resumption or consider a market sale of tokens that remain outside the queue. That option needs available liquidity and an acceptable ETH output.
- For an existing pending request, wait for its finalization status to change. Passing the displayed estimate does not authorize a claim.
- Once a request is finalized, its owner can claim and reconcile the ETH transfer with the recorded claim amount. Account for gas separately when comparing wallet balances.
Moving tokens into a request replaces the spendable token balance with a transferable claim right. A market sale leaves no protocol withdrawal request to claim afterward.
Token format and network determine compatibility
The native queue accepts its supported Ethereum stETH and wstETH contracts, so both token identity and the network determine whether a balance can enter.
stETH and wstETH inputs
Submitting wstETH does not require a separate manual unwrap beforehand. The withdrawal method transfers the wrapped tokens, unwraps them and records the corresponding stETH amount. That conversion explains why the request can display a different token quantity from the original wstETH input. The amounts describe different units; they do not establish a withdrawal loss.
Bridged or deposited balances
A bridged representation on another network does not become an Ethereum queue input simply because it shares a ticker. Returning it requires the compatible bridge route. Tokens deposited in a DeFi position also remain subject to that position’s release conditions. Collateral obligations or available liquidity can constrain access before Lido’s own request rules apply.
Approval authorizes spending before a request exists
The queue needs spending authorization before it can transfer tokens into a request and create the corresponding withdrawal NFT. An allowance transaction can provide that authorization in advance. Permit-enabled methods can use an ERC-2612 signed approval within the request transaction, where the wallet and interface support it. Approval and request creation therefore do not always require separate on-chain transactions. A signature alone does not prove that tokens entered the queue. The successful request record establishes the submitted amount and owner, while its request ID identifies the entry whose status matters later.
How long does a Lido withdrawal take?
A request becomes claimable when it reaches an eligible finalization batch with enough ETH, so elapsed time alone does not establish readiness. The queue finalizes requests in first-in, first-out order. The amount waiting ahead, incoming ETH and Ethereum validator withdrawal activity all affect timing. Lido’s interface provides estimates for new and existing requests, but changing demand can move them. A submitted transaction can confirm promptly while the withdrawal remains pending. Network confirmation and queue fulfilment measure different delays.
Finalization also relies on accepted AccountingOracle reports and their eligibility rules. A request created too close to a report’s reference time must wait beyond the applicable timestamp margin. That margin is a protocol setting, not a universal completion deadline. Large losses can introduce further delays.
Available ETH connects the buffer to the queue
Requests can use ETH already in the protocol’s buffer, so native redemption does not require a matching validator exit for every submitted entry. New staking deposits and received validator withdrawals can replenish available ETH. Execution-layer rewards provide another source. WithdrawalVault collects ETH arriving from Ethereum’s validator withdrawal process, and protocol accounting brings those funds into the buffer. If available funds fall short of withdrawal demand, additional validator withdrawals or exits can supply the difference. Their timing introduces Ethereum-level dependencies beyond the queue itself.
Eligible withdrawals take priority over sending available buffer funds into validator deposits. Finalization reserves ETH in the withdrawal contract for the corresponding requests. Reserved funds support claims that the protocol has already finalized; the unfinalized portion still depends on future funding and eligibility.
Finalization fixes the amount that becomes claimable
The finalized ETH amount follows the recorded stETH and underlying shares, with a cap based on the amount submitted when the request entered the queue.
A request’s ETH payout cannot exceed the stETH amount locked when that request was created. Submitted tokens therefore do not add further staking rewards to the withdrawal payout while they wait. The protocol burns the queued stETH at finalization. Continuing rebases on tokens still held outside the queue belong to those separate holdings.
Losses can reduce the claim below the submitted amount. Finalization applies the relevant ETH-per-share rate, and a sufficiently adverse accounting change can produce a discounted redemption. The withdrawal cap limits upside during the waiting period without removing exposure to applicable staking losses.
For wstETH requests, compare claimable ETH with the recorded stETH equivalent. Comparing it directly with the wrapped token count mixes units. Small integer-rounding differences also require separate treatment from a material loss.
Bunker mode changes finalization during losses
Bunker mode adds finalization restrictions when the protocol detects or anticipates a negative consensus-layer rebase, while a queue pause separately controls request placement and finalization.
Accounting for unresolved losses
Normal operation uses Turbo mode. Bunker mode changes which request timestamps qualify for finalization so withdrawals account for relevant negative rebases and unresolved slashing effects. A pending request can consequently take longer even if it predates the mode change. Available ETH alone does not remove those eligibility restrictions. Bunker mode does not establish that every request will lose the same amount.
Pausing queue operations
The withdrawal contract’s pause mechanism blocks new requests and finalization. It leaves claims for already finalized requests available. A pause therefore affects pending and claimable entries differently. A general interface warning cannot establish the state of an individual request; its recorded finalization and claim status still determine the applicable action.
The withdrawal NFT carries ownership of the claim
The current holder of the unstETH NFT owns the withdrawal right, so transferring the NFT also transfers its ETH claim. Each NFT uses the ERC-721 standard and corresponds to a specific request ID. Its token count does not express an ETH balance. Transferring a pending NFT changes ownership without creating a new request or restarting its position in the queue. A sale introduces separate market pricing: a buyer’s payment for the NFT need not match its eventual redemption amount.
A successful claim burns the NFT. Its disappearance after claiming can therefore reflect completion.
Gas costs follow the transactions that reach Ethereum
Lido does not charge a native withdrawal request fee, but Ethereum gas applies to the transactions used for authorization, requesting and claiming. The gas total changes with network fees, contract execution and the authorization method. Splitting a large total into several requests within one transaction does not create a separate request transaction for every NFT. It can still increase execution work. Any approval transaction adds its own network cost, and claiming happens later at the fees applicable then.
Staking reward fees describe a different charge and do not become a second redemption fee. Market exits have their own execution costs and pricing effects. For a claim to the same wallet that pays gas, the net ETH balance increase can be smaller than the claim’s recorded transfer.
Claim status separates reserved ETH from received ETH
A finalized, unclaimed request has ETH available to claim; a successful claim transaction establishes its transfer and completes the request. A pending NFT does not establish a claimable transfer. Wallet artwork can also lag behind the on-chain status. The claim interface and the request’s recorded status resolve readiness more reliably than an NFT thumbnail. Another token approval cannot make a pending request ready.
A reverted claim attempt on an unclaimed request does not complete it, although an included transaction can consume gas. The transaction outcome therefore matters more than a submitted transaction hash. Completion records also distinguish the owner who claimed from the recipient who received ETH when a supported claim method specifies another address. The WithdrawalClaimed event identifies the request, owner, recipient and transferred ETH amount.
Key questions about Lido withdrawals
What does an expired permit mean for a withdrawal request?
An expired permit cannot provide token authorization for a permit-based withdrawal request. Its deadline limits that signed approval, rather than setting a deadline for an existing withdrawal claim. A request using a sufficient existing allowance follows a different authorization path. Permit expiry does not cancel a previously accepted request or change an NFT’s recorded finalization status.
Can several finalized withdrawal requests be claimed in one transaction?
The withdrawal contract supports claiming several finalized requests in one transaction. Every included request must belong to the caller, remain unclaimed and satisfy the method’s requirements. Batch methods also require valid checkpoint information for the selected entries. Including an ineligible request can revert the transaction, so a pending entry cannot share a successful claim batch merely because its owner also holds ready requests.
Does approving a withdrawal NFT let another wallet claim its ETH?
An NFT transfer approval alone does not satisfy the claim method’s ownership requirement. However, the approved address may transfer that NFT, and its new owner then holds the claim right. Token spending approvals and NFT transfer approvals grant different permissions. Treat authorization to move a withdrawal NFT as control over an asset that carries its associated ETH redemption right.
Will a claim fail if the receiving contract rejects ETH?
A claim reverts if the specified recipient rejects the ETH transfer. The reverted transaction does not leave the request successfully claimed. The claimWithdrawalsTo method supports sending ETH to another recipient, while still requiring the caller to own the request. An interface may not expose this method. Gas consumed by a transaction included on Ethereum remains a separate cost.
How should a zero claimable ETH value be interpreted?
The getClaimableEther query returns zero for a request that remains unfinalized or has already been claimed. That value alone does not distinguish those states. The request’s finalization and claim flags provide the missing context. An invalid request ID or invalid checkpoint information can instead cause the query to revert, so a query error and a zero result have different meanings.
Why can a permit-based request fail after its allowance has been set?
A permit-based request can fail if another transaction has already submitted the same signed permit and consumed its nonce. This documented failure does not itself imply token loss. The established allowance may still support the ordinary request method, provided it covers the intended transfer. Other failures need their own diagnosis; insufficient balances, invalid amounts and queue pauses do not share that explanation.
Is the original token sender always the withdrawal NFT owner?
The request methods allow a designated owner that differs from the address supplying the tokens. That owner receives the withdrawal NFT and controls its transfer and claim rights. Supplying the stETH or wstETH does not preserve a separate claim right for the sender. Integrations that designate another owner therefore change who must hold and authorize the later claim.