Add ERC: Staked ERC-721 Ownership Recognition

ERCS/erc-7531.md

@@ -0,0 +1,127 @@
+---
+eip: 7531
+title: Staked ERC-721 Ownership Recognition
+description: Recognizing NFT ownership when staked into other contracts.
+author: Francesco Sullo (@sullof)
+discussions-to: https://ethereum-magicians.org/t/eip-7531-resolving-staked-erc-721-ownership-recognition/15967
+status: Draft
+type: Standards Track
+category: ERC
+created: 2023-10-01
+requires: 165, 721
+---
+
+## Abstract
+
+The ownership of [ERC-721](./eip-721.md) tokens when staked in a pool presents challenges, particularly when it involves older, non-lockable NFTs like, for example, Crypto Punks or Bored Ape Yacht Club (BAYC) tokens. This proposal introduces an interface to address these challenges by allowing staked NFTs to be recognized by their original owners, even after they've been staked.
+
+## 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.
+
+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.
+
+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.
+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.
+
+The interface provides a simple, elegant way to extend staking compatibility to legacy NFTs without affecting their core functionality or benefits of ownership.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+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. 
+   *      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.
+   */
+  event RightsHolderChange(address indexed tokenAddress, uint256 indexed tokenId, address indexed holder);
+
+  /**
+   * @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.
+   * @return The address of the entity with rights over the token.
+   */
+  function rightsHolderOf(
+    address tokenAddress,
+    uint256 tokenId
+  ) external view returns (address);
+}
+```
+
+The `RightsHolderChange` event is crucial for accurately identifying the actual owner of a held token. In scenarios where a token is staked in a contract, the [ERC-721](./eip-721.md) Transfer event would incorrectly assign ownership to the staking contract itself. The `RightsHolderChange` event addresses this discrepancy by explicitly signaling the real owner of the token rights.
+
+### 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.
+
+### 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.
+
+## Rationale
+
+### Addressing Non-Lockable NFT Challenges:
+
+Non-lockable NFTs present a unique challenge in decentralized ecosystems, especially in scenarios involving staking or delegating usage rights. The standard [ERC-721](./eip-721.md) `ownerOf` function returns the current owner of the NFT, which, in the case of staking, would be the staking pool contract. This transfer of ownership to the staking pool, even if temporary, can disrupt the utility or privileges tied to the NFT, such as participation in governance, access to exclusive content, or utility within a specific ecosystem.
+
+### The `rightsHolderOf` Method:
+
+The `rightsHolderOf` method provides a solution to this challenge. By maintaining a record of the original owner or the rightful holder of certain privileges associated with the NFT, this method ensures that the underlying utility of the NFT is preserved, even when the NFT itself is held in a pool.
+
+### Technical Advantages:
+
+1. Preservation of Utility: This approach allows NFT owners to leverage their assets in staking pools or other smart contracts without losing access to the benefits associated with the NFT. This is particularly important for NFTs that confer ongoing benefits or rights.
+
+2. Enhanced Flexibility: The method offers greater flexibility for NFT owners, allowing them to participate in staking and other DeFi activities without relinquishing the intrinsic benefits of their NFTs.
+
+3. Compatibility and Interoperability: By introducing a new method instead of altering the existing ownerOf function, this EIP ensures backward compatibility with existing [ERC-721](./eip-721.md) contracts. This is crucial for maintaining interoperability across various platforms and applications in the NFT space.
+
+4. Event-Driven Updates: The `RightsHolderChange` event facilitates real-time tracking of the rights-holder of an NFT. This is particularly useful for third-party platforms and services that rely on up-to-date ownership information to provide services or privileges.
+
+### Addressing Potential Misuse:
+
+While this approach introduces a layer of complexity, it also comes with the need for diligent implementation to prevent misuse, such as the wrongful assignment of rights. This EIP outlines security considerations and best practices to mitigate such risks.
+
+## Backwards Compatibility
+
+This standard is fully backwards compatible with existing [ERC-721](./eip-721.md) contracts. It can seamlessly integrate with existing upgradeable staking pools, provided they choose to adopt it. It does not require changes to the [ERC-721](./eip-721.md) standard but acts as an enhancement for staking pools.
+
+## Security Considerations
+
+A potential risk with this interface is the improper assignment of ownership by a staking pool to a different wallet. This could allow that wallet to access privileges associated with the NFT, which might not be intended by the true owner. However, it is important to note that this risk is lower than transferring full legal ownership of the NFT to the staking pool, as the interface only enables recognizing the staker, not replacing the actual owner on-chain.
+
+### Event Authenticity:
+
+There is a concern regarding the potential emission of fake `RightsHolderChange` events. Since any contract can emit such an event, there's a risk of misinformation or misrepresentation of ownership. It is crucial for entities listening to the `RightsHolderChange` event to verify that the emitting contract is indeed the current owner of the token. This validation is essential to ensure the accuracy of ownership information and to mitigate the risks associated with deceptive event emissions.
+
+### Reducing the Risk of Inaccurate Ownership Records:
+
+While improper use of this interface poses some risk of inaccurate ownership records, this is an inherent issue with any staking arrangement. The risk is somewhat mitigated by the fact that the owner retains custody rather than transferring ownership.
+
+### Due Diligence:
+
+Consumers of privilege-granting NFTs should exercise due diligence when evaluating staking providers. Signs of mismanagement or fraud should be carefully assessed. The interface itself does not enable new manipulation capabilities, but caution is always prudent when interacting with smart contracts and staking pools.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).