Lido 退出排队后能领 ETH 了吗？按 requestId 核对可领取状态
链小知 · 进阶 · 核验 · 依官方文档整理
针对已有 stETH/wstETH 退出请求，查询 NFT 所有者、定稿与领取状态，并解释队列期间收益和可领取金额的区别。
开始前准备
- 已有退出请求 ID、提交交易、网络及当前 unstETH NFT 所有者地址。
- 适用于 Lido 核心 WithdrawalQueueERC721；stVault DeFi Wrapper 使用不同队列与角色，需查对应文档。本教程只读，不请求退出或领取。
1. 确认是协议退出还是市场卖出
先查看原记录是提交核心退出队列，还是通过 DEX 卖出 stETH/wstETH。只有前者会对应队列请求及 unstETH NFT，不能拿兑换成交时间解释队列等待。
从官方合约文档的部署入口定位同一网络的 WithdrawalQueueERC721，记录提交交易与每个 requestId。较大的退出可能拆成多条请求，要逐条保存。
检查结果：已确定队列类型和合约，requestId 列表完整。
2. 读取当前请求所有者
按地址可读 getWithdrawalRequests(owner)，按 ID 可读 getWithdrawalStatus([requestId])。保存每条请求的 owner、timestamp、amountOfStETH 与 shares。
unstETH NFT 可以转让，最初提交退出的钱包不必是现在有领取权的钱包。若旧地址列表找不到，回到原 requestId 查当前 owner，不先断言请求丢失。
检查结果：请求 ID 能对应到当前 owner，而非只看原发起地址。
3. 用两个布尔值判断阶段
isFinalized=false 表示尚未定稿；isFinalized=true 且 isClaimed=false 才是可领取条件；isClaimed=true 表示已经领取，不能再次领取。
保存原始字段，避免只看 NFT 图片的文案。NFT 元数据可能随定稿更新，但图片不是替代合约状态的证据。
检查结果：每条请求明确归入等待、可领取或已领取，并保留原值。
4. 等待时看实际条件而非固定天数
定稿由 Accounting Oracle 报告及可用 ETH、等待条件等因素决定。官方文档没有把所有请求的等待时间保证成一个固定天数。
队列中的锁定 stETH 不继续给该请求累计质押奖励，且定稿金额还有相应风险条件。不要用钱包以前的 stETH 年化收益推算排队期间一定会多拿多少 ETH。
检查结果：等待结论保留状态与观察时间，没有承诺到账期限或排队收益。
5. 查询可领取的实际金额
需要精确数量时，按官方读取流程取得 checkpoint hints，再调用 getClaimableEther(requestIds,hints)。未定稿或已领取的请求可能返回零，这两种零的含义不同。
wstETH 提交后的请求金额以 stETH 口径记录，不能把 wstETH 原数量直接当 ETH 领取数量。核对返回值单位与请求状态后再解释差额。
检查结果：金额读取包含 requestId、hints 依据、单位和状态；零值的原因明确。
6. 已领取时核对真正的接收记录
若 isClaimed=true，沿领取交易查看成功回执、接收地址及 ETH 转移。领取会销毁对应 NFT，因此钱包不再显示 NFT 并不必然表示资产异常。
若状态仍可领取，记录为流程尚有领取阶段，不把按钮存在当成已经领取。本教程不点击领取或发起交易；后续执行应由当前所有者自行核对。
检查结果：已到账结论能同时定位请求状态与成功领取交易。
怎样确认完成
- 每个请求的 owner、定稿和领取状态已记录。
- 可领取数量和原 wstETH/stETH 数量按正确口径核对。
- 到账结论附成功领取证据或明确待领取阶段。
常见错误与边界
- 把 DEX 卖出与协议退出队列混为同一流程。
- 将 isFinalized=true 直接写成已领取。
- NFT 转让后仍用原地址判断领取权。
- 把可领取零值都解释成亏损。
- 套用 stVault Wrapper 的 operator 队列流程到核心 stETH 队列。