From d0568501246b1857a05d125376a0fe14d25cd213 Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Fri, 19 Aug 2022 16:12:01 +0700 Subject: [PATCH 1/8] Create 0066-nft-royalty-standard.md --- text/0066-nft-royalty-standard.md | 48 +++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 text/0066-nft-royalty-standard.md diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md new file mode 100644 index 00000000..584600a3 --- /dev/null +++ b/text/0066-nft-royalty-standard.md @@ -0,0 +1,48 @@ +- **TEP**: [66](https://github.com/ton-blockchain/TEPs/pull/0) +- **title**: NFTRoyalty Standard Extension +- **status**: Draft +- **type**: Contract Interface +- **authors**: [EmelyanenkoK](https://github.com/EmelyanenkoK), [Tolya](https://github.com/tolya-yanot) +- **created**: 12.02.2022 +- **replaces**: - +- **replaced by**: - + +# Summary + +Which feature this document introduces? Describe it in one paragraph. + +# Motivation + +Which problem we address? Why it is important to make a new TEP? + +# Guide + +Explain this document in simple language, as if you were teaching it to another developers. Give examples how your feature will work in real life. + +# Specification + +This section describes your feature formally. It contains requirements, which must be followed in order to implement your TEP. To keep things formal, it is convenient to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). You should include following text at the beginning of this section: + +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +# Drawbacks + +Why should we *not* do this? + +# Rationale and alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +# Prior art + +Discuss prior art, both the good and the bad, in relation to this proposal. How the problem stated in "Motivation" section was solved in another blockchains? This section encourages you as an author to learn from others' mistakes. Feel free to include links to blogs, books, Durov's whitepapers, etc. + +# Unresolved questions + +If there are some questions that have to be discussed during review process or to be solved during implementation of this TEP, write it here. + +# Future possibilities + +Do you have ideas, which things can be implemented on top of this TEP later? Write possible ideas of new TEPs, which are related to this TEP. From 3d4057377023309577c363746d0b37d9992628e7 Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Fri, 19 Aug 2022 16:26:54 +0700 Subject: [PATCH 2/8] Update 0066-nft-royalty-standard.md --- text/0066-nft-royalty-standard.md | 51 +++++++++++++++++++++++++++---- 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 584600a3..e25e1613 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -9,7 +9,9 @@ # Summary -Which feature this document introduces? Describe it in one paragraph. +Extension for [NFT Standard](https://github.com/ton-blockchain/TIPs/issues/62). + +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. # Motivation @@ -21,19 +23,56 @@ Explain this document in simple language, as if you were teaching it to another # Specification -This section describes your feature formally. It contains requirements, which must be followed in order to implement your TEP. To keep things formal, it is convenient to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). You should include following text at the beginning of this section: - > The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +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. + +## 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` + # Drawbacks Why should we *not* do this? # Rationale and alternatives -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +## Why are there no obligatory royalties to the author from all sales? +See the relevant paragraph in [NFT Standard](https://github.com/ton-blockchain/TIPs/issues/62). + +## 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. # Prior art From b9a6f02993c4194f4fb9fcaf4290aa6b9e452fe3 Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Sun, 21 Aug 2022 16:14:34 +0700 Subject: [PATCH 3/8] Update 0066-nft-royalty-standard.md --- text/0066-nft-royalty-standard.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index e25e1613..5e776895 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -15,11 +15,11 @@ A standardized way to retrieve royalty payment information for non-fungible toke # Motivation -Which problem we address? Why it is important to make a new TEP? +It is convenient to standardize royalty, so all NFT markets will pay royalty to collection author independently of how this collection was deployed. # Guide -Explain this document in simple language, as if you were teaching it to another developers. Give examples how your feature will work in real life. +TODO # Specification @@ -64,7 +64,7 @@ report_royalty_params query_id:uint64 numerator:uint16 denominator:uint16 destin # Drawbacks -Why should we *not* do this? +TODO # Rationale and alternatives @@ -76,12 +76,12 @@ We do not know in what currency the sale will take place. Percentage royalty is # Prior art -Discuss prior art, both the good and the bad, in relation to this proposal. How the problem stated in "Motivation" section was solved in another blockchains? This section encourages you as an author to learn from others' mistakes. Feel free to include links to blogs, books, Durov's whitepapers, etc. +TODO # Unresolved questions -If there are some questions that have to be discussed during review process or to be solved during implementation of this TEP, write it here. +TODO # Future possibilities -Do you have ideas, which things can be implemented on top of this TEP later? Write possible ideas of new TEPs, which are related to this TEP. +None From adaa9bca0113b0929434317b0dcc5e176c7c4566 Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Sun, 21 Aug 2022 16:16:50 +0700 Subject: [PATCH 4/8] Update 0066-nft-royalty-standard.md --- text/0066-nft-royalty-standard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 5e776895..d4351450 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -80,7 +80,7 @@ TODO # Unresolved questions -TODO +1. Shall we standardize the way marketplaces send internal message with royalties to the author? # Future possibilities From 5315ba5898236aa9e71924013f4e7619362f5ba4 Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Sun, 21 Aug 2022 16:17:21 +0700 Subject: [PATCH 5/8] Update 0066-nft-royalty-standard.md --- text/0066-nft-royalty-standard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index d4351450..41324553 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -80,7 +80,7 @@ TODO # Unresolved questions -1. Shall we standardize the way marketplaces send internal message with royalties to the author? +1. Shall we standardize internal message with royalties which markets send to the author? # Future possibilities From 0271e5759ae71551d7564e069026825c7cb6ce0d Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Sat, 27 Aug 2022 12:30:47 +0700 Subject: [PATCH 6/8] Update 0066-nft-royalty-standard.md --- text/0066-nft-royalty-standard.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 41324553..5719e10f 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -64,19 +64,16 @@ report_royalty_params query_id:uint64 numerator:uint16 denominator:uint16 destin # Drawbacks -TODO +There is no way to enforce royalty for each sale. There should be an option to gift NFT for free, however, it is not possible to track, was it really for free or not. See the relevant paragraph in [TEP-62](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md#why-are-there-no-obligatory-royalties-to-the-author-from-all-sales). # Rationale and alternatives -## Why are there no obligatory royalties to the author from all sales? -See the relevant paragraph in [NFT Standard](https://github.com/ton-blockchain/TIPs/issues/62). - ## 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. # Prior art -TODO +1. [EIP-2981: NFT Royalty Standard](https://eips.ethereum.org/EIPS/eip-2981) # Unresolved questions From 95f6dcff240676650bd3d1c2d8689f48a64c5dfe Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Sun, 28 Aug 2022 15:17:13 +0700 Subject: [PATCH 7/8] TEP-66: Add guide --- text/0066-nft-royalty-standard.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 5719e10f..8b90531a 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -19,7 +19,19 @@ It is convenient to standardize royalty, so all NFT markets will pay royalty to # Guide -TODO +1. report_royalty_params example implementation: [ton-blockchain/token-contract](https://github.com/ton-blockchain/token-contract/blob/2c13d3ef61ca4288293ad65bf0cfeaed83879b93/nft/nft-collection.fc#L58-L68). +2. get_royalty_params example implementation: [ton-blockchain/token-contract](https://github.com/ton-blockchain/token-contract/blob/2c13d3ef61ca4288293ad65bf0cfeaed83879b93/nft/nft-collection.fc#L149-L153). + +Royalty data example: +``` +"EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N" parse-smc-addr drop 2=: royalty-addr + + =: royalty-params +``` # Specification From 5a170cf420a5fbfc9bb6fbbc9238b96be31bef54 Mon Sep 17 00:00:00 2001 From: Vladimir Lebedev Date: Sun, 28 Aug 2022 15:18:10 +0700 Subject: [PATCH 8/8] Draft -> Review --- text/0066-nft-royalty-standard.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 8b90531a..bf0e30a4 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -1,6 +1,6 @@ -- **TEP**: [66](https://github.com/ton-blockchain/TEPs/pull/0) +- **TEP**: [66](https://github.com/ton-blockchain/TEPs/pull/6) - **title**: NFTRoyalty Standard Extension -- **status**: Draft +- **status**: Review - **type**: Contract Interface - **authors**: [EmelyanenkoK](https://github.com/EmelyanenkoK), [Tolya](https://github.com/tolya-yanot) - **created**: 12.02.2022