ERC-7401 取代 ERC-6059：可嵌套 NFT 修的是哪个接口号

一枚 NFT 的主人可以是另一枚 NFT

可嵌套 NFT 的核心设定一句话讲完：ERC-721 里 owner 通常是地址或合约，而嵌套标准把”另一枚 NFT”也承认为合法 owner。于是转账的动作变成”把子币发给父币”，子币随父币一起移动——父币卖掉了，挂着的所有子币整串跟走。规范举的四个典型场景很有代表性：把多枚藏品套成一个包裹一次售出（打包）、按喜好组织灵魂绑定凭证（收藏）、给会员币直接套发奖励币（会员）、把投票币套进受托人的币里（委托）。

这条路线的原始标准是 ERC-6059，2022 年 11 月 15 日创建、Final 状态。2023 年 7 月 26 日，同一批作者提交了 ERC-7401，同样 Final，并在摘要第一行声明取代（supersedes）6059。

一个补丁标准的诞生原因

7401 的动机章节罕见地坦白：功能上两者完全等价，改的只是一个错误——6059 在提案生命周期里接口演化时漏加了一个参数到接口定义里，而那个参数早已计入接口 ID。两者由此对不上号。对外的直接后果是 ERC-165 探测失灵：钱包或市场用 supportsInterface 查询某合约是否支持嵌套协议，合约按 7401 口径声明、工具按 6059 编号查询（或反过来），得到的都是 false，合约明明支持却被当成不支持。7401 因此把接口 ID 对齐到实际接口定义，并给出新的 ERC-165 标识符（规范注明为 0x42b0e56f）。

这就是”补丁式标准”的全部意义：不是加功能，而是让”能不能被自动识别”这件事重新为真。

为什么接口 ID 对普通持有人重要

嵌套关系的魅力和麻烦都在”自动”二字。钱包能枚举一个父币下挂着哪些子币、市场能把整个套娃打包出售、清算协议能顺着父子链估值——这些体验全部建立在合约可被探测、事件可被索引的前提上。接口 ID 错位时，这些工具对同一份合约会输出互相矛盾的结论：有的显示”有 3 个子币”，有的显示”空”。对读者的实操含义：遇到嵌套藏品显示不一致时，先确认合约实现的接口声明按 6059 还是 7401 口径，再看索引器适配了哪套；同一份合约在不同工具上表现不同，常常不是数据丢了，而是探测号段不对。

核对嵌套关系的最短路径

三层验证与一个常见误区

链上验证嵌套的最小闭环由三层组成：子币合约上的 parentOf 或等价查询回答”我现在属于谁”，父币合约上的 childrenOf 回答”我名下挂着谁”，而 Transfer 与嵌套相关事件回答”最后一次进出发生在哪笔交易、由谁发起”。三者一致时结论可靠；不一致时以事件历史优先，因为查询函数可能受合约实现细节影响，事件流是原始记录。常见误区是把”嵌套=安全保管”：父币是另一枚 NFT，而 NFT 的归属由地址私钥控制——私钥泄露时，整套套娃结构连同每一层一起易主，嵌套只是权限集中的一种形态。用它当”收藏保险箱”的设想，安全前提与把它当普通持仓完全相同：管好的始终是那把地址的钥匙。

与”同币多资产”路线的分野

顺带划清边界：ERC-5773 让一枚代币同时携带多种资产文件、ERC-5606 的多元宇宙把多版本装进同一编号，两者解决的是”一枚币内部装什么”；嵌套标准解决的是”一枚币归属于另一枚币”的跨合约关系。评估组合结构时先问属哪类——内部装装的组合不会随父币移动，嵌套的资产会整体搬家——把两者混为一谈是面板读数与预期不符的常见根源。

链上验证嵌套只需要三步：在子币合约上查 parentOf 类接口或等价事件（childProposed、transferredToParent 等），确认当前父币的合约地址与编号；在父币合约上查 childrenOf 枚举它的子币列表；沿传递事件回溯最近一次”套入或取出”发生在哪笔交易。要注意权限语义：按规范，子币由父币的所有者全权管理，任何人可发起提案（propose），但转移由父币 owner 的账户发出——这意味着你的子币安全等于父币地址的安全，父币私钥泄露时整套结构一起易主。嵌套带来的组合便利与集中风险是同一枚硬币的两面。本文为机制科普，不构成投资建议。