跨合约认亲：ERC-7510 如何让不同项目的 NFT 互为父母

一张二维头像想发布自己的三维模型版，一部电影 NFT 想写明自己借用了哪三个角色 IP——这些“谁衍生自谁”的关系有个现实障碍：衍生作品往往是新项目、新合约，而 ERC-6150 的层次化关系只在同一个合约内部有效。ERC-7510 专门解决跨合约认亲，还允许多个父母。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2023 年 8 月 24 日创建，建立在 ERC-721 之上。

一把钥匙：带合约地址的代币指针

标准的根基是一个结构 Token，把合约地址和代币编号绑成一对，等于给链上任何一枚 ERC-721 造了个“全名”。在此之上接口给四件工具：parentTokensOf 返回一枚代币的全部父代币（一个 Token 数组，天然支持多父）；isParentToken 判断“另一枚（可能是别人合约的）代币是不是它的父”；setParentTokens 整体改写父列表；每次改写发 UpdateParentTokens 事件。就这么多——没有铸造、没有转移，它只维护亲缘簿。

为什么只记父、不记子

设计说明里这段推理值得完整转述：原作先于衍生品存在，铸造衍生品时当然知道父亲是谁；反过来铸原作时根本不知道将来会有哪些孩子。如果坚持双向记账，那么每铸一枚衍生品都要跑到原作的合约上补登记一笔子记录——两边不同合约意味着两套写权限，实操中根本无法合并进一笔交易。于是标准干脆只让衍生品单方面记父：查“父亲是谁”一次调用就够；查“孩子都有谁”则要靠索引器反查链上所有合约的 UpdateParentTokens 事件。这是个诚实承认代价的取舍：结构更简单，但子向查询变成了链下工程。

与 ERC-6150 的分工

两者命名刻意保持一致（parent、child 的叫法接近），但适用面不同：同一合约内的父子、需要子代币可回收（recycle）的场景，ERC-6150 的接口更顺手；一旦跨界——联名、二创平台、衍生集合独立发行——ERC-6150 无能为力，ERC-7510 才有存在意义。对看项目的人，先问一句“衍生品和原作在不在同一个合约里”，就知道该拿哪把尺子量。

持有人核验清单

把一次联名审计走完

用一件虚拟联名案例收尾：电影 NFT 编号 88 宣称吸收了 A 集合的 3 号与 B 集合的 77 号。核验第一步在电影合约上调 parentTokensOf(88)，得到两个 Token 结构——合约地址与编号的成对指针；逐指针检查：地址是不是 A、B 的官方部署（拿官网、官方社交账号、已验证源码三处交叉），编号在各自合约里 ownerOf 是否正常。第二步用 isParentToken(88, 指针) 做反向点验，排除“列表里有名字但关系位没写”的半吊子实现。第三步拉取 UpdateParentTokens 事件历史，确认父列表从铸造至今是否被 setParentTokens 整体改写过——被改写过就要问为什么，比如把某位联名方换成了自己的壳子合约。第四步跳出链上：登记簿干净，不等于片酬分成到账，许可协议的经济条款永远要单独读。四步走完，你对这件联名的了解就超过绝大多数围观者。另外给数据团队留一句备忘：因为接口只记父不记子，做“某角色被哪些作品引用”的反向看板必须自建事件扫描器，全链监听 UpdateParentTokens 并反向建索引，这活没有人替你干，也是评估一个衍生生态基础设施成色的快捷切面。

第一，亲缘数据本身不授权：setParentTokens 谁可调由实现者定，标准没给权限模型。因此“我的角色被某电影 NFT 登记成了父母”在某类实现里完全可能发生——对持有 IP 类权益的藏家，把 isParentToken 与自家合约的事件监控列为例行项是稳妥做法。第二，父列表是整体覆盖（set）语义，改一次全换一遍，历史只能靠事件回放，核对时把每一版列表都拉出来比。第三，亲缘登记不自动等于分成依据：谁从联名作品里拿多少钱属于许可协议层，链上只证明“关系被登记过”，不证明“钱按关系分对了”。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。