比 approve 更硬的锁定：ERC-7246 Encumber 保留余额机制

要担保一笔履约，常见做法是把代币转进合约，条件满足再退回。ERC-7246 指出这里有个被忽视的代价：代币已经易主，空投、快照这些所有权附带的好处跟着跑了对手方；而只用 ERC-20 的 approve 又太软——额度只是“允许你转”，余额随时可能被主人自己转走。Encumber 是第三条路：不动所有权，给对手方一份“这部分一定拿得到”的硬承诺。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Review，2023 年 6 月 27 日创建，依赖 ERC-20。

两条余额，一张预留网

接口有四个查询与动作加两个事件。encumberedBalanceOf(owner) 返回某账户当前被预留的总额，规范立了一条铁律：它永远不得超过 balanceOf(owner)，任何会使余额跌破已预留额的函数调用必须回滚——这句是给所有兼容 ERC-20 的转账路径下的硬约束。encumbrances(owner, taker) 查的是两个地址之间的预留额度。动作侧：encumber(taker, amount) 由所有者把自己的部分余额预留给出价方，若“余额减已预留”不足 amount 则直接回滚；encumberFrom 允许被许可账户代做预留；对手方则通过 transferFrom 兑现权利，或用 release 主动放弃预留。Encumber 与 Release 两个事件记录增减。

标准的担保语义在于“预留只被这两条路消耗”：要么对方转走，要么主动释放，账户主没有第三种方式悄悄搬走被锁部分。文本还点了一个安全副产品：想排干一个池子只需一笔转账，而要逐户转走被 encumber 的代币，Gas 成本高到足以劝退。

与 approve 到底差在哪

两者都叫“授权他人取币”，差别在约束方向：approve 约束的是对手方的上限，不约束所有者自己；encumber 约束的是所有者自己——预留存在期间，余额减预留才是可用空间，转账、支付、被扣减都会受到余额校验的连锁限制。于是它适中的场景也更具体：不需要真正转移资产、但需要“到时候一定拿得出来”的保证，比如履约押金、订单担保、协议间的债务确认。标准明确说接口可平移到 ERC-721 等其他标准，一枚 NFT 可以被预留而非转走。

参考实现里的三条硬规则

把代码层的关键约束摊开看。其一，encumber 的前置校验写成“余额减去已预留必须大于等于本次额度”，也就是同一账户可以把余额切成多份分别预留给出价方，但任何一份都不会和其他预留互相透支。其二，encumberFrom 在参考实现里检查调用者对 owner 的 ERC-20 allowance 是否足够——第三方代做预留时，传统的 approve 仍是授权来源，两套机制在这里并联而非互斥。其三，release 只能由 taker 本人调用减少自己拿到的预留，owner 想单方面收回预留，标准文本没有提供第三个函数，设计意图就是把“说话不算数”的路径焊死。把这些规则连成一句话：encumber 是对所有者自己更严、对对手方更有利的约定，它把担保的代价从“质押物易主的权利折损”换成了“自己账户可用余额的实时缩水”。也正因如此，它特别适合与 ERC-721 的授权体系对照记忆——approve 管额度、encumber 管余额，一个防超支、一个防挪用，问题域不同但都是“让承诺有牙齿”；而要让牙齿真正咬合，部署前还得确认代币合约在所有会减少余额的自定义路径上都执行了预留校验，这类边界测试是审计此类扩展时的第一道题；把同一套断言在部署脚本里固化成回归用例，比任何口头承诺都更接近“承诺有牙齿”的本意。

给读者的核对提醒：Review 状态意味着它还在校稿，采用面很小，任何自称支持 ERC-7246 的合约都要以源码为准逐条验证“必须回滚”条款是否真的覆盖了全部转账路径——最典型的实现漏洞是在 burn 或自定义扣减函数里漏掉预留校验，让铁律名存实亡。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。