ERC-5269 supportERC：让合约自己回答你支持那份标准的哪一版

买 NFT 前常说“用 ERC-165 探一下接口”，但 ERC-165 只认 4 字节的接口标识，遇到“这个合集除了 ERC-721 主行为外，还实现了那份提案的哪个可选扩展、哪个草稿版本”就无能为力了。ERC-5269 想把探测粒度从“接口”提升到“整份提案及其子行为”。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案状态为 Review，仍未定稿。

四个参数问出一张能力表

核心函数只有一个：supportERC(caller, majorERCIdentifier, minorERCIdentifier, extraData)，返回一个 32 字节的状态值。majorERCIdentifier 就是要问的提案编号，规范要求它落在 0 到 2 的 31 次方减 1 的范围内，超出范围的行为留白；minorERCIdentifier 是留给各提案作者自定义的子标识，比如 ERC-721 的作者可以用对字符串 ERC721Metadata 做哈希得到的值代表元数据扩展，也可以用它区分同一提案的不同版本；传 0 表示问主行为；caller 允许按询问者地址区分答复；extraData 按 ERC-5750 的惯例放在末尾给未来留扩展。状态值的约定很直白：对已定稿的提案必须返回对字符串 FINAL 做哈希的结果，未定稿则建议返回对字符串 DRAFT 做哈希的结果或作者在正文里声明过的自定义值，而返回 0 被严格定义为“不支持”。查询函数必须是 view，不允许改动任何全局状态。另外合规合约应当在建仓或升级时广播一次 OnSupportERC 事件，方便索引器被动发现能力清单。

对未定稿提案的诚实条款

规范里最值得注意的是这样一条：对任何未处于 Final 状态的提案，查询其支持情况时绝不能返回代表 FINAL 的哈希值，推荐做法是返回 0，调用方必须把一切非 FINAL 的返回值当作“未定稿”处理。这条等于替用户堵住了“拿草稿当定稿宣传”的话术：即使项目方声称自己“已支持某标准”，链上返回值也必须诚实到提案生命周期为止。

使用边界

与 ERC-165 同桌吃饭

ERC-5269 并不打算取代 ERC-165，两者定位不同：ERC-165 回答“你实现了这个函数选择器集合吗”，粒度是接口；ERC-5269 回答“你对这份提案整体及其子行为的支持程度与版本状态”，粒度是提案。一个务实的组合用法是先用 ERC-165 过滤明显不合规的合约，再用 supportERC 深挖可选扩展；对已经大量存在的旧合约，则不要指望它们会主动实现 ERC-5269——这类合约返回“未声明”本身就是信息，调用方应准备好回退路径，直接按行为探测处理，而不是把查询失败误读为“不支持该功能”。钱包厂商目前也没有把 ERC-5269 列入普遍支持，所以它更接近一种面向未来的自报家门机制：谁愿意多报一层能力，谁就多一分可发现性，但没人强制。理解这一点，才能既用得上它的诚实条款，又不被“我们支持 ERC-5269”的宣传话术带节奏。

一次真实查询长什么样

以常见工具为例：在合约浏览器的 Write 页找到 supportERC，caller 填零地址表示查询对所有人生效，majorERCIdentifier 填目标提案号如 721，minorERCIdentifier 填零表示主行为，extraData 留空，执行后返回一个 32 字节哈希。把该哈希与 keccak256("FINAL") 对照即可判定状态；若返回全零，则是明确的“不支持”。这套动作不需要写一行代码，也不需要合约作者配合改任何东西——它的价值在反面同样成立：读不懂返回值的项目页面，说明对方多半没接入这个标准，宣传里的“完全支持某提案”就要按无自证处理。

给市场与钱包的实用姿势是：先问 supportERC(caller, 5269, 0, []) 确认合约本身合规——按当前快照，该调用对合规合约应返回代表 DRAFTv1 的哈希——再问具体提案号。也要清楚两件事：第一，ERC-5269 自身还是 Review，实现方可以自愿采用，覆盖率无法与 ERC-165 相提并论；第二，“回答支持”不等于“实现正确”，任何自报能力都只是线索，关键行为仍要用模拟交易和已验证的实现去实测。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。