Update ERC-7531: Adding ierc7531 rights

Merged by EIP-Bot.

ERCS/erc-7531.md

@@ -41,7 +41,7 @@ The interface is defined as follows:
 
 ```solidity
 interface IERC7531 {
- 
+
   /**
    * @notice MUST be emitted when the token's technical owner (the contract holding the token) is different 
    *      from its actual owner (the entity with rights over the token). 
@@ -54,13 +54,12 @@ interface IERC7531 {
    * @param tokenAddress The address of the token contract.
    * @param tokenId The ID of the token.
    * @param holder The address of the actual rights holder of the token.
-   * @param rights The type of rights held by the holder. The supported rights in V1 are:
+   * @param right The type of right held by the holder. The initial supported rights are:
    *
    *           0x399d2b36   // bytes4(keccak256("ownership"))
    *           0x230a5961   // bytes4(keccak256("usage"))
    *
-   *        This approach using bytes4 allows the community to add more rights in future versions without
-   *        breaking compatibility with this interface.
+   *        This allows projects to add more rights without breaking compatibility with this interface. See IERC7531Rights for more details.
    */
   event RightsHolderChange(address indexed tokenAddress, uint256 indexed tokenId, address indexed holder, bytes4 right);
 
@@ -91,6 +90,40 @@ The `RightsHolderChange` event MUST be emitted either in the same block as the c
 
 To maintain compatibility with the broader ecosystem and optimize for gas efficiency, any new `Transfer` event involving the same token invalidates any previous `RightsHolderChange` event. This approach ensures that the most recent `Transfer` event reliably reflects the current ownership status, negating the need for additional events upon unstaking.
 
+### NFT extension
+
+The two default rights are:
+* 0x399d2b36   // bytes4(keccak256("ownership"))
+* 0x230a5961   // bytes4(keccak256("usage"))
+
+However, there can ben NFTs that only need to validate the ownership, others may need to validate the usage, and others may need to validate both, some other NFT may need to manage totally different rights.
+
+To give NFTs the necessary flexibility, we also propose the following RECOMMENDED but OPTIONAL extension.
+
+```solidity
+interface IERC7531Rights {
+  
+  /**
+   * @dev Returns the list of rights supported by the NFT.
+   * @return The list of rights supported by the NFT.
+   */
+  function supportedERC7531Rights() external view returns (bytes4[] memory);
+  
+  /**
+   * @dev Returns whether the NFT supports a specific right.
+   * @param right The right to check.
+   * @return Whether the NFT supports the right.
+   */
+  function supportsERC7531Right(bytes4 right) external view returns (bool);
+}
+```
+
+It allows NFTs to return the list of rights it supports, and projects to verify it the NFT supports a specific right. Since the rights are identified by the bytes4 hash of the right name, when introducing new rights, NFT projects SHOULD make public statements about the string that corresponds to the bytes4 hash and explain the rationale for it.
+
+If the NFT does not support the interface (for example, if an existing NFT), project using NFTs SHOULD consider only the standard rights.
+
+NFT Projects SHOULD adhere to pre-existing rights, when possible, to avoid the proliferation of rights that could make the system less efficient and more complex.
+
 ## Rationale
 
 ### Addressing Non-Lockable NFT Challenges: