Update ERC-7531: Adding rights to ERC7531

Merged by EIP-Bot.

ERCS/erc-7531.md

@@ -17,17 +17,20 @@ The ownership of [ERC-721](./eip-721.md) tokens when staked in a pool presents c
 
 ## Motivation
 
-Recent solutions involve retaining NFT ownership while "locking" the token when staked. However, this requires the NFT contract to implement lockable functionality. Many early vintage NFTs like CryptoPunks or Bored Ape Yacht Club were not originally designed as lockable.
+Recent solutions involve retaining NFT ownership while "locking" an NFT letting the owner keeping its ownership. However, this requires the NFT contract to implement lockable functionality. Early NFTs were not originally designed as lockable and so they must be staked transferring the ownership to the staking contract.
 
-When these non-lockable NFTs are staked, ownership transfers fully to the staking pool contract. This prevents the original owner from accessing valuable privileges and benefits associated with their NFTs.
+This prevents the original owner from accessing valuable privileges and benefits associated with their NFTs.
 
 For example:
 
-A BAYC NFT holder would lose access to the BAYC Yacht Club and member events when staked.
-A CryptoPunks holder may miss out on special airdrops or displays only available to verified owners.
-Owners of other early NFTs like EtherRocks would lose the social status of provable ownership when staked.
+- A BAYC NFT holder would lose access to the BAYC Yacht Club and member events when staked.
+- A CryptoPunks holder may miss out on special airdrops or displays only available to verified owners.
+- Owners of other early NFTs like EtherRocks would lose the social status of provable ownership when staked.
+
 By maintaining a record of the original owner, the proposed interface allows these original perks to remain accessible even when the NFT is staked elsewhere. This compatibility is critical for vintage NFT projects lacking native locking mechanisms.
 
+Another important right, is the right to use an asset. For example an NFT can be used to play a game. If the NFT is lent to a user, the ownership of the NFT is transferred to the lending contract. In this case, it can be hard to identify the wallet that has the right to us the NFT in the game, which should be the user.
+
 The interface provides a simple, elegant way to extend staking compatibility to legacy NFTs without affecting their core functionality or benefits of ownership.
 
 ## Specification
@@ -38,32 +41,42 @@ The interface is defined as follows:
 
 ```solidity
 interface IERC7531 {
+ 
   /**
-   * @dev 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). This scenario is common 
-   *      in staking, where a staking contract is the technical owner. The event MUST be emitted 
-   *      in the same or any subsequent block as the Transfer event for the token. 
+   * @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). 
+   * @dev This scenario is common in staking, where a staking contract is the technical owner. The event MUST  
+   *      be emitted in the same or any subsequent block as the Transfer event for the token. 
    *      A later Transfer event involving the same token supersedes this RightsHolderChange event.
    *      To ensure authenticity, entities listening to this event MUST verify that the contract emitting
    *      the event matches the token's current owner as per the related Transfer event.
    *
    * @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:
+   *
+   *           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.
    */
-  event RightsHolderChange(address indexed tokenAddress, uint256 indexed tokenId, address indexed holder);
+  event RightsHolderChange(address indexed tokenAddress, uint256 indexed tokenId, address indexed holder, bytes4 right);
 
   /**
    * @dev Returns the address of the entity with rights over the token, distinct from the current owner.
    *      The function MUST revert if the token does not exist or is not currently held.
    *
    * @param tokenAddress The address of the ERC-721 contract.
    * @param tokenId The ID of the token.
+   * @param rights The type of rights held by the holder.
    * @return The address of the entity with rights over the token.
    */
   function rightsHolderOf(
     address tokenAddress,
-    uint256 tokenId
+    uint256 tokenId,
+    bytes4 right
   ) external view returns (address);
 }
 ```
@@ -72,11 +85,11 @@ The `RightsHolderChange` event is crucial for accurately identifying the actual
 
 ### Timing of Event Emission:
 
-The `RightsHolderChange` event MUST be emitted either in the same block as the corresponding Transfer event or in any subsequent block. This approach offers flexibility for existing pools to upgrade their systems without compromising past compatibility. Specifically, staking pools can emit this event for all previously staked tokens, or they can allow users to actively reclaim their ownership. In the latter case, the event SHOULD be emitted as part of the ownership reclamation process. This flexibility ensures that the system can adapt to both current and future states while accurately reflecting the actual ownership of held tokens.
+The `RightsHolderChange` event MUST be emitted either in the same block as the corresponding `Transfer` event or in any subsequent block. This approach offers flexibility for existing pools to upgrade their systems without compromising past compatibility. Specifically, staking pools can emit this event for all previously staked tokens, or they can allow users to actively reclaim their ownership. In the latter case, the event SHOULD be emitted as part of the ownership reclamation process. This flexibility ensures that the system can adapt to both current and future states while accurately reflecting the actual ownership of held tokens.
 
 ### Invalidation of Previous `RightsHolderChange` Events:
 
-To maintain compatibility with the broader ecosystem and optimize for gas efficiency, any new `Transfer` event involving the same token invalidates the 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.
+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.
 
 ## Rationale