版税声明的公共查询台：Royalty Registry 与 Manifold 共享合约的分层

注册表想解决的两件事

Manifold 文档对 Royalty Registry 的定位写得很直接：一是让市场更容易使用正确的链上版税配置，二是让原本不支持链上版税的合约也能补上声明。站点和合约都开源，由 Manifold 与 Coinbase、Foundation、Makersplace、Nifty Gateway、OpenSea、Rarible、SuperRare、Zora 等平台共同推动，各网络的官方部署地址列在 royaltyregistry.xyz 上。

理解它的最好方式是把它当成”查询中间层”：合约里自己声明的版税（ERC-2981 的 royaltyInfo，或平台侧配置）仍然在各处，注册表提供一个统一入口把这些配置读出来，并在合约本身没实现标准接口时，用链下登记的数据代为回答。

共享合约模式下版税住在哪

Manifold 的 Creator Suite 是共享合约模式的代表：一批项目方共用一套部署好的 ERC-721/ERC-1155 合约（Creator Core），每个项目有自己的创作者空间。这种结构里，版税配置不住在”你的合约”里——合约只有一个——而是住在共享合约的项目配置和注册表里。创作者在 Manifold 界面改版税，改的是这套配置，市场通过注册表或标准接口读到的是同一个值。

这和每个项目自己部署合约的模式形成对照：自有合约的项目，版税字段、可否修改、由谁修改都写在自己的代码里；共享合约项目则要把”平台层配置”和”合约层声明”分开看。

查到的声明和到手的钱是两回事

注册表回答的是”声明了多少版税给谁”，不回答”成交时会不会被支付”。支付发生在市场撮合环节：市场愿意执行才扣，愿意执行多少扣多少。ERC-2981 本身没有强制力，这是行业常识；注册表把声明集中了，强制力仍然在平台政策那层。

所以完整的核验链条是三层：注册表或 royaltyInfo 的声明值；你打算成交的那个市场当前对版税的政策（可强制、可选、还是忽略）；以及订单里实际包含的费用分配项。三层都在文档和订单数据里，任何一层都查得到。

注册表查不到时怎么办

注册表里查不到一枚藏品，先分清三种情况：合约自己实现了 ERC-2981，数据就在 royaltyInfo 里，注册表只是转述；合约是 2018 到 2021 年那批老合约，既没实现标准也没人登记，平台只能靠内置的默认比例表兜底；第三种是共享合约模式下项目方还没配置，返回空值。三种情况的”版税”其实是三种东西——代码事实、平台政策、项目方意向。把注册表结果当成唯一真相，等于把第一类之外的情况都读错了。

一个查询动作的拆解

在 royaltyregistry.xyz 输入合约与编号后，返回结果通常带着来源标记：这条数据是从合约的 royaltyInfo 现场读的，还是来自登记数据。同一个数值两种来源的可信度不同——前者是合约代码事实，改它需要链上交易；后者是项目方自报，改它只需要再签一次登记。市场集成方大多把两种来源统一处理，但对愿意多花三十秒的人，回到 Etherscan 手动调一次 royaltyInfo 是成本最低的事实核验：一个 view 函数免费读，不需要钱包签名。查到的接收地址也值得顺手搜一下，落在知名金库或托管合约的版税，比一个从未在链上出现过的裸地址更像长期承诺。

三种查询方式各自的盲区

直接调 ERC-2981 接口：最贴近合约事实，但大量老合约根本没实现这个接口，查不到不代表没有声明。查注册表：覆盖了补挂的登记数据，但登记是项目方自报的，注册表不验证真伪。看市场页面的版税标签：反映该平台撮合时会用的值，换一个市场可能完全不同。

对交易者来说，比较稳妥的顺序是先查注册表拿到声明基线，再在目标市场的订单预览里确认实际分配，两处一致再成交。共享合约和注册表的实现细节以 2026 年 8 月文档为准。本文只解释机制，不构成任何投资建议。