Yearn V3 退出金额为何不同：核对份额、预览、损失限额与队列
链小知 · 进阶 · 核验 · 依官方文档整理
从已有金库配置、读取和退出回执区分 V2/V3、asset/shares 与真实 receiver；预览及最大额度不直接当作到账保证。
开始前准备
- 准备已有去敏 chainId、金库地址/实际版本、asset、owner/receiver、份额余额、读取区块/时间和退出输入及回执；缺项保留未知。
- 仅盘点已有资料与官方方法，不连接钱包、查询链或提交退出。固定 Vault 3.1.1 和 Strategy 3.1.0 仅解释参考，不能替代原部署 ABI。
1. 先确定金库家族与实际地址
从原仓位记录分列链、金库地址、资产地址与版本。V2 的策略不能直接被用户当 V3 独立金库存取；V3 Allocator Vault 可分配给多个策略，而 Tokenized Strategy 自身也是 ERC-4626 金库，可被用户或多个 Vault 持有。
对照 V3 地址页的具体版本，不把 Vault original、VaultFactory、TokenizedStrategy implementation 当个人仓位地址。该页最高列3.1.0，本文固定 Vault 源码标3.1.1；原记录未证该版本时只保留差异。
检查结果：产品类型、仓位地址与参考版本分开，未把同符号当同金库。
2. 分开底层资产与份额单位
把 balanceOf(owner) 记录为 share 原整数，把 asset 与对应 decimals 记录为底层资产；convertToAssets(shares) 是换算结果，不能把份额余额直接写成可提 USDC 或 ETH。固定 Vault 初始化采用 asset decimals，但原部署仍需其自身记录。
需要准确原整数时优先保留 convertToAssets/convertToShares 的已有返回，不用网页 pricePerShare 小数倒推；官方说明 pricePerShare 精度有限。读取时点不同的余额和换算不得相乘混算。
检查结果：份额、asset 与精度来自同一金库和时点，展示金额与原整数都保留。
3. 区分退出输入与返回值
逐项抄原 withdraw(assets,receiver,owner,...) 或 redeem(shares,receiver,owner,...)：withdraw 输入是资产、返回烧掉的份额；redeem 输入是份额、返回实际资产。receiver 与 owner 可以不同，钱包未增余额时先检查接收目的地。
previewWithdraw(assets) 向上换算所需份额，previewRedeem(shares) 向下换算资产；固定 Vault 的这些函数只做换算，未执行策略退出、损失及 hook。已有 preview 不等同成交净额或最终到账。
检查结果：输入/返回单位与 receiver 明确，预览未被当作成功回执。
4. 核对max函数及实际损失限额
核原输入是否显式有 max_loss/maxLoss。单位为 bps：10000=100%，1=0.01%；省略参数时 withdraw 默认0，redeem 默认10000，不能把二者都解释成零损失退出。
Allocator Vault 的 maxWithdraw/maxRedeem 也应与相同 owner、损失限额和队列配套。固定 _max_withdraw 会追踪未实现损失但返回名义额度，不保证相同净到手数；官方代码例子的100债务/10损失可能实际取回90。Tokenized Strategy 的匹配 maxLoss 重载在固定实现中忽略该参数，不能推其 max 已替实际执行审核损失。
检查结果：损失单位、默认值和具体产品重载都已标明，max未当净到账承诺。
5. 还原实际提款队列及限制
多策略金库把原 strategies 有序地址数组与 get_default_queue/use_default_queue 对照。数组最多10项；use_default_queue=True 时自选队列会被忽略。重复策略或顺序不正确可使 max 估算不准确，不能从一次 max 输出证明队列合理。
参考旧生成方法页的 withdraw_limit_module，与固定3.1.1的 withdraw_hook 分列，不互换名字。最新固定实现 paused 返回 max=0；hook 可限制提款并在转移后调用，原地址是否采用这些配置仍以已有记录为准。
检查结果：实际队列、默认覆盖和版本限制可追溯，未知配置没有补成空队列或无限额度。
6. 按失败阶段保留原文
在已有失败记录中查 paused、inactive strategy、insufficient assets in vault、too much loss、insufficient shares to redeem 等固定实现分支；只有原版本匹配才用于定位，不把相似文字自动判成同一错误。队列耗尽与损失超过限额是不同原因。
sender 不是 owner 时还涉及份额 allowance；资产批准与份额批准不能混同。原错误为空或 ABI 不明就保留原返回与交易状态，不主动改高损失限额、不用第二笔退出试探。
检查结果：失败分类有原输入/版本支持，未从空错误推定余额不足。
7. 对照退出事件与已有接收记录
固定实现成功后 Withdraw(sender,receiver,owner,assets,shares) 中 assets 为实际送出资产、shares 为烧掉份额。比较原事件与 receiver 的已有资产记录，注意同区块其他交易或转账费用可能影响净余额；不能只看 share 减少。
若只有预览或待处理交易，结论停在估算/待定；有失败状态不标提取完成。最终表列名义换算、损失限额、实际事件资产、费用和接收记录，未有接收证据则到账待核。
检查结果：输入、事件、目的地址及接收阶段分列，完成标签有相应证据。
怎样确认完成
- 已形成同链同地址的单位、版本、参数和队列对照。
- 退出估算、失败或事件与实际接收证据分开，缺项列为待核。
常见错误与边界
- redeem 默认允许100%损失是接口默认值，不是推荐参数。
- 金库流动性、策略损失和接收钱包记录不同；利润锁定并不等于份额不能赎回。