做减法的 NFT：ERC-7561 把 approve 全家从合约里删掉之后

绝大多数 NFT 标准扩展在“加法”：再加一个授权函数、再加一类回调。ERC-7561 的立场恰好相反——NFT 合约应该更简单，复杂的事情交给智能合约钱包去做。它据此从 ERC-721 里删掉了四个授权函数和一个安全转账函数，只保留余额、归属与转让。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2023 年 10 月 29 日创建，依赖 ERC-721，接口标识 0xc1b31357。

删除清单与理由

被删的是 approve、getApproved、setApprovalForAll、isApprovedForAll 和 safeTransferFrom。标准的论证分三层。授权类函数整体上移：ERC-721 的授权体系建立在外部拥有账户（EOA）没有状态与代码的前提上，而智能合约钱包有，授权判断可以按“用户级”在钱包侧实现，用户反而获得更灵活的控制，同时规避了 721 合约层授权被滥用的那类风险（无限 approve 正是 NFT 盗案的常见入口）。safeTransferFrom 的删除逻辑类似：想去访问对方的资产，正确姿势是访问对方自己的合约，而不是由 NFT 资产合约替接收方做“是否合约”的回调检查——接收检查的职责从资产层转移到账户层。

留下的核心接口只有四件

合规合约必须实现：Transfer 事件（from、to、tokenId 三个索引参数齐全）、balanceOf(address)、ownerOf(uint256) 和 transferFrom(address,address,uint256)。权限规则收敛为一句：transferFrom 的合法调用者来自合约钱包侧的策略判断，NFT 合约自己不再维护单枚授权和批量授权两套映射。

“前向兼容”这句话要读准

标准文本的措辞值得逐字品味：本 ERC 与 ERC-721 前向兼容，也就是说所有现存 ERC-721 藏品未来都能兼容这套新设计；而 ERC-721 对本 ERC 是后向兼容——反过来不成立。翻译成使用语言：一个只会 ERC-721 授权模型的市场，接一枚只有 ERC-7561 接口的 NFT 时，setApprovalForAll 根本不存在，撮合、质押、租赁等一切依赖合约层授权的服务都要改走钱包侧路径。这不是运行时自动补齐的兼容，而是生态迁移方向的声明。

站在 EOA 用户一侧再看一遍

假设你今天买下一枚只有 ERC-7561 接口的 NFT：想挂拍卖，市场先要求 approve，这个函数不存在；想进质押合约，setApprovalForAll 也不存在——除非市场按新模型改造成“经你的合约钱包签策略授权”再撮合，否则挂牌流程直接卡死。这正是标准设定的前提条件如此关键的原因：它赌的是智能合约钱包成为默认签名方式，让“访问对方资产先访问对方合约”成为肌肉记忆。在这个假设变成现实之前，ERC-7561 的合规藏品对普通持有人的真实体感就是“兼容性缺口”。另外两点冷知识：参考实现仍然保留了 totalSupply 的只读视图，说明总量统计并没有被减法误伤；标准把与 721 的关系写成单向——ERC-721 资产未来都能接进这套模型，反向不自动成立。评估一个新项目是否值得采用它，比“省 Gas 数字”更实质的问题是：你现有的钱包、市场、质押入口，有几家已经支持钱包侧授权模型？答案决定摩擦由谁承担。也提醒一句迁移节奏：智能合约钱包与账户抽象基础设施仍在铺开，把资产设计押在一个尚未普及的前提上，等于让早期买家替你承担生态成熟度风险，这与标准好坏无关，是时间错配本身的成本。

给读者的核对清单：评估一个采用 ERC-7561 的项目，第一问不是“省了多少 Gas”，而是“钱包支持吗”——它的前提是账户抽象足够普及，用户默认拥有可编程钱包；在 EOA 仍是主流签名方式的现实里，这类 NFT 与主流市场的摩擦会直接落在持有人头上。第二问是“授权语义由谁兑现”：钱包侧策略代码成为新的信任与审计边界，出问题时排查点从合约源码换成了钱包实现与策略合约。标准本身不承诺任何额外的资产安全。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。