ERC-7531: Staked ERC-721 Ownership Recognition
Recognizing NFT ownership when staked into other contracts.
Abstract
The ownership of ERC-721 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" 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.
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.
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
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:
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 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. 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 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 OPTIONAL extension.
It allows NFTs to return the list of rights they support, and projects to verify it an 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:
Non-lockable NFTs present a unique challenge in decentralized ecosystems, especially in scenarios involving staking or delegating usage rights. The standard ERC-721 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:
-
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.
-
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.
-
Compatibility and Interoperability: By introducing a new method instead of altering the existing ownerOf function, this EIP ensures backward compatibility with existing ERC-721 contracts. This is crucial for maintaining interoperability across various platforms and applications in the NFT space.
-
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 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 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.