Lido is a stETH position whose native exit runs through a withdrawal queue

Lido is a stETH position whose native exit passes through a FIFO withdrawal queue before ETH reaches the wallet. Staking begins with an ETH transaction and produces rebasing stETH. Closing through the protocol reverses that exposure in two active steps: submit a withdrawal request, then claim after finalization. The pending request is represented by an unstETH NFT, and rewards stop accruing on the locked amount after the request enters the queue.

Each native withdrawal request accepts from 100 wei to 1 000 stETH, so larger exits are split before finalization.

Should you swap stETH or enter Lido's withdrawal queue?

The Lido withdrawal queue fits users who prefer protocol redemption, while a decentralized exchange fits users who value immediate execution and accept market pricing.

Native redemption targets the protocol-calculated ETH amount. The queue adds no Lido withdrawal fee, although both the request and claim consume Ethereum gas. A swap through Curve, Uniswap, or an aggregator such as 1inch, CoW Swap, or ParaSwap settles in one trade. Its quote reflects available liquidity, pool fees, price impact, and gas at that moment. Compare the executable swap output with the queue's estimated claim amount and timing before committing. An on-chain queue request has no cancellation path.

The decision turns on four facts: the deadline for receiving ETH, the stETH or wstETH amount being closed, the secondary-market quote after price impact, and the Ethereum gas needed for every remaining transaction.

Open the position with one ETH stake

A Lido position opens when a user submits ETH on Ethereum and receives stETH representing shares in the protocol's pooled stake.

Connect an Ethereum wallet, choose the ETH amount, and confirm the staking transaction. MetaMask signs directly, while a Ledger device confirms through the connected wallet interface. Once Ethereum settles that single submission, the wallet holds stETH. The validator deposit remains pooled inside the protocol rather than appearing as a personal validator record. stETH follows the ERC-20 interface and uses 18 decimal places. Its economic accounting rests on shares rather than a fixed number of tokens created once and left unchanged. That token remains transferable while the pooled validator position stays inside Lido.

Keep native ETH outside the stake for later gas. Opening consumes one state-changing transaction; closing through the native queue requires at least two more.

The six-stage position path

The Lido position lifecycle has six ordered stages, from an ETH submission through a separate claim that returns native ETH to the controlling wallet.

The adjustment stage is optional, but the request and claim remain separate. The table also separates a wallet-visible token change from protocol finalization: receiving unstETH records the claim right, whereas receiving ETH ends the lifecycle.

Read stETH as a balance backed by shares

A Lido stETH balance expresses pooled staking shares in ETH terms, so the displayed token amount changes when protocol accounting updates the shared exchange rate.

The displayed stETH amount

Wallets present stETH with 18-decimal ERC-20 precision. One ETH contains 10 ¹⁸ wei, and stETH uses the same base-unit scale. An Accounting Oracle report updates total pooled ether. The token contract then converts each account's unchanged share count into a revised stETH balance. No reward transfer needs to arrive in MetaMask for that displayed amount to move.

The share ledger

The durable ledger item is the account's fraction of total Lido shares. In compact form, an account's stETH balance equals its shares multiplied by total pooled ether, then divided by total shares. That relationship explains both rebases and the conversion into wstETH. This internal accounting avoids distributing a separate reward transaction to every holder.

Unwrapped stETH

Unwrapped stETH exposes the changing token amount directly. Sending or requesting part of it reduces the account's shares by the converted amount, while the untouched portion continues through later accounting updates.

Wrapped wstETH

Wrapped stETH keeps the wstETH token count fixed and lets its stETH conversion value rise or fall with the share rate. The wrapper changes representation, not the underlying share exposure.

Wrap only the portion that needs a fixed token balance

A Lido holder wraps stETH into wstETH when a fixed token quantity is easier to track or integrate, while the underlying staking exposure stays share-based.

Wrapping is a routine position adjustment rather than an exit. The wrapper locks stETH and mints wstETH; unwrapping burns wstETH and returns the corresponding stETH amount. This fixed-balance form works cleanly with integrations that expect ordinary ERC-20 quantities. Examples include many Uniswap routes and Ethereum bridges. Curve also supports established stETH liquidity, so the desired venue and accounting style determine which representation is more convenient.

The native withdrawal queue accepts either token. A wstETH request unwraps inside the transaction, records the converted stETH amount, and mints unstETH without requiring a separate manual unwrap.

Size the withdrawal request before signing

A Lido native withdrawal accepts each stETH-denominated request only within the contract's fixed lower and upper bounds, with larger positions divided across request IDs.

Each request must contain at least 100 wei of stETH and no more than 1 000 stETH. Because stETH has 18 decimals, 100 wei equals 0.0000000000000001 stETH. The maximum applies per request rather than per transaction, so an interface may submit several valid amounts together and mint one unstETH NFT for each amount.

