ERC-5521 可引用 NFT：把藏品之间的关系写成链上有向图

一件作品致敬另一件作品、一个二创项目声明自己取材自哪个合集、一份资料引用了另一份资料——这些”关系”通常只写在项目介绍里，换个人讲就变味。ERC-5521 想解决的就是把这种引用关系变成链上可查询的结构：它给 ERC-721 代币加上”引用了谁”和”被谁引用”两个方向的记录，构成一张有向无环图。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准标注为 Final，依赖 ERC-165 与 ERC-721。

两个列表、一个时间戳

标准的核心是一组很朴素的数据结构。每枚 rNFT 维护两份名单：referring 列表记录”它引用了哪些代币”，referred 列表记录”它被哪些代币引用”。名单元素是”合约地址加代币编号”的组合，所以引用可以跨越不同的合集合约。除这两份名单外，还有一个按 tokenId 存储的 createdTimestampOf，记录这枚引用型代币铸造的时刻。

操作层面，实现合约必须提供 setNode 函数：铸造者或持有人为某枚代币设定它引用的对象集合，合约在写入本币 referring 列表的同时，反向更新被引用方各自的 referred 列表，并广播 UpdateNode 事件。查询侧则有两个对称的视图函数：referringOf 返回某枚代币引用了谁，referredOf 返回它被谁引用。

为什么强调”无环”

有向无环（DAG）不是修辞，而是这套结构能稳定查询的前提。如果 A 引用 B、B 又回头引用 A，那顺着”引用链”遍历的索引器就会打转，溯源分析也失去起点。规范在 setNode 的要求里明确禁止自引用（不能引用自己），并建议对重复项做去重检查；工程上，链上验证通常只能防住直接成环，多跳的深层环要靠索引端做图检测，这是读者评估某个 rNFT 工具可信度时要心里有数的一条。

跨合约引用带来另一个现实：被引用方是别人的合约，它可能升级、可能被证明是仿冒项目。你声明引用了某合集的 tokenId 42，只证明”你声称引用了这个坐标”，不证明该坐标上的资产有任何义务与你互动。引用关系是单向声明，不产生授权，也不构成合作背书。

这个结构适合谁

对创作者，rNFT 提供了一条比”在描述里@对方”更耐久的致谢路径：时间戳和引用边都进了链上事件日志，多年后仍可复原某件作品的引用谱系。对索引器和数据分析，被引用次数可以在一定程度上反映某个源头在创作网络中的位置，但把它直接当”质量评分”就是统计陷阱——刷图互引、营销互捧都会灌进同一张图。

从事件日志重建谱系的注意事项

除了直接调用视图函数，整张图还有一条更原始的还原路径：事件。每次 setNode 都伴随 UpdateNode 事件，载荷里完整带着这枚代币的引用名单和被引用名单的快照。索引器不需要信任任何中间数据库，遍历合约全部事件就能重建任意历史时刻的图结构——这也是 rNFT 相对”项目介绍里写致谢”的真正优势：致谢进了事件日志就与链同步，项目方改官网文案改变不了已上链的声明。

但事件流同样提醒我们区分”记录”与”事实”：事件证明某地址在某时刻做了某个引用声明，声明内容是否属实（比如”本作品构图取自某合集”是否构成事实描述）不在标准的保证范围内。把引用图当作一份带时间戳的公开声明集来读，结论会比较稳；把它直接读成”官方认可的衍生关系”，就超出了它能承载的东西。另一个工程细节是 createdTimestamp 按单枚代币记录，因此”先有原作后有二创”这类时序判断可以直接用时间戳交叉核对，省去了翻铸造历史比交易顺序的麻烦。

对普通持有人，核验路径是：打开合约，调用 referringOf 看这件二创作品声称的源头是否真实存在、是否真是官方合约下的代币；再调用 referredOf 看自己收藏的原作被多少下游引用。两个方向都查完，比听任何一方的宣传文案都可靠。本文为机制科普，不构成投资建议；标准文本以 ethereum/ERCs 仓库为准（核验时间 2026 年 9 月 9 日）。