ERC-1132 免托管锁仓：ERC-20 里直接按理由分格冻结

“锁仓”在代币经济里到处出现：团队份额按月释放、保证金按用途冻结、质押到期前不可动用。最常见的实现是把币转进一个锁仓合约再定期放币，用户从此多信一个合约、多学一套领取流程。ERC-1132 在 2018 年 6 月 3 日提出一个更朴素的替代：锁就发生在代币合约内部，不需要资金搬家。提案原文列了转进外部托管的六点顾虑：对托管方的额外信任、多一道转账授权、来回搬运的 gas 开销、到期还得记得去外部合约领回、用户难以追踪自己真实余额、以及锁定活动对用户不可见。这份提案状态 Stagnant，但”代币原生锁仓加按原因分格”的设计仍值得一读。

接口逐条读

核心函数 lock 带三个参数：一个 bytes32 的 reason（给锁定打用途标签）、数量与以秒计的时长，调用后对应数量在指定时长内不可转移。查询侧构成一套口径体系：tokensLocked 按地址与原因返回当前冻结量，tokensLockedAtTime 可查未来某时间点的冻结余额，tokensUnlockable 回答”现在已经可以解锁多少”，totalBalanceOf 一次读回某地址的冻结加可动总余额，配合 ERC-20 原本的 balanceOf 与 transferableTokens 思路区分”名义余额”与”可用余额”。写侧还有 extendLock 延长冻结期与 increaseLockAmount 追加锁定数量；到期后 unlock 释放，Locked 与 Unlocked 事件记录每次变动。注意 reason 是自由字节标签，同一地址可能同时在多个原因下各有一格冻结，各格独立计时——这既是灵活性，也是核对时必须问清”哪个原因”的原因。

与质押、时间锁的关系

提案自己也承认时间锁可用质押实现（它引用的 ERC-900 路线），并逐条解释了为什么要避免那种写法：质押转移产生真实转账事件，链上看起来像钱动了；而合约内锁定不产生转账语义，资产始终记在持有人名下，只是被状态机冻结。对用户而言，两类锁对钱包展示的冲击也不同——转进质押合约的币往往从钱包列表消失，合约内锁定的币仍在列表里但转不出去。评估”激励锁仓”类产品时，先分清它用哪种结构，再决定看哪个合约：前者的风险面在质押合约的管理员权限，后者的风险面在代币合约自身实现得是否规范。

reason 标签的自由度还带来一类容易忽视的运营型风险，值得点名。bytes32 原因值没有注册表，平台A用 DEPOSIT 的字节填充、平台B用带前缀的变体，同一地址在两种代币上被打了形似而实异的标签，用户用钱包或自建脚本汇总冻结资产时，按错误的原因键查询会得到零——不是没锁，是查错了格。认真的使用者应当把原因枚举写进文档并在事件里保持字节级一致；认真的核对者则应避免按原因查询，改用逐时间戳扫描 tokensLockedAtTime 与 totalBalanceOf 差值来穷举冻结，虽然笨重但不会漏格。另外留意 extendLock 的授权边界：能延长锁的一方是否等同于能提前解的一方，两者若同属一个管理员角色，“锁仓”对管理员就是单向透明的便利而非对等约束——把这两项写进任何锁仓集成或自研代币的验收清单，比事后翻事件流找异常要经济得多。

对 NFT 项目保证金场景的启示

NFT 平台与 DAO 常要收 ERC-20 保证金：作恶罚没、退出解冻。用 ERC-1132 式结构，保证金留在会员自己的代币余额里由平台触发锁定，罚没规则（哪些 reason 可被谁解锁、是否需多签）就必须在代币合约或配套治理里写清。核对顺序建议这样排：确认所用代币是否真有锁接口（多数主流币没有，需要找锁仓服务合约，那又回到托管模型）；读 lock 的权限修饰——谁能替别人锁、谁能替别人解；模拟一笔到期流程，验证 unlock 是否无需对方配合即可执行；把 tokensUnlockable 与网站显示的可提额度逐项对表。四个动作做完，“锁仓”才从形容词变成可验证状态。本文为机制说明，不构成任何投资建议。