Plume Vaults：赎回在排队，怎样区分 pending 与可领取份额
链小知 · 进阶 · 核验 · 依官方文档整理
面向已有赎回记录，按链、资产与路径核对报价、pendingShares、claimableShares 和减少请求后的最终份额；构造交易并不表示已经领取。
开始前准备
- 准备已脱敏的 vault slug、链 ID、赎回资产地址、份额精度、user/controller 与已有请求或集成响应。
- 先核对 Nest 地区和条款资格；所列接口为官方字段说明，示例不能替代自己实际仓位的资产和地址。
1. 固定同一条赎回路线和份额单位
先列 vault slug、chainId、redemptionAsset、user/controller、shareTokenAddress 与 shareDecimals。shareAmount 是份额的原始整数串，不是稳定币 UI 金额；例如只有在 shareDecimals 已核为 6 时，1000000 才是 1 份额。
Redeem API 的 redemptionType 可为 atomicQueue 或 nest；新请求省略时使用 vault 默认值，而 pending/update 可能先选已有遗留 AtomicQueue 请求。已知路径应在支持该参数的方法中保持显式一致；FACTOR 专题仅支持所述 NestVault 路径，不支持时应报告错误，不能静默换合约。
检查结果：链、vault、赎回资产、用户、份额精度与路径已成套记录，未把另一链或另一遗留请求混入。
2. 先判断等待的是哪一种退出机制
即时退出动用可用流动性，可能有通常 0.1%–0.5% 的 liquidity fee；排队退出等待底层变现，不收该即时流动性费，官方称资本持续计收益至结算，但不等于免全部费用或保证收益。
现行官方正文对多数中等规模请求写约一小时、许多策略 T+2 至 T+5，较大或缺流动性的请求更久，长期资产策略可达 30–90 天。这些描述不能代替所选 vault 当前估计，更不能只凭“redeem anytime”判定逾期。
检查结果：已记录即时或排队路径、具体 vault 估计及流动性条件，没有承诺统一到账期限。
3. 核对报价与构造请求，分别标记提交和结算
官方 POST /vaults/{slug}/redeem/quote 以 redemptionAsset、原始 shareAmount、chainId 及可选 redemptionType 报价。核对返回的 redemptionAmount/redemptionDecimals、feeAmount/fees、minPrice、deadline；报价金额不是已到账金额。
redeem/build-tx 还需 user，skipSimulation 默认 false。FACTOR NestVault 分支返回可能需要的 approve，随后是 requestRedeem；已有足够 allowance 时可省略 approve。拿到 transactions 仅是构造结果，已有请求是否已上链、之后是否结算须分开确认。
检查结果：报价、构造结果、原始请求是否执行与是否结算分列，不把 HTTP 成功或 approve 当成赎回到账。
4. 分别阅读 pendingShares 与 claimableShares
POST /vaults/{slug}/update-redeem/pending 的输入含 redemptionAsset、chainId、user 及可选路径，返回 pendingShares、shareDecimals 和所选 nestVaultAddress 等；它描述仍待处理的份额。
POST /vaults/{slug}/claim/pending 则返回 claimableShares，表示当前可领取份额。该 claim schema 没有通用 redemptionType 输入，不能自行添加并声称所有 AtomicQueue 请求都适用；需确认所选 NestVault 与 user/controller 对应。pending 为零不能单独证明稳定币已收到，claimable 也不是稳定币数量。
检查结果：已区分待处理份额、可领取份额和稳定币余额；遇到路径或用户不匹配时保留未知，不拼接两个请求的数值。
5. 减少请求时填写最终保留量
update-redeem/build-tx 的 newShareAmount 是减少后最终 pending 总份额，不是要减掉的差额，原始整数串格式；0 用于取消请求。若已核 pending 为 1000000、希望保留 400000，填写 400000，而非要减少的 600000。
核对 previousPendingShares、newShareAmount、shareDecimals 与 redemptionType。减少待处理量或取消请求不等于把基础资产退出到钱包；FACTOR 专题把更新定位在变成可领取之前，不能据此承诺已结算部分也能撤回。
检查结果：最终保留份额、原 pending、精度与路径一致；已领取或可领取部分未被当作普通 pending 任意减少。
6. 把可领取、领取交易和实际收款再分开
NestVault 的 claim/build-tx 以 redemptionAsset、chainId、user 构造 claimRedeem，skipSimulation 默认 false；FACTOR 专题称领取该 vault 与用户当前全部 claimable shares。它不是让用户任填稳定币金额的通用提款接口。
若已有领取记录，核对其目标 vault、实际执行、对应资产到账及剩余 pending/claimable；仅拿到交易或 claimableShares 大于零仍不能宣布到账。美国等受限地区和直接合约交互的资格限制仍适用，不因找到 API 或合约路径而消失。
检查结果：已列可领取份额、领取构造或执行证据、实际资产到账与剩余请求；缺收款证据时明确仍未确认。
怎样确认完成
- 已得到同一请求的路径、单位、待处理份额、可领取份额与实际收款分项结论；官方方法已核，实际账户资格和赎回结果未验证。
常见错误与边界
- 从原 Nest 更名推断必须迁移或重新存款；官网称原仓位延续。
- 混用 AtomicQueue 与 NestVault，再把 pending=0 当已到账。
- 把 newShareAmount 当减量、把 claimableShares 当稳定币金额。
- 把通常的流动性费率或等待窗口推广至所有 vault、链与请求。