ERC-2981 版税标准：链上声明能要到创作者分成吗

一句话理解

ERC-2981 解决一个很小的技术问题：以前每个市场各维护一套“这个合集版税多少、打给谁”的私有线下表，项目方挨个提交、平台互相不一致。标准把答案搬到链上——合约直接回答 royaltyInfo(tokenId, salePrice)，返回收款人和金额。但必须立刻补一句：标准规定“怎么问”，管不了“付不付”。

接口结构

两个查询面、一个支付面：

• royaltyInfo(tokenId, salePrice) 返回收款地址与 wei 金额。注意它返回的是绝对金额而非比例，便于不同基数价格下计算一致。
• 通过 ERC-165 的 supportsInterface 宣告支持，市场先问“你会答题吗”，再开始答题。
• 合约也可以在转账时强制支付（royaltyPayment 扩展思路），但主流 ERC-721 基础转账并不强制——这是整个标准最关键的落差。

“声明了但收不到”是怎么发生的

版税的强制执行在技术上有两条路：要么在每次 NFT 转账时强行扣费（需要所有交易路径都经过收费逻辑，实践中很难，二手挂单、原子交换、场外交易都绕得开），要么靠市场在成交结算时主动执行（主流做市协议如 Seaport 在订单构造时支持携带版税条款，但可议价为零）。ERC-2981 选择了第二条的“信息统一”版本：它不改变支付流程，只统一查询。于是：

• 支持标准且愿意执行的市场：查询后按声明金额结算；
• 零版税竞争的市场：忽略声明，按自己的费率结算；
• 场外 P2P 交易：完全自愿。

换句话说，ERC-2981 是信息层的基建，不是产权执行器。围绕版税强制性的市场政策之争（哪些平台强制、哪些可选）属于商业策略范畴，随时间变化，请以各平台当期规则为准，本文核验截止 2026 年 7 月。

实践建议

• 创作者部署合约时把 royaltyInfo 返回值设对，并理解它在多数交易路径上只是“建议值”。
• 买家核对版税时别只看市场页面显示：直接链上调 royaltyInfo 是更可靠的口径，两者不一致时通常说明市场用了自己的表。
• 评估“版税收入”这个商业模型时，把成交渠道分布放进模型——若主要成交发生在不执行版税的场所，声明值再高也是纸面数字。

常见问答

问：合约里的版税声明和实际成交被分掉的钱不一致，谁说了算？

以成交交易里的实际转账为准。链上结算明细是最终事实，任何界面显示只是预测。审计版税收入的正确方法是对成交交易做转账拆解，不是对照声明值。

问：版税比例设得很高会伤害流动性吗？

高声明值会在执行版税的渠道抬高买家成本、在忽略版税的渠道毫无作用，净效应取决于成交渠道结构。这不是一个有标准答案的技术问题，而是渠道分布与定价策略的权衡，本文不做倾向性建议。

问：我怎么快速查一个合集有没有实现 2981？

区块浏览器打开已验证合约，在函数列表（Write/Read 选项卡）里找 royaltyInfo 与 supportsInterface；或用 ERC-165 查询工具直接喂接口 ID。都没有则说明版税信息只存在于平台私有表，显示值与链上无绑定关系，核对时要把这一点写进尽调笔记。

把版税声明放进合约还有信息外溢价值：链上可聚合、可索引，数据平台能统一口径统计全市场版税支出，创作者第一次可以跨平台汇总自己的分成收入，这层统计可行性是分散的私有表时代做不到的。

风险提示

本文为技术标准科普，不构成投资建议。版税声明不保证实际支付，平台政策存在变动，请以链上结算与当期规则为准。