ERC-7564：智能合约钱包管 NFT，把 approve 拆成三个层级

大多数 NFT 被盗剧本里都有一环：用户对某个合约点了 setApprovalForAll，整个合集一夜清空。ERC-7564 盯住的就是这个结构性缺口——它把 NFT 授权从”外部账户一把全放”改写成智能合约钱包里的可编程模块，授权可以按单枚、按合集、跨合集三个粒度设定，还能附带策略条件。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案处于 Draft 状态，2023 年 11 月创建，依赖 ERC-165。

七个函数，三种半径

规范的接口是一组以 nft 开头的函数：nftApprove 对单个合集里的单枚代币授权某个操作者，相当于 ERC-721 的 approve；nftSetApprovalForOneAll 把授权半径放大到一个合集的全部代币，相当于 setApprovalForAll；nftSetApprovalForAllAll 则跨钱包内所有 NFT 资产放行某操作者——这是接口给得最狠的一档，正常情况下应当谨慎使用。查询侧有对应的 nftGetApproved、nftIsApprovedForOneAll、nftIsApprovedForAllAll，执行侧提供 nftTransfer 由钱包代为转移。

真正让它区别于普通 ERC-721 的是”钱包有代码”这件事：合约钱包可以在这些函数上叠加规则——超过某个 tokenId 范围的转移动作拒绝、非白名单操作者拒绝、每自然日转移数量封顶。这些条件逻辑不在 ERC-7564 规范之内，是各家实现的自由度；规范只保证授权状态本身以统一接口可查。

与 ERC-4337、模块机制的关系

规范文本把自己定位为可搭在 ERC-4337 账户抽象之上、或作为钱包插件存在的能力。理解这一点很重要：ERC-7564 不改变 ERC-721 合约本身——市场与合约仍然看到标准的 approve 与 setApprovalForAll 调用，只不过发起方是持有你资产的那份合约钱包，由它在内部决定批不批。对手方协议无需升级就能兼容，钱包侧的策略能力则是加分项。

与裸用 EOA 相比，安全模型有一个本质差别：私钥失窃意味着签名权整体失窃，任何前端界面都能引导资金流向；合约钱包下，即便某个钓鱼前端骗过了一个签名，转账仍要穿过钱包合约自己设定的规则。但这句”即便”的前提是规则配置正确——一个把 nftSetApprovalForAllAll 随手打开的合约钱包，与不设防毫无两样。

被盗叙事里的对照组

回看几起流传较广的合集失窃事件，攻击链条几乎同构：钓鱼页面诱导用户对伪装合约签一次批量授权，随后攻击者用一笔交易按授权扫走全部 NFT。合约层面看，每一步都是”合法”调用——授权事件正常发出，转移事件完全合规，区块浏览器只记录事实不判断意图。ERC-7564 类结构在此类剧本里的价值在于把攻击面切短：钓鱼前端骗到的是一次签名，而不是自动生效的全集放行；转账要过钱包合约的策略层，策略里若配置了”单次转移数量上限”或”操作者白名单”，扫货交易就会卡在其中一环。这不是理论推演，而是把”防钓鱼”从用户注意力问题部分转化为代码配置问题的工程路线。

反过来也要诚实：对已经习惯 EOA 加硬件钱包、从不点批量授权的用户，引入合约钱包未必是净收益——多一层合约就多一层实现风险与管理员密钥问题。安全结构的选择应当基于自己的操作习惯，而不是流行度。

用合约钱包管 NFT 的日常清单

第一，把三种授权半径当成三种不同的钥匙区分对待：日常交互只开单枚级，参与租赁或游戏等需要批量操作的场景再临时开合集级，跨合集全放几乎不应存在。第二，定期检查钱包模块列表：能修改授权逻辑的是钱包上挂载的模块与管理员地址，买合约钱包服务等于信任这些地址的组合，值得像核对项目权限一样核对一次。第三，保留人工兜底：策略类规则通常允许管理员绕过，管理员钥匙的存放（多签、硬件、恢复人机制）决定了整个账户的真实安全等级。

还要澄清一个常见误会：ERC-7564 不是让 NFT”放进”另一种账本，资产仍在原 ERC-721 合约名下，区块浏览器上的持有人地址就是那份钱包合约的地址。你的资产看起来属于一个合约而不是一个个人地址，这在合规申报、平台登记等场景需要提前说明口径。本文为机制与安全科普，仅提供防御性建议，不构成投资建议；提案状态以 ethereum/ERCs 仓库为准（核验时间 2026 年 9 月 9 日）。