ERC-6229 带锁定期的金库：份额价格没定之前，存取款怎么排队

ERC-4626 金库的默认假设是”随时可存取”：存一笔资产，按当前份额价格当场铸份额；赎份额，按当前价格当场换回资产。但有些资产天生做不到随时定价——定期拆借的贷出资金、锁仓期的质押头寸、封闭式基金，在锁定期内你甚至说不清一份份额该值多少。ERC-6229 为这类场景给 4626 打了一个扩展补丁：锁定期内金库”关门”，存取款都变成排队意向，等价格能算了再统一结算。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2022 年 12 月 21 日。

isLocked 开关与四个调度函数

标准的扩展建立在两条底线之上：金库必须先完整实现 ERC-4626 与 ERC-20（份额本身就是代币）。在此之上加一个布尔视图 isLocked，声明金库此刻处于锁定期与否。锁定期内，4626 原来的 deposit、mint、withdraw、redeem 四个即时函数应当直接 revert——标准在兼容性一节写得很清楚，这是为了防止在份额价格未定时发行或销毁份额。取而代之的是排队函数：scheduleDeposit(assets) 把用户的资产收进金库但不发任何份额；scheduleRedeem(shares) 把用户的份额收进金库但不付任何资产。两者都只登记意向、不动价格。等 isLocked 变回 false，再由 settleDeposits(depositor) 按当前份额价格为排队的存款铸造新份额，由对应的结算函数处理排队的赎回。换句话说，整个设计把”成交”从下单时刻推迟到了定价时刻。

为什么没有”预约提取”函数

标准动机一节专门解释了一个看似缺席的功能：没有为提取做预约的函数并不奇怪——锁定期间份额价格未定，本来就无法回答”我这 100 份将来能换回多少资产”，任何预约报价都是假报价。因此预约接口只管存入侧的意向登记与份额侧的回收登记，两边都不承诺价格，价格统一由结算时刻的现货份额曲线决定。这种”宁缺毋滥”的接口取舍，是这份标准最鲜明的性格。

延迟结算埋下的价格错配

安全考量一节指出了这套机制最大的坑：未结算的排队订单。设想用户在第一轮锁定期结束前提交了 scheduleDeposit，但错过结算没有及时 settle；等第三轮锁定期结束后再补结算，金库会按第三轮的价格给他铸份额——而市场早已不是他下单时的市场。标准刻意不规定解决方案，只列举了实现者可选的思路，例如：只要还有未结算订单就不允许金库再次进入锁定，或者干脆让结算永远按订单进入的那一轮处理。对用户的直接含义是：在基于 ERC-6229 的金库提交订单后，解锁窗口内尽快完成结算动作，把订单留在系统里过夜，承担的是标准明说的价格错配风险。

轮次计数堵住的一个漏洞

标准还规定金库维护一个从 0 起算的 vaultRound 计数器：每当 isLocked 变 true 进入新锁定期就加一，其他任何时候不得改动。排队事件里也带上轮次编号，作用是给每个意向订单钉上”它许的是哪一轮的愿”。没有轮次，隔了几轮再结算的订单至少说不清该认领哪段行情；有了轮次，实现方至少有了按轮对账、给订单区分先后处理顺序的基础设施——前文提到的价格错配问题，第一块拼图就是这个计数器。

和定期存款的心理差异

银行定期存款到期利率写在合同上，链上锁定期金库的承诺则弱得多：你锁定的是”排队资格”，兑付数量取决于结算那一刻的资产账面价值。资金在锁定期内如何运用、份额曲线如何更新，标准同样不规定，只把 isLocked 一个开关留作接口。这决定了阅读它的方式：把它当”带封条的账本协议”而不是”理财产品说明书”，重点核对封条期多长、解封时按哪条价格线结算、自己的订单在哪一轮被处理。按 ercs 仓库口径，ERC-6229 停留在 Draft，采用金库不多，接口细节应逐项实测。本文为机制说明，不构成任何投资建议。