Appearance
TEP: 66 - NFT 版税标准扩展
- TEP: 66
- 标题: NFT 版税标准扩展
- 状态: 活跃
- 类型: 合约接口
- 作者: EmelyanenkoK, Tolya
- 创建日期: 2022年2月12日
- 取代: -
- 被取代: -
摘要
这是 NFT 标准 的扩展。
提供了一种标准化的方法来检索非同质化代币(NFT)的版税支付信息,以便在所有 NFT 市场和生态系统参与者中实现对版税支付的普遍支持。
动机
标准化版税是很方便的,这样所有的 NFT 市场都能够独立于该集合的部署方式向集合作者支付版税。
指南
report_royalty_params
示例实现:ton-blockchain/token-contract。get_royalty_params
示例实现:ton-blockchain/token-contract。
在 Fift 中的版税数据示例:
"EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N" parse-smc-addr drop 2=: royalty-addr
<b
11 16 u, // 分子
1000 16 u, // 分母
royalty-addr Addr, // 发送版税的地址
b> =: royalty-params
规范
本文档中的关键字“必须”、“不得”、“要求”、“应”、“不应”、“推荐”、“可以”和“可选”按照 RFC 2119 中的描述进行解释。
NFT 集合智能合约必须实现:
(如果这是没有集合的 NFT 项目变体,那么 NFT 项目智能合约必须实现这些方法)。
Get-methods
royalty_params()
返回(int numerator, int denominator, slice destination)
版税份额为numerator / denominator
。 例如,如果numerator = 11
且denominator = 1000
,则版税份额为11 / 1000 * 100% = 1.1%
。numerator
必须小于denominator
。destination
- 发送版税的地址。类型为MsgAddress
的切片。
内部消息
get_royalty_params
请求 入站消息的 TL-B 方案:get_royalty_params#693d3950 query_id:uint64 = InternalMsgBody;
query_id
- 任意请求编号。 应做: 发送回带有以下布局的消息,并使用发送模式64
(返回消息金额,扣除燃气费): TL-B 方案report_royalty_params#a8cb00ad query_id:uint64 numerator:uint16 denominator:uint16 destination:MsgAddress = InternalMsgBody;
预期希望参与版税支付的市场将在 NFT 销售后将 muldiv(price, numerator, denominator)
发送到 destination
地址。
市场应忽略零值版税支付。
市场可以从版税金额中扣除发送版税所需的燃气费和消息费。
TL-B 方案
get_royalty_params query_id:uint64 = InternalMsgBody;
report_royalty_params query_id:uint64 numerator:uint16 denominator:uint16 destination:MsgAddress = InternalMsgBody;
crc32('get_royalty_params query_id:uint64 = InternalMsgBody') = 0xe93d3950 & 0x7fffffff = 0x693d3950
crc32('report_royalty_params query_id:uint64 numerator:uint16 denominator:uint16 destination:MsgAddress = InternalMsgBody') = 0xa8cb00ad | 0x80000000 = 0xa8cb00ad
缺点
没有办法强制每次销售都支付版税。应当有一个选项可以免费赠送 NFT,然而,无法追踪它是否真的免费赠送。请参阅 TEP-62 中的相关段落。
理由和替代方案
为什么不能设置固定金额的版税?
我们不知道销售将以何种货币进行。百分比版税是通用的。
先前的工作
未解决的问题
- 我们是否应该标准化市场发送给作者的版税内部消息?
未来的可能性
无