在以太坊上查 NFT 版税要调用 ERC-2981 的 royaltyInfo，TON 上对应的是一套完全不同的形态：TEP-66 把版税信息写成合约的一个取方法和两条内部消息。它不要求任何市场强制执行什么，只规定一件事——当有人问起版税时，合约应当用统一格式回答。理解这套问答结构，是核对 TON 藏品版税声明的第一站。
先看取方法。TEP-66 要求 NFT 条目合约实现 royalty_params()，返回三个值：整数 numerator（分子）、整数 denominator（分母）和一个 MsgAddress 类型的 destination。版税份额等于分子除以分母，规范给的例子是分子 11、分母 1000，也就是百分之一点一，并且明确要求分子必须小于分母。收款地址以消息地址切片的形态返回，指向谁，链上写死，改不改得动取决于合约本身有没有留管理入口。
取方法之外还有内部消息，这是 TON 与以太坊的明显差异。TEP-66 定义了 get_royalty_params 请求，TL-B 结构是 get_royalty_params#693d3950 query_id:uint64，query_id 由发起方任意填作对账编号；合约收到后应回一条 report_royalty_params#a8cb00ad，携带同样的 query_id 加分子、分母和收款地址，回复时要求使用不依赖消息金额的发送模式，让回报不因转账金额被扣而失真。市场端不直接读他人合约存储时，就可以走这条消息问一遍。
分工上，TEP-66 是叠加在 TEP-62 NFT 标准之上的扩展：条目合约必须实现这套查询；如果条目把逻辑委托给集合合约，则由集合合约实现。也就是说，同一个集合里所有条目通常给出同样的比例和同一个收款地址——这与以太坊上按单个 tokenId 分别声明版税的做法不同，更接近集合级声明。规范在 FAQ 里解释了为什么只做比例版税而不做固定金额版税：卖出时用的币种事先并不知道，百分比是唯一通用可比的表达方式，固定金额留给市场自己谈。
规范同时点名了 ERC 阵营的前例：它的先例就是 EIP-2981。两者的精神一致——版税是声明不是锁，查询回答”发行方希望收多少”，而成交路径里到底扣不扣、扣了打给谁，仍然由经手成交的市场或合约决定。差别在于 TON 把查询做成了可被任何合约用消息触发的一问一答，连没有外部只读调用习惯的合约也能被问到。
实际动手核对时，两条查询路径的适用场景不同。取方法 royalty_params() 走的是只读调用，适合浏览器或工具脚本直接问一句就拿三元组；内部消息路径则适合合约对合约的场景，比如一个市场合约在撮合逻辑里需要现场确认版税，它没法做外部只读调用，就用 get_royalty_params 发一条带 query_id 的消息，从回报里取数。query_id 由发起方任意生成，作用是把你发出的多次提问和回来的多条回报对上号——同一区块高度内问两个集合，靠编号区分哪份回答属于哪个。核对记录里最好连 query_id 与区块高度一起截图，避免日后对不上是哪一次查询。分子必须小于分母这条硬约束还有一层含义：这套声明在格式上就排除了”版税百分之百”这类极端值，读到的比例永远小于一。
普通持有人能把这些字段用起来的路径很直接：先确认你手上的藏品合约声明支持 TEP-66，再读 royalty_params() 的三个返回值，记下分子分母化成百分比、记下收款地址尾部若干位，然后在市场卖出前把这份记录与挂牌页面上的版税设置对照。两边对不上时，以链上读取结果为准，因为市场页面上的数字随时可以被平台侧改掉，而合约返回什么由链上代码决定。任何关于某集合当前版税比例的断言，都应标注你实际核验的日期。
还有一条边界值得写清楚：TEP-66 的规范状态是 Active，但它约束的只是合约的应答格式，不约束市场行为。某个交易平台是否读取这个字段、是否据此分账、分账失败怎么处理，都是平台自己的政策，与规范无关。查到的 destination 是发行方填写的地址，它证明的是”发行方要求打到这里”，不证明历史上每一笔成交真的打到了这里——后者要靠成交记录逐笔核对，规范没有提供自动追缴机制。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。