Update EIP-5521: Move to Draft

Merged by EIP-Bot.

EIPS/eip-5521.md

@@ -46,7 +46,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 rNFT can be collaborating with the Top-down composible NFT (cf. [ERC-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. [ERC-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 applied to rentable scenarios (cf. [ERC-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). 
 
 *Scalable Interoperability* From March 26th 2023, this standard has been stepping forward by enabling cross-contract references, giving a scalable adoption for the broader public with stronger interoperability.
 
@@ -61,16 +61,17 @@ Truffle and Openzeppelin are required to run the following in a test network.
 ```node
 
 truffle develop
-rNFT = await ERC_rNFT.new("ERC_5521","ERC_5521")
-rNFT.safeMint(1,[],[])
+
+rNFT = await ERC_rNFT.new("ERC_5521", "ERC_5521")
+rNFT.safeMint(1, [], [])
 rNFT.referredOf(1)
 rNFT.referringOf(1)
 
-rNFT.safeMint(2,[rNFT.address],[1])
+rNFT.safeMint(2, [rNFT.address], [[1]])
 rNFT.referredOf(2)
 rNFT.referringOf(2)
 
-rNFT.safeMint(3,[rNFT.address],[1,2])
+rNFT.safeMint(3, [rNFT.address_1, rNFT.address_2], [[1,2], [2,4,5]])
 rNFT.referredOf(2)
 rNFT.referredOf(3)
 rNFT.referringOf(3)
@@ -298,7 +299,7 @@ The `createdTimestamp` only covers the block-level timestamp (based on block hea
 
 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 [ERC-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.
+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