Hello,
I was wondering why the consumer should be reset to address(0) when there is a transfer.
Wouldn’t it make more sense to default it to the owner’s address?
I have in mind projects who refer to the consumer address to give out benefits, like airdrops or whatever. I guess it would make more sense for the owner to be the default consumer when he/she isn’t renting out the token.
Cheers,
Aloys
Hello @MissieBish
The proposed design clears the consumer address similar to why approved addresses for a given tokenId are cleared on transfer. We wouldn’t want to keep the same consumer on transfer since it is an attack/exploit vector to the new owner of the tokenId.
Do you think that ERC4400 must specify the address to which consumer must be updated on transfer? I am citing this:
On every transfer, the consumer MUST be changed to the zero address the same way approve address is changed.
I think that if we enforce the default address to which we must change the consumer on transfer we will be again enforcing a rule that might not fit every use case. F.e some projects may want to provide the utility of the NFT to both the owner and the consumer, but projects may prefer NOT to provide the utility of the NFT to the owner but only the consumer. That being said, I think that we can update the spec in the following way:
On every transfer, the current consumer MUST be changed to a default address. It is RECOMMENDED for implementors to use `address(0)` as that default address.
Hello Daniel,
Thank you for your reply.
To answer your question, I do not think that the updated consumer address should be specified on transfer. It could have unwanted ramifications (for example, a borrowed nft could be returned to the original owner with a modified consumer address).
I think your proposed modification to the spec is very appropriate, it does give more flexibility to ERC4400 implementations to fit their intended needs more closely (I have a real life example in mind: I rent a flat, my landlord sells the flat, I’m still the renter of that flat despite the new owner. A land register ERC4400 can deal with that under your proposed modified spec).
All the best,
Aloys
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:
And other discussion threads here on relevant topics:
