让智能合约钱包替你管授权：ERC-7204 的五个代币函数

ERC-20 的 approve 假设授权人是一个普通外部账户：谁的地址在调，额度就记在谁名下。智能合约钱包不是这样——它内部可能有一组持有人、一套策略规则，把额度账本放在合约地址上只是一个数字，体现不了“这个钱包内部是怎么决定要授权谁”的逻辑。ERC-7204 提出让智能合约钱包自己接管代币管理的接口层：授权、放行、查询都走钱包合约的程序化逻辑。提案在 ercs 仓库的状态是 Draft（草稿），创建于 2023 年 6 月 21 日，要求兼容 ERC-165，接口的 ERC-165 标识为 0xf73edcda。

五个函数各管什么

接口 IERC7204 定义五个函数和两个事件。tokenTransfer 从钱包往外转代币；tokenApprove(asset, spender, value) 对某个代币合约、某个支出者设定额度，语义上对应 ERC-20 的 approve——重复调用会覆盖旧额度；tokenApproveForAll 则是对支出者放行钱包管理的全部代币，对应 setApprovalForAll 的角色；查询侧是 tokenAllowance 与 tokenIsApproveForAll。事件方面，TokenApproval 带三个索引字段：asset（被授权的代币合约地址）、owner（钱包地址）、spender，外加额度 value；TokenApprovalForAll 记录 owner、spender 与布尔 approved。把 asset 放进事件索引是个容易被忽略的设计：任何人按代币合约过滤日志，就能审计某笔授权发生在哪个资产上。

和原生 approve 的关系

ERC-7204 不修改任何代币合约。代币侧的 allowance 仍然记在钱包地址名下——这个接口是给 dApp 和前端的一层“问法”：想知道这个智能钱包对某支出者的授权口径，不再猜某个 ERC-20 映射，而是直接调用钱包合约。合规合约必须实现 ERC-165 接口探测，因此 dApp 可以先 supportsInterface 再决定走哪条路。对 ERC-721/ERC-1155 资产，这个套路的价值更直接：把“要不要给市场放行整个系列”的决策收进钱包的模块逻辑（限额、时间锁、多人签核），而不是 EOA 上一键弹确认。

边界与风险

第一，这是钱包侧标准，代币侧是否识别这套授权语义是另一回事：如果 dApp 只按传统 ERC-20 授权流程走，看到的仍是链上映射值，两种口径要靠前端对齐。第二，tokenApproveForAll 的覆盖面和 ERC-721 的 setApprovalForAll 一样宽——放行全部资产的管理权，一旦支出者合约有问题，波及面是整个钱包，使用前应确认该函数在钱包内部是否受额外策略约束。第三，提案是草稿且公开实现有限，接到具体钱包时以它的合约与文档为准。

从事件日志审计一次授权

ERC-7204 的审计价值集中在 TokenApproval 事件上，因为它把 asset 地址放进了索引。对审计脚本来说这意味着：不遍历所有代币合约、只按事件主题过滤一次，就能列出一个智能钱包生命周期里发生过的全部授权——哪天、对哪个代币合约、放行了哪个支出者、额度多少。把这份清单和对应代币合约的 Approval 事件做交叉比对，还能发现口径漂移：钱包事件说有授权、代币侧映射却是零，多半是后来撤销过；反之代币侧还有额度而钱包事件早已取消记录，说明撤销没走完，正是该补刀的时刻。对个人用户，一个实用习惯是每季度按自己的智能钱包地址拉一次 TokenApproval 时间线，凡是不认识的 spender、或活动早已结束还挂着的 asset，都按“先查用途、再撤销”的顺序处理，比等到盗币案发了再翻历史高效得多。

顺带提醒事件口径的一个差异：ERC-7204 的 TokenApproval 把资产地址设为索引，而 ERC-20 原生 Approval 没有这个字段，做历史合并查询时两种日志不能直接拼在同一张表里。

顺带说明它与账户抽象的关系：智能账户的签名验证走 ERC-1271 与 ERC-7739，授权管理走 ERC-7204，两条线在同一钱包里并行工作，读接口清单时不要混为一谈。

给多人钱包或智能钱包管 NFT 与代币的用户，这个标准给出的方向值得留意：授权应当是可以带规则的决定，而不是一次性的裸签名。本文为机制说明，不构成任何投资建议。