Update EIP-5521: Add more descriptions (#5563)

* Create eip-referable-NFT.md This standard proposes an extension to ERC-721 Non-Fungible Tokens (NFTs) to construct reference relationships among NFTs. * Update eip-***.md * Update eip-referableNFT.md * update eip name * Update eip-0000.md * Update eip-0000.md * Update eip-0000.md * Update eip-0000.md * Update eip-0000.md * Update eip-0000.md * Update eip number Update eip number * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5521.md Co-authored-by: Pandapip1 <[email protected]> * Update eip-5521.md * Update eip-5521.md * Update eip-5521.md * Update eip-5521.md * Update * Update .gitignore Co-authored-by: Pandapip1 <[email protected]>
ethereum · Sep 1, 2022 · bab9d3f · bab9d3f
1 parent 4f37566
commit bab9d3f
Showing 1 changed file with 14 additions and 4 deletions.
diff --git a/EIPS/eip-5521.md b/EIPS/eip-5521.md
@@ -2,13 +2,13 @@
 eip: 5521
 title: Referable NFT
 description: An EIP-721 extension to construct reference relationships among NFTs
-author: Saber Yu (@OniReimu), Qin Wang <[email protected]>, Shange Fu <[email protected]>, Shiping Chen <shiping.chen@data61.csiso.au>, Sherry Xu <[email protected]>, Jiangshan Yu <[email protected]>
+author: Saber Yu (@OniReimu), Qin Wang <[email protected]>, Shange Fu <[email protected]>, Shiping Chen <shiping.chen@data61.csiro.au>, Sherry Xu <[email protected]>, Jiangshan Yu <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/eip-x-erc-721-referable-nft/10310
 status: Draft
 type: Standards Track
 category: ERC
 created: 2022-08-10
-requires: 165, 721, 5006
+requires: 165, 721
 ---
 
 ## Abstract
@@ -22,6 +22,7 @@ By adding the `referring` indicator, users can mint new NFTs (e.g., C, D, E) by
 ## Specification
 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.
 
+`Relationship`: a structure that contains `referring`, `referred`, `createdTimestamp`, and other customized attributes such as `mapping (uint256 => address) privityOfAgreement` recording the ownerships of referred NFTs at the time the rNFTs were being created.
 `referring`: an out-degree indicator, used to show the users this NFT refers to;
 `referred`: an in-degree indicator, used to show the users who have refereed this NFT;
 `createdTimestamp`: a time-based indicator, used to compare the timestamp of mint.
@@ -40,7 +41,7 @@ This standard is intended to establish the referable DAG for queries on cross-re
 
 *Incentive Compatibility*: This standard clarifies the referable relationship across different NFTs, helping to integrate multiple up-layer incentive models for both original NFT owners and new creators.
 
-*Easy Integration*: This standard makes it easier for the existing token standards or third-party protocols. For instance, the referable NFT can be applied to rentable scenarios (cf. [EIP-5006](./eip-5006.md) to build a hierarchical rental market, where multiple users can rent the same NFT during the same time or one user can rent multiple NFTs during the same duration). 
+*Easy Integration*: This standard makes it easier for the existing token standards or third-party protocols. For instance, the rNFT can be collaborating with the Top-down composible NFT (cf. [EIP-998](./eip-998.md) to build a finer-grained reference relationship, where the `Relationship` structure and the interface `IERC_rNFT` can be seamlessly stored and updated when invoking the `mint` function). Another example is that the rNFT can be applied to rentable scenarios (cf. [EIP-5006](./eip-5006.md) to build a hierarchical rental market, where multiple users can rent the same NFT during the same time or one user can rent multiple NFTs during the same duration). 
 
 ## Backwards Compatibility
 This standard can be fully [EIP-721](./eip-721.md) compatible by adding an extension function set.
@@ -106,6 +107,11 @@ contract ERC_rNFT is ERC721, IERC_rNFT {
         uint256[] referring;   // referring list
         uint256[] referred; // referred list
         uint256 createdTimestamp; // unix timestamp when the rNFT is being created
+
+        // Customized attributes
+        // The distribution of profits complies to the aggreement when the NFT was being created regardless of the change of ownership unless specified in the agreement
+        // <token ID => token owner address>
+        // mapping (uint256 => address) privityOfAgreement
     }
 
     mapping (uint256 => Relationship) internal _relationship;
@@ -179,7 +185,11 @@ contract ERC_rNFT is ERC721, IERC_rNFT {
 ```
 
 ## Security Considerations
-The `createdTimestamp` only covers the block-level timestamp (based on block headers), which does not support fine-grained comparison such as transaction-level.
+The `createdTimestamp` only covers the block-level timestamp (based on block headers), which does not support fine-grained comparisons such as transaction-level.
+
+The change of ownership has nothing to do with the reference relationship. Normally, the distribution of profits complies to the aggreement when the NFT was being created regardless of the change of ownership unless specified in the agreement.
+
+In the context of collaborating with [EIP-998](./eip-998.md), referring a token will not refer its descendants by default. In the case that only a specific child token gets referred, it means the privity of contract will involve nobody other than the owner of this specific child token. Alternatively, a chain-of-reference all the way from the root token to a specific very bottom child token (from root to leaf) can be constructured and recorded in the `referring` to explicitly define the distribution of profits.
 
 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).