Lido withdrawal NFT: check pending, claimable and received ETH

A Lido withdrawal NFT represents a request to receive ETH; it is not ETH already credited to your wallet. For an existing request on Ethereum Mainnet, identify its request ID, current holder and status. Then distinguish a pending request, an amount ready to claim and a completed payment.

If your stETH balance fell after a request but native ETH has not appeared, compare those stages before concluding funds are missing. This guide inspects public records. It does not submit a withdrawal, transfer the NFT or claim funds.

Read the request as a position in progress

Lido’s NFT explanation describes an NFT minted for a withdrawal request and burned after a successful claim. The NFT can move between addresses: its current holder, rather than necessarily the original requester, holds the right to claim.

Keep the request beside the transaction you already recognize. The staking tokens sent into that process and the request representing them are successive forms of the position. Do not list the old token balance as if those same tokens were still freely held at the address.

This is different from reading a wallet-held staking token’s rebase or wrapper conversion. Use the stETH and wstETH balance guide for tokens still held outside the request. A withdrawal request needs its own record even if a tracker shows no useful NFT value.

Match the contract, ID and current holder

Record Ethereum Mainnet, the full withdrawal queue contract address and the request ID. Verify the deployment using Lido’s official contract list reached independently, not a link inside an unexpected NFT. A collection name, picture or familiar token symbol is insufficient.

The request ID identifies an item within that contract. A wallet’s total NFT count does not identify this request or its amount. The NFT ownership guide explains why an individual ID matters.

For an unclaimed request, compare its recorded owner with the address you intend to inspect. If a service or custody contract holds the NFT, connect that record to the service’s separate claim information. A past transaction from your wallet is not proof that the NFT is still there. Do not move it just to make a wallet gallery look right.

Separate pending, claimable and claimed

Lido’s readiness guidance separates requesting from claiming. A ready state is a step in the process, not a completed wallet credit.

Record	What to establish
Pending request	It exists and has not been finalized
Finalized, unclaimed	Its reserved ETH can be claimed
Claimed	A claim completed; check its recipient
Failed lookup	The state remains unverified

The queue reference documents getWithdrawalStatus with owner, isFinalized and isClaimed. Its getClaimableEther read requires valid checkpoint hints and returns zero for requests that are not finalized or are already claimed. Read the flags alongside the amount; a bare zero cannot tell those cases apart. A query error is not a valid zero response.

The same reference allows a claim to send ETH to a specified recipient. After a completed claim, inspect that actual destination rather than assuming it was the original requester. The NFT is burned, so an ownership lookup can fail for a claimed ID; preserve the request history and status instead of interpreting the absent NFT as a fresh loss.

Here, finalization means Lido has finalized the withdrawal request. It is not the same label as Ethereum consensus finality. These records also do not establish an NFT sale price or a guaranteed future payout amount.

Reconcile one claim without adding it twice

Build a small record with columns for request identity, state, current holder, documented amount and observation time. Keep wallet-held tokens outside the request separate. Once a claim completes, replace the outstanding claim entry with the actual received amount; retain the claim as history rather than another asset.

For an invented accounting example, suppose an address has a finalized, unclaimed request showing 1 ETH available. Recording both a 1 ETH claim and 1 ETH as already received would incorrectly show 2 ETH. If the claim later sends 1 ETH to that address, with no other changes, the outstanding claim becomes zero and the received amount is 1 ETH. This example illustrates double counting, not a live request, exchange rate or promise that every requested stETH amount pays the same ETH amount.

A historical receipt also does not establish today’s balance. The recipient could have spent ETH afterward. Compare snapshots and later activity before adding a current wallet amount. The broader portfolio mismatch checklist helps distinguish missing coverage, stale records and pricing.

Finish a read-only check before deciding to act

This procedure follows documentation checked on 31 October 2026. It was not tested on a live wallet or withdrawal request for this article.

1. Identify the request. Save the network, verified queue contract, request ID and your known request transaction. Do not substitute a similarly named NFT.
2. Check current ownership. Match the recorded holder for an unclaimed request. If another account or service holds it, note that fact and the separate custody claim.
3. Read status and amount together. Record pending, finalized or claimed evidence and a dated amount where available. Use the documented inputs for read methods; leave unsupported or failed reads unknown.
4. For a completed claim, verify receipt. Match the claim record’s request ID, actual recipient, ETH amount and transaction or block. Inspect the destination’s current balance separately from the historical payment.
5. Reconcile the position once. Keep unrequested tokens, an outstanding claim and ETH already received in their correct states. Explain movements between snapshots instead of adding every screen’s number.

Withdrawal timing depends on queue conditions and protocol circumstances. A displayed estimate is not a universal deadline. This inspection does not require a signature, approval or recovery phrase. Claiming funds is a separate transaction decision with its own checks.

Your result should identify the request, its current state and the evidence for any ETH received. If an essential link is missing, label that part unverified. A familiar NFT image or a completed request transaction cannot fill the gap.