ERC-8034 可引用版税：版税沿引用关系分发，与 ERC-2981 有什么不同

谈 NFT 版税时，大多数讨论停在 ERC-2981”每枚代币声明一个收款地址和比例”。但创作协作经常不是一对一：二创作品想给原作作者分账，原作又引用过更早的素材，一条链上关系背后站着好几层贡献者。ERC-8034 就是针对这种结构提出的版税分发标准——它不修改 ERC-2981，而是配在 ERC-5521 可引用 NFT 旁边使用的一套独立接口。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准标注为 Final。

规范规定了什么

ERC-8034 引入两个数据结构。RoyaltyInfo 是一个收款地址加上一个金额（按售价查询时单位为 wei，按固定查询时单位为基点）；ReferenceRoyalty 是若干个 RoyaltyInfo 加上一个 referenceDepth——后者限定版税沿引用图最多向上传播几层，防止链条无限延伸。查询侧提供 getReferenceRoyaltyInfo，给定合约、代币（以及可选的售价），返回这一笔应有的收款人列表和各自金额；设置侧提供 setReferenceRoyalty，由有权者写入收款人数组、比例数组和传播深度，另有带签名的重载版本。成交发生并触发分发时，合约发出 ReferenceRoyaltiesPaid 事件，把合约地址、代币、买家、市场和版税结构一起写进日志。

标准文本明确两点定位：第一，它与 ERC-2981 相互独立，是并行存在的另一套声明渠道；第二，它期望配 ERC-5521 的 rNFT 使用，实践中建立在 ERC-721 的所有权语义之上。

与 ERC-2981 的三个差异

第一，收款人数量。ERC-2981 的 royaltyInfo 一次只返回一个收款地址加一个比例；ERC-8034 一次返回的是一个数组，天然支持”创作组内多人分账”。第二，传播维度。前者的版税归属是那枚代币自己的属性；后者会沿着引用图走到上游代币的版税设置，referenceDepth 决定走多远。第三，查询语义。前者回答”这枚代币声明多少版税”，后者回答”这笔交易应该拆给谁、各多少”。

但两者共享同一个现实约束：版税是自愿机制。规范管的是”怎么声明、怎么查询”，钱到不到账取决于市场是否在结算时调用这套接口并按返回值执行分发。没有市场配合，链上写得再漂亮也只是声明。判断一个支持 rNFT 的市场是否真付多层版税，看它的结算逻辑是否处理 ReferenceRoyaltiesPaid 对应的分发路径，而不是看项目页的标语。

持有人视角的检查清单

如果你打算买入一个声明”收益回流原作者网络”的引用型藏品，值得逐项确认：查询该代币的 getReferenceRoyaltyInfo，确认上游名单里确实有你认为该收到的地址；核对 referenceDepth，深度为零就意味着上游引用链完全不参与分账；留意收款比例总和是否为合理值，异常接近或超过百分之百的配置会直接吃掉全部毛利。另外，设置函数是否可由管理员随时改写，决定了这份分配承诺的稳定性。

还有一个容易被忽略的查询细节：规范提供两种形态的版税查询——带售价参数的版本用于结算时计算具体金额，不带售价的版本返回以基点计的固定比例。对账时这两个口径要分清：基点数值乘错分母，会把”百分之五”读成”百分之零点零五”，或者反过来被结算界面的小数字吓到。带签名参数的 setReferenceRoyalty 重载则意味着分配方案可以在链下协商、由持有人签名生效，流程上更接近”协议变更须双方签字”，审计时记得把签名事件的发起人与链上生效记录对应起来看。

也要避免一个常见误读：引用关系声明的是创作致谢，不是法律授权。版税分发结构不回答”原作是否授权二创”这个版权问题，两者不能混为一谈。同样的道理反方向也成立：某作品没有出现在任何版税名单里，不等于它与任何人的创作没有渊源，只是那条渊源没有用这套标准登记而已。本文为机制科普，不构成任何投资建议或收益承诺；标准文本以 ethereum/ERCs 仓库为准（核验时间 2026 年 9 月 9 日）。