For wstETH, read the converted stETH value before signing because that converted amount is tested against both bounds. The queue records the stETH amount and underlying shares at submission. From that point, the locked amount stops earning later staking rewards, even while its request remains pending.

The queue's FIFO and finalization gates

The Lido WithdrawalQueueERC721 processes requests in FIFO order, yet finalization still waits for eligible requests, available ETH, and the Accounting Oracle's report, as broken down in Lido guide use cases.

FIFO means earlier request IDs are considered before later IDs. Funding comes from the protocol's ETH buffer and new stake. Execution Layer rewards, Maximal Extractable Value rewards, and Ethereum Consensus Layer partial or full withdrawals also feed that budget. The oracle calculates how far the queue can advance within that ETH budget and a safe timestamp border. The budget is denominated in ETH and declines as the calculation advances. Finalization then reserves ETH in the queue contract and burns the stETH assigned to the completed range.

The finalization calculator holds up to 36 batch endpoints and represents its maximum share rate with a 10 ²⁷ precision base. Batches separate requests whose recorded share rates fall on different sides of that maximum. Nominal requests preserve the recorded stETH amount. When a batch's recorded share rate exceeds the checkpoint maximum, its claim equals shares multiplied by that maximum and divided by 10 ²⁷ .

Turbo mode uses the ordinary safe border. Bunker mode shifts that border under severe validator penalties or a negative rebase, extending the path to finalization. FIFO fixes sequence, not elapsed time: the live queue ahead, available ETH, Ethereum validator exits, and protocol mode set the wait.

When does a Lido withdrawal become claimable?

A Lido withdrawal becomes claimable only after the queue finalizes its request ID, reserves the corresponding ETH, and marks the request as finalized.

The contract's getWithdrawalStatus response contains six fields: submitted stETH, locked shares, owner, timestamp, isFinalized, and isClaimed. The last two are Boolean states, so a claimable request has the first set to true and the second set to false. Request IDs and checkpoint indices start at 1; a last ID of 0 means that no entry exists in that sequence.

The Lido interface translates those values into pending and ready-to-claim states. An estimated date remains a forecast because finalization consumes a changing ETH budget. The on-chain finalized flag is decisive. A positive value returned by getClaimableEther confirms the amount available; that getter returns 0 before finalization and after a completed claim.

The unstETH NFT carries the claim right

The Lido unstETH NFT is the transferable on-chain record of a pending withdrawal and gives its current owner the eventual right to claim reserved ETH.

WithdrawalQueueERC721 implements ERC-721 ownership, ERC-165 interface detection, and ERC-4906 metadata updates for unstETH. Exactly one NFT is minted for each request amount. Its metadata may change when finalization occurs, and the token is burned after the ETH claim succeeds.

Ownership matters more than the wallet that created the request. A transfer preserves the request ID, timestamp, and FIFO position while moving the future claim right to the recipient. When the recipient is a contract, safeTransferFrom requires that contract to implement the ERC-721 receiver interface. A stale picture in MetaMask does not change the on-chain status.

Claiming ETH completes the exit

A Lido exit finishes only when the current unstETH owner sends the claim transaction and the WithdrawalQueue transfers reserved ETH to the selected recipient.

The contract exposes a single-request claim, a batch claim for several finalized IDs, and claimWithdrawalsTo for a separate recipient. Every selected request must exist, be finalized, remain unclaimed, and belong to the caller. Batch calls also use checkpoint hints, which the interface calculates without asking the user to interpret the queue's internal checkpoints.

An ERC-2612 permit removes a standalone token-approval transaction, leaving two state-changing exit calls: request and claim. A conventional approval adds a third call before the request. Keep enough ETH for the final gas payment, because the reserved ETH arrives only after that claim executes. Successful settlement burns the unstETH token and credits native ETH.

Match the exit route to the position's next use

The Lido native queue best matches an Ethereum position moving back to ETH without accepting a decentralized-exchange quote at the moment of exit.

Choose the queue when the claim can wait for FIFO finalization and the position already sits on Ethereum. Choose a swap when immediate execution outweighs the difference between the quoted output and protocol redemption. Curve supplies direct stETH liquidity. Aggregators such as 1inch, CoW Swap, and ParaSwap search routes across venues; each route still settles at its displayed market terms.

Network location is part of the decision. wstETH on Arbitrum, Base, or Optimism belongs to that network's bridge environment. It must reach Ethereum before direct interaction with the mainnet WithdrawalQueue. Once the asset is on Ethereum, the desired destination - native ETH later or a market-priced trade now - determines the cleanest closing action.

Worth knowing