ERC-7196 极简代币：只留三个函数的 ERC-20 近亲

ERC-20 的六个函数里有三个是配套的：approve 设额度、allowance 查额度、transferFrom 代扣。这套授权机制撑起了交易所充值、理财合约、 NFT 市场的一切自动扣款，但也正是钓鱼攻击最常利用的入口——批出去额度，钱就随时可能被别人划走。2023 年 6 月 21 日创建、状态为 Draft 的 ERC-7196 做了一次激进的减法：这三个函数全删，代币接口只剩 totalSupply、balanceOf、transfer 三个函数。本文按原文拆这个极简实验。

删掉授权之后，钱怎么动

原文的抽象部分写得很直白：这份标准是基于用户合约钱包（包括账户抽象）设计的新资产形态，为了保持资产简单，删掉了 ERC-20 的 transferFrom、approve 和 allowance。接口定义就叫 IERC7196，三个函数各管一件事：查全币总量、查单地址余额、把指定数量转给某个地址。参考实现里每个函数都简单到几行。看上去这像一次开倒车，但设计逻辑立在账户这一侧：当发起转账的是一个合约钱包，事情可以反过来做——外部合约想动用资金，不再依赖代币合约里的预批额度，而是由账户抽象层在每笔操作里显式授权。授权状态从代币合约的公共账本，挪进用户自己控制的账户逻辑。

前向兼容的承诺怎么兑现

删函数的标准最怕生态孤立，ERC-7196 的回应是声称与 ERC-20 前向兼容。兼容的方式不是假装三个函数还在，而是让认识 ERC-20 的工具仍可查询总量与余额这两个只读函数，钱包与浏览器几乎零成本就能展示这类资产；区别只出现在写路径：涉及第三方代扣的场景需要账户层配合，代币合约本身不再提供预批通道。这个取舍的后果要两面读。安全侧的收益是实打实的：不存在一个可以被钓鱼话术骗着调用的 approve，公共授权表消失，经典授权盗币剧本在纯 7196 资产上失去舞台。代价同样实打实：大量默认按 ERC-20 写死充提逻辑的中心化系统，遇到这种只有三函数的合约往往直接拒绝支持，资产的可达性会收窄。

一次可组合性代价的自测

删掉授权对依赖“应用主动扣款”的那部分 DeFi 组件影响最直接：进金库、给交易所充值这类先批后扣的标准流程，在纯三函数资产上走不通，替代路径是交易时由用户的账户合约反向调用应用。换句话说，资产的简单是用账户的复杂换的，这笔账划不划算，完全取决于账户侧的普及程度——钱包默认还是外部账户，资产就寸步难行；智能账户成为默认，授权面反而更收敛。读者可以自己做一个验证动作：找该资产的一个入金或认领入口，观察钱包弹窗要你做的是“设置额度”还是“确认一笔带完整参数的操作”。前者意味着资产层面留着别人随时动钱的权利，后者意味着授权只发生在眼前这一笔。所谓删繁就简，在 ERC-7196 这里其实有个更准确的描述：授权半径被永久缩小到你刚刚签下的那一笔转账。

草稿箱里的实验品

按 ercs 仓库记录，ERC-7196 停留在 Draft，属于想法提案一类，它更大的价值是提出问题而不是给出答案：授权状态到底该由资产记账本维护，还是该由每个账户自己维护？ERC-4337 生态里账户侧的授权表达、ERC-6821 这类按代币调整授权的接口设计，其实都在回答同一个问题的不同侧面。普通读者从这份标准能带走的实用视角有两个：其一，每次被要求“批准额度”时先想清楚批的是不是无限期、无限量的动钱权利，这仍是今天最值钱的防身术；其二，一个代币接口越接近三函数极简，它的可编程流转就越依赖账户层是否聪明，资产好不好用不只取决于币本身，也取决于拿币的那只手是什么结构。

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