sUSDe 冷却已结束却没收到USDe：核对已有请求、Silo与领取回执
链小知 · 进阶 · 核验 · 依官方文档整理
按cooldownAssets/cooldownShares和unstake字段区分等待、重新计时、可领取与最终收到USDe。
开始前准备
- 已有本人或获授权的sUSDe退出记录：网络、合约/ABI版本、请求调用者、方法及输入、成功/失败回执与同一部署cooldowns字段快照。
- 只排查已有记录；不创建冷却、不修改权限、不调用Silo、不申请机构赎回或签名交易。
1. 先固定退出产品、网络与方法输入
匹配Ethereum sUSDe staking身份与已有请求目标。固定V2的cooldownAssets(assets)输入USDe资产原始量并返回所需shares；cooldownShares(shares)输入sUSDe份额并返回assets。不能把两者输入相同数字就当相同退出数量。
这两个方法以msg.sender为请求owner，不接受receiver参数。已有调用经智能账户/协议合约发出时，按实际调用者定位cooldowns，而不是只拿外层发交易钱包地址。USDe机构redeem与sUSDe冷却是不同合约过程。
检查结果：得到请求owner、实际方法和输入单位；外层sender与冷却owner差异有记录。
2. 确认请求已结算进 Silo，而不是已到钱包
在成功请求回执中核对烧毁shares及Withdraw记录：固定实现将USDe资产转到绑定Silo，receiver是Silo，尚不是用户最终收款地址。把已结算underlyingAmount与仍持有的sUSDe份额分别列出，避免双计。
没有成功回执或只有网页倒计时，不直接判为请求成立；cooldowns字段缺失与真正underlyingAmount=0分开。进入Silo的部分已经结算为USDe，不能继续当仍在staking金库中的份额累计其后奖励。
检查结果：请求成功、结算USDe量、Silo接收和剩余份额能对应；等待余额未当已收款。
3. 核对结束时间及追加请求是否重设
读取已有快照中的cooldowns(owner).cooldownEnd和underlyingAmount，分别是Unix秒时间和USDe资产原始量。固定V2每次成功冷却会将结束时间改为该请求区块timestamp+当时cooldownDuration，并把新增assets累加到旧underlyingAmount。
因此追加请求可能让整笔待领取量重新等待。当前duration的非零修改本身不重写旧请求时间，不能用今天天数替代已存cooldownEnd；若记录显示结束时间变化，先对照后续成功请求而非认定第一笔失效。
检查结果：使用最后成功请求及匹配快照的结束时间，金额累加与时间覆盖分别解释。
4. 按已有部署状态判断等待与可领取边界
将cooldownEnd与同一部署已保存可信区块timestamp比较。固定unstake允许timestamp>=cooldownEnd，或cooldownDuration已为0；反之会报InvalidCooldown。电脑UTC时间或网页倒计时只能辅助，不能代替链上检查时点。
固定构造赋值90天是初始代码默认/上限，旧Github Overview写14天，2026年3–4月治理论坛报告描述1/3/5/7天动态模型。这些分别是代码/历史正文/框架报告，都不是本次请求当前天数。没有当前状态证据时结论保留未知。
检查结果：等待/满足代码时间条件/未知分开；没有把历史或构造数字宣称为当前承诺。
5. 核对已有 unstake 回执和最终接收人
达到时间条件不自动发送USDe。固定unstake(receiver)使用msg.sender名下cooldowns，全量取underlyingAmount后清零，再由绑定Silo把USDe发给receiver；没有分次领取参数。Silo.withdraw仅允许staking vault调用，用户的直接Silo调用不是此流程。
若已有领取回执，核对实际caller、receiver、USDe转账与金额，以及之后请求记录清零；清零快照或前端“已结束”单独都不能证明预期地址已收到。没有领取回执则保持“满足时间条件/领取状态未证实”，不重复发请求测试。
检查结果：完成必须有对应成功领取和正确USDe接收证据；时间已到与到账分别标注。
6. 将方法错误、权限与机构赎回限制分开
已有ExcessiveWithdrawAmount/ExcessiveRedeemAmount分别对照assets/maxWithdraw和shares/maxRedeem；OperationNotAllowed可能是cooldown开关与方法不匹配，或FULL角色相关限制，不能仅凭同名错误确定一种原因。固定MinSharesViolation约束非零总份额至少1×10^18，不是要求每个用户至少留1份。
旧正文对SOFT退出限制与固定_withdraw只查FULL存在差异；按当前部署/角色记录确认，不建议绕过。直接USDe赎回的白名单、每块限额和对手方要求与Silo领取不同；二级市场卖出另受价格/费用影响。任何费用/权限快照缺失都单列，链费不因请求失败自动为零。
检查结果：每项错误对应方法、单位和版本证据；地区/权限/费用未知不被替换成保证或规避步骤。
怎样确认完成
- 用既有证据明确请求是否成功、等待截止、是否追加重设、领取是否成功及最终接收人。
- 全部为文档核验，没有新请求、链上状态查询、资金领取或机构/API操作；无法证实的分支保留未知。
常见错误与边界
- 冷却期结束不等于自动到账；cooldownEnd=0或underlyingAmount=0须结合成功请求/领取记录解释。
- 追加冷却可能累加金额并重设账户结束时间；不能把它视为无影响刷新。
- 官方已归档源码和历史动态公告都未确认当前部署参数；不据其进行资金操作或承诺退出时限。