转账之前先敲门：ERC-777 的操作员与收币钩子怎么改写代币交互

ERC-20 的转账是哑巴式通知：币进了合约，合约不会自动知道，只能靠轮询事件或者由发送方额外调用一个确认函数。ERC-777 想补上这块，它创建于 2017 年 11 月 20 日，仓库记录状态为 Final，在标准仓库里作为对 ERC-20 的扩展出现，后续被行业路线放弃并标记弃用。它的两个核心概念——操作员和钩子——仍然值得读，因为它们各自回答了今天依然在遇到的两个问题：谁能替我转币，以及合约怎么在收币瞬间做出反应。理解这两点的最佳入口，是把 ERC-20 的局限说得更具体：approve 加 transferFrom 的两步式授权既费一次手续费，又留下一个悬空的额度；收币合约要确认入账，要么让用户多发一笔调用自证，要么索引器每隔几秒扫一遍区块。777 的野心是在代币合约内部把这两件事各自收敛为一步。

操作员：介于本人和 approve 之间

ERC-777 的授权单位不再是某个金额上限，而是一个地址身份。持有者用 authorizeOperator 把某个地址设为操作员后，这个地址可以用 operatorSend 和 operatorBurn 支配持有者的全部代币余额，不需要逐笔设定额度；撤销用 revokeOperator，查询用 isOperatorFor。合约还可以声明一批默认操作员，所有持有者默认受其支配。这个设计把信任颗粒度做粗了：一次授权即全额支配，和 ERC-20 的按金额授权是两种风险模型。原文的 Sent、Minted、Burned 事件都带 operator 字段，审计一笔转账时可以区分执行者和所有者，这是 ERC-20 的 Transfer 事件给不出的信息。

钩子：让收币方在场

另一个机制是回调。合约若想接收代币，需要按 ERC777TokensRecipient 接口实现 tokensReceived 函数，发送方合约在转账时查询 ERC-1820 注册地址表，找到收币方登记的钩子地址并调用它；发送方一侧同样有 ERC777TokensSender 和 tokensToSend，可以在转出前被询问。send 与 operatorSend 都带一个 data 参数，发送时可以附带说明文字传给钩子，让收币合约知道这笔币是谁、为什么转过来。NFT 市场代收、自动兑换、订阅扣款这类场景在 2017 年就得靠这套机制，否则每个收币合约都得自己写轮询。

粒度与铸造销毁

接口里还有一个 ERC-20 没有的字段：granularity，规定代币的最小计量粒度，所有转账金额必须是它的整数倍，取值为 1 时退化为逐枚可分。铸造与销毁也被显式标准化：burn 允许持有者销毁自己的代币并发出 Burned 事件，operatorBurn 让操作员代做同一件事，总量变化因此不需要翻内部账务就能从事件流复原。配合带 operator 字段的 Sent 事件，一套合约的完整资金流水——谁执行、谁承担、何时增减总量——全部可以从日志重建，这正是 2017 年的索引器最缺的能力。

钩子的寻址与失败语义

发送方合约不会瞎猜收币方实现放在哪里。ERC-777 利用 ERC-1820 的全局注册表：任何地址（合约或普通账户）都可以登记自己实现的钩子管理合约地址，转账时代币合约先查注册表，再调用登记的 tokensReceived。这一层间接寻址解决了合约无法自改代码的老问题，但也引入新的依赖：注册表本身是链上一个已被广泛引用的合约。失败语义同样要背锅——钩子里的调用失败会把整笔转账一起回滚，收币合约的一段坏代码足以让整个代币的转账路径卡住某条支线，这与 ERC-20 转账和确认互不拖累的松耦合是两种哲学。

它为什么被放弃

ERC-777 的失败原因在原文的兼容性讨论里就有线索：钩子把一次调用变成两次跨合约执行，重入面扩大，Gas 上升，而且 ERC-1820 注册表本身是一个全网单点依赖。更关键的是生态选择——钱包和交易所对兼容 ERC-20 的转账路径做了深度集成，任何改变回调语义的代币都要求下游全量适配。最终行业把需求拆开解决：批量和代付走向 ERC-4337，授权细节走向 EIP-712 签名和 EIP-2612 类扩展，收币通知靠事件索引成熟解决。对今天的读者，ERC-777 的提醒很实际：凡是把一次授权变成全额支配的设计，看清 operator 字段和默认操作员名单再动手；凡是声称转账即触发回调的协议，先确认回调实现在哪条链上、失败时转账是否回滚。

本文为机制说明，不构成任何投资建议。