This idea has been on my mind as well recently, and looking through various threads on this forum it seems others have too, and it seems this one is most active and willing to be updated to fit the needs of various use-cases.
The need to have another “role” (or set of roles) beyond “owner” and “approved” (the labels used in the ERC721 standard) I agree with the general concept of. I think updating this EIP to have a more generic form of “roles” that a contract can use, plus have the option to extend with custom roles is a good direction to go in.
EIP634 is the (currently draft) standard for how the ENS specifies text metadata on their tokens, in which the standard has a few Global keys that it defines, plus lays out a structure for custom keys. That standard only allows for one value of each text key, but for this extension on the ERC721 standard, because the ERC721 standard allows for both “approved” (for one token) and “approved for all”, it might be a good idea to keep that concept of every “role” could be assigned to one address, or one address marked as having that role for all tokens.
Alternatively, the roles could be identified by bytes32 values that are hashes of known structures. That’s a style that’s done in the OpenZeppelin AccessControl template contract, and used as typeHash identifiers in EIP712. With that idea, a “renter” role would be identified not as "renter", but as keccak256("renter").
Additionally, this EIP is structured to be an “extension” meaning that new ERC721 contracts deployed after this standard could choose to implement it. Existing ERC721 contracts could use the new extension by creating a new contract and having users convert (“wrap” or “upgrade”) to the new contract, and then they could have “in-place”/“non-custodial” staking/renting, but the current ecosystem of NFT marketplaces would then treat that new contract as a new “collection” and not carry the previous collection’s history forward (and makes user experience harder, as users need to then be given ways to be assured the new collection is legitimate and not a scam/copycat collection). For contracts that already exist, or platform infrastructures that want to provide generic staking/rental options for many different tokens, or for multisig wallets that hold ERC721 tokens, extending this EIP to have consumerOf(address tokenCollection, uint256 tokenId) (representing an inquiry like “hey smart contract, you’re marked as having some role for token #100 from collection ABC. For your logic, what (if any) other address has rights to trigger you to do something on behalf of token #100 from collection ABC?”) would be helpful. This would allow chaining together role requests, to find a final EOA that represents the human behind the role, making wallet and portfolio UIs able to better enumerate all tokens a user has some rights/roles to.
For completeness (and to tag them as linked from here), my research searching around for similar proposals yielded these other EIPs that have attempted to do similar things:
- EIP900 - Simple Staking Interface: Created early 2018 and is now marked Stagnant in the EIPs repository.
- EIP1132 - Time-locking tokens within a contract: Created in late 2018 and is merged into the EIPs repository as a Draft.
- EIP4353 - Viewing Staked Tokens in NFT: Drafted late 2021, had a merge request to the EIPs repository that got closed without merging in. Discussion comments on this one were that it might be too specific to a single application use.
- ERC4902 - Decentralized Autonomous Access: An attempt to quantify different holding patterns as different levels of “trust”. Drafted early 2022 and closed out without merging.
And other discussion threads here on relevant topics:
- ERC721 Rental idea discussion
- Lockable ERC721s
- EIP4907 “user” role and expiration metadata extension for ERC721