ERC-7887 取消申赎请求：异步金库里反悔的那一步怎么写

ERC-7540 把金库的存取款改成异步：你提交 requestDeposit，金库在你看不见的时刻处理，你再来 claimDeposit 领取。这套流程一直缺一块——请求交上去了，在结算之前想撤回来怎么办？ERC-7887（Cancelation for ERC-7540 Tokenized Vaults）就是给这个缺口写的扩展，把取消做成与申赎对称的标准动作。按以太坊 ercs 仓库的记录，提案状态为 Draft，创建于 2025 年 2 月 18 日。

Pending、Claimable、Claimed：取消也要走完整三段

标准给取消请求规定了与正常申赎同构的生命周期。以取消存款为例：第一步，用户调用 cancelDepositRequest(requestId, controller)，请求进入 Pending，金库把该 controller 的 pendingCancelDepositRequest 置满对应额度；第二步，金库在内部完成取消处理后，pending 标志归零、claimableCancelDepositRequest 增加，进入 Claimable；第三步，用户再调用 claimCancelDepositRequest(receiver, controller) 把资产拉回钱包，进入 Claimed。标准用强语气词写死了两条纪律：请求不得跳过 Claim 状态——就算取消和领取在同一区块里完成，也必须分别调用 cancel 与 claim 两个函数；金库不得把资产“推”给用户，一切领取都是用户主动 pull。同步型金库允许从 Pending 直接跳到 Claimable，但同样要两段式调用。还有一条交互规则：取消存款请求处于 Pending 时，新的存款请求被阻塞，requestDeposit 必须回退，取款一侧同理。

为什么设计得这么啰嗦：状态一致性与清结算安全

标准提醒 ERC-7540 的全部安全考虑对本扩展同样适用，实操上还有一对容易被状态机表格掩盖的角色分工：controller 是提交请求、由它发起取消并领取资产的主体，receiver 只是资金落点，取消与领取看的都是 controller 名下的状态位，把两者随手填成同一地址是集成新手常犯、但多数时候并不致命的错。时序细节也值得前端处理：Pending 期间新请求被阻塞的规则，意味着取消按钮应当做成条件禁用，否则用户会连撞几次看不懂的回退。清算周期长的金库还要看 claimable 值的更新时点，界面显示的待领金额只是缓存口径，链上真值永远以当场查询为准。

把这套扩展放回 ERC-7540 的大图景：异步金库解决了清算需要链下参与者的事实，代价是用户手上多了一堆悬挂请求，7887 补的是这块交互债。对集成方，升级路径并不轻松——四组映射意味着钱包界面要为每个 controller 维护待存、待赎、待取消存、待取消赎四个小账本，任何一格显示错误都会被用户当成资产问题。判断一个金库实现是否认真，有个快捷测试：同时发起一笔存款请求与它的取消请求，观察界面状态是否还能讲清楚每一分钱当前处在三段里的哪一段，讲不清的实现多半在状态机上有捷径。

对普通储户还有个务实建议：在长周期金库发起存取请求时顺手记下 requestId 与提交区块，之后无论是推进清算还是发起取消，链上查询都要靠这两个坐标定位自己的请求；界面不给这些字段的封装产品，透明度上要先扣一分。

两步式加阻塞规则看着繁琐，实际是给异步清算兜底。若允许一步取消并即时到账，金库就可能出现“取消与正常结算同时命中同一笔请求”的双重处理；pending 与 claimable 分离后，清算器与取消器操作的是同一组状态位，先到先改、后到看到的就是改后的值。阻塞新请求则避免同一 controller 的 pending 队列里出现“存一笔、撤一笔”的账目纠缠，防止索引器与金库内核对队列顺序理解不一致。用户在金库里的操作界面因此变复杂了：判断“我的请求到底是存款待领还是取消待领”，要查四组映射——pending 与 claimable 各两条，存款与取款各一对——光看份额余额推不出真实状态。检查一个接入 ERC-7887 的金库时，要点是验证它的 claim 函数确实在领取前检查 claimable 值、取消后确实拒绝新请求、且没有任何“自动退回”路径绕过 Claimed。状态机严格，账本才不会有幽灵。标准仍是草案，接口以仓库当前文本为准。本文为机制说明，不构成任何投资建议。