共享合约的版税开关：Manifold Fee Switch、注册表与市场政策三层账

共享合约改变的不只是部署方式

Manifold 的 Creator Suite 把”每个项目一个合约”换成”所有项目共用一套 Creator Core”：ERC-721 和 ERC-1155 的合约各一份，多个项目方在同一合约上以空间（space）为单位管理自己的藏品。版税话题在这里出现了结构性变化——不存在”你的合约里的版税变量”，配置被拆进了三个各有主人的层。

第一层：Creator 合约与开关

Creator Core 仓库里实现了 ERC-2981 接口，版税接收地址与比例按项目空间配置，只有对应空间的 creator 角色能改。仓库源码中的开关类函数（社区常称 fee switch）控制的是这个空间在标准接口上对外声明的版税去向与数值。要点在于权限边界：平台不能替你改，你也改不了别人的空间——共享的是代码，不共享的是配置。

第二层：Royalty Registry 补挂声明

Manifold 文档写明，Royalty Registry 的目的有二：让市场更容易读到正确的链上版税配置，让原本不支持链上版税的合约也能补上声明。它由 Manifold 与多家平台共建，注册表本身不产生版税，只做”统一查询门面”：合约没实现接口的，查登记数据；实现了的，转述合约。

平台费与版税两条线不合并

读订单时还要把两条费用线分开：市场平台抽自己的服务费（OpenSea 等按 Collection API 返回的 fees 结构在订单里加自己的 consideration 项），创作者版税走另一套接收地址。聚合器场景下两线可能来自不同主体——路由层收路由费、源市场收撮合费、版税归创作者。一笔成交页面上看到的”总费用”实际是三方各自的收费行，逐项拆开再判断是否合理，比看总数有用得多。

历史合集的空白格

大量 2021 年前的老合约既无 2981 也无登记，注册表对它们返回空。市场通常用内置默认表兜底（常见 5%），但不同平台的默认值不同——这正是同一枚老藏品在不同市场版税悬殊的原因。想推动某条历史合集的版税，唯一可靠路径是合约可升级且权限在创作方手里；否则任何”默认值”都只是平台善意，善意没有合约保障。

第三层：市场的扣款政策

声明归声明，扣款发生在市场撮合那一刻。平台愿意强制才全额扣（OpenSea 对部分合约类型走协议级强制，见其 creator fee enforcement 文档），愿意自愿就按订单写多少给多少，聚合器还可能只撮合不扣。同一枚藏品在不同渠道的”到手价差”就来自这一层。

一次改版税的完整动线

以共享合约上的创作者视角走一遍：在 Manifold Studio 的空间设置里改动版税接收地址或比例，触发一次链上交易写入 Creator 合约的配置；注册表读取时自动反映新值，无需重复登记。如果同一空间曾接入其他市场，那些市场如果读的是标准接口或注册表，会跟着变；如果读的是自己后台的静态表，就不会变——这就是”改完要在各平台分别验证”的原因。接收地址改成多签或金库合约是常见操作，链上转账测试一笔小额比直接切换安全得多。对藏家来说，这条动线也解释了为什么同一藏品在不同时期的成交记录里版税数值会漂移：漂移本身不是异常，读得到修改记录才是共享合约模式的透明之处。

买方与创作者各自的核对动作

买方：下单前按顺序查三处——royaltyregistry.xyz 的声明值、目标市场订单预览里的费用分配行、以及该市场当前的版税政策公告；三处一致才谈”确定性”。创作者：在共享合约模式下改版税，改的是自己 Creator 空间的配置加注册表登记，改完要在目标市场分别验证显示是否同步；别假设所有平台都尊重你的新数值，强制与否是市场政策问题。

合约地址、接口行为与政策细节可能更新，本文口径见 2026 年 8 月检索的 Manifold 文档与仓库。本文只解释机制，不构成任何投资建议。