NFT 版税的老问题在每条链上都一样：转让动作和买卖动作在合约里长得一模一样，收款该不该发生、发给谁、发多少，总得有个标准地方可查。Tezos 生态为此写过一份提案：NFT Royalties draft，托管在 tzip 官方仓库的 drafts/current 目录（文件 draft-nft-royalties.md），按仓库的元数据，这是一份草案状态的接口类标准，作者 Josh Dechant，最早创建于 2022 年 8 月，后续修订到第三版，明确声明扩展 TZIP-012——也就是 Tezos 的 FA2 多资产代币接口。写这篇时它仍是草案：能被引用、未必被全部市场实现，这个状态本身就该放进阅读预期。
草案的问题意识开门见山：转让不一定等于销售，所以协议不可能在每次 transfer 里强制收版税；于是标准只解决”信息”这一半——让市场能在成交前查到一笔销售应付的版税比例和收款方，付不付、怎么付留给交易机制。落到接口上，实现该标准的合约必须提供一个名为 get_royalties 的 Michelson 链上视图（view）：输入代币编号，返回一对结构——total_shares 总份额与一张”地址到份额”的映射。份额按百分比约定：例如 total_shares 为一万，两个地址分别拿 500 与 750，就代表版税的 5% 与 7.5%，且各份额之和不得超过总份额；同一合约可以返回不同的份额表，但标准提醒实现方不要依据不可预测的变量作答。市场方拿到份额后再按公式结算：应付版税等于成交价乘以份额除以总份额；标准同时规定，成交币种是什么，版税就用同一币种支付（XTZ 成交付 XTZ，USDT 成交付 USDT），版税为零时不必发一笔零金额交易，而支持该标准的市场必须为它促成的每笔销售付版税——无论成交发生在链上、拍卖、抽奖还是场外。这与以太坊上 EIP-2981 的”链上声明、自愿执行”思路同构：链上只回答”应付多少、付给谁”，钱款交割由市场在结算时执行，付款通知的具体机制被草案明确划出范围之外——它自称只是”最小的积木”，供后续机制在其上搭建。
为什么版税信息值得单独标准化？草案的动机部分讲得直白：市场很多，如果每家按自己的私有接口查版税，创作者就要挨个登记、挨个祈祷；只要版税可被任何市场以同一方式查询，跨平台转售也能算清应付，若某个市场干脆不实现这套接口，那它的二级成交就不产生创作者收入——这既是对集成方的要求，也是对买方的提示。判断一枚 Tezos 藏品的版税处境，顺序由此清晰：第一步，在区块浏览器或开发者工具里对合约调用 get_royalties 视图，看它是否实现、份额表里比例与地址是什么；第二步，看目标市场是否声明实现这份草案的查询与执行；第三步，看成交回执里是否出现了对应收款方的转账记录。三步缺任何一步，版税都只是纸面数字。
给收藏者的三条风险提示：草案地位意味着接口可能继续演化，历史项目未必迁移；百分比查询接口返回的是”应付”而非”已付”，两者靠回执对账；多收款人结构下，宣称的”创作者版税”可能已按比例分给了发行、代理等多个地址。查得到，和拿得到，中间隔着整个结算流程。
把这份草案放回 Tezos 的生态语境里，能看懂它为什么长成这样。Tezos 的 NFT 主要活在一枚共享合约里：多个项目挤在同一个 FA2 合约中按代币编号区分，这是 objkt 等平台早期的默认结构（这个背景属于生态常识，具体合约以链上为准）。共享合约意味着版税不可能像以太坊那样”每项目一合约各自声明”，于是草案把 get_royalties 的入参设计成 token_id——同一个合约对 A 项目回答 5%、对 B 项目回答 7.5% 互不干扰。份额表用地址到整数的映射而不是单一收款人，也是同样的务实：发行方、策展方、艺术家工作室可以按份额分账，不必链下再拆一次。它没有解决的部分同样值得记住：没有强制结算挂钩，版税依旧依赖市场自觉；份额可随调用变化，标准只要求别拿不可预测变量当依据；连”多少算合理”都没规定，一切都交给买卖双方在查询结果面前自己判断。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。