NFTRoyalty Standard Extension

[tolya-yanot]

⚠️ WARNING: Standards are now published and discussed in the TEPs repository. This page may be out of date.

NFTRoyalty

Summary

Extension for NFT Standard.

A standardized way to retrieve royalty payment information for non-fungible tokens (NFTs) to enable universal support for royalty payments across all NFT marketplaces and ecosystem participants.

Specification

NFT Collection smart contract must implement:

(if this is a variant of NFT items without collection then NFT item smart contract must implement this).

Get-methods

1. royalty_params() returns (int numerator, int denominator, slice destination)

   Royalty share is numerator / denominator.

   E.g if numerator = 11 and denominator = 1000 then royalty share is 11 / 1000 * 100% = 1.1%.

   numerator must be less denominator.

   destination - address to send royalty. Slice of type MsgAddress.

Internal messages

1. get_royalty_params

   Request

   TL-B schema of inbound message:

   get_royalty_params#693d3950 query_id:uint64 = InternalMsgBody;

   query_id - arbitrary request number.

   Should do:

   Send back message with the following layout and send-mode 64 (return msg amount except gas fees):

   TL-B schema report_royalty_params#a8cb00ad query_id:uint64 numerator:uint16 denominator:uint16 destination:MsgAddress = InternalMsgBody;

It is expected that marketplaces which want to participate in royalty payments will send muldiv(price, nominator, denominator) to destination address after NFT sale.

Marketplaces SHOULD neglect zero-value royalty payments.

Marketplaces MAY deduct gas and message fees required to send royalty from royalty amount.

Rationale

Why are there no obligatory royalties to the author from all sales?

See the relevant paragraph in NFT Standard.

Why can't I set a fixed amount of royalties?

We do not know in what currency the sale will take place. Percentage royalty is universal.

TL-B Schema

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

[NoelJacob]

I think it's better if royalty fee is enforced in smart contracts, if it's possible. Otherwise it is guaranteed to be not followed. Royalty fees are beneficial only to creator.
Because ignoring royalty fees are beneficial to sellers, buyers and marketplaces I'd go as far to say ignoring it by marketplaces might be common in few years and creators will want for a new standard.

[EmelyanenkoK]

@NoelJacob Considering cases when user need to be able to :

• transfer NFT to himself (during rotation of wallets)
• send NFT gift to the other user
• use NFT in complex scenario via smartcontracts which implement custom logic
  it is impossible to enforce royalty onchain.

The only way of royalty onchain enforcing is to restrict NFT transfers so tightly that any transfer is a public auction: this is possible but it limits usefulness a lot and make user experience a nightmare.

[NoelJacob]

Having read more (from ethereum especially), yes, I guess it's fine making Royalty voluntary.

[tvorogme]

Maybe we need to rename royalty_params to get_royalty_params so all functions have the same naming style?

#62 Get method section have get_ prefix in all methods

[NoelJacob]

Is royalty required both in smart contract and as seller_basis_fee in metadata ?

[EmelyanenkoK]

Is royalty required both in smart contract and as seller_basis_fee in metadata ?

I believe it is better to store royalty info in one place to avoid conflicts.