Hey @Daniel-K-Ivanov ,
Thanks for your feedback, I share your concerns that this current proposal is too limited to the rental use case and that it will benefit from having a more customizable role definition.
I saw you were discussing interesting ideas with @ilanolkies in ERC-4400: ERC-721 Consumer Extension about how to define roles more generically.
I tried to come up with a new design that intends to merge the 2 ideas:
Allow arbitrary roles to be granted
Delegating the role permission management to another contract IERC721RolesManager
so that roles terms and agreements can be honored on-chain.
Here is the PR that also has an example about we would implement define the Renter role:
comitylabs:master
← comitylabs:roles
opened 08:13PM - 21 Mar 22 UTC
Introducing 2 new interfaces `IERC721Roles` and `IERC721RolesManager` inspired f… rom the feedbacks from [ERC-4400: ERC-721 Consumer Extension](https://ethereum-magicians.org/t/erc-4400-erc-721-consumer-extension/7371) and [ERC721 extension to enable rental](https://ethereum-magicians.org/t/erc721-extension-to-enable-rental/8472).
This aims to provide a general framework to define token roles with on-chain guarantees that roles attribution terms are fulfilled.
**IERC721Roles**
- Enables to define ERC721 user roles by tokenId. We expect standard nomenclatures for roles to be defined such as `bytes4(keccak256("ERC721Roles::Renter"))`.
- Applications will call `roleGranted` to check whether a user has been granted a specific role.
- The role attribution logic is delegated to an `IERC721RolesManager` contract, that is set at the tokenId level. Note that we could have implementations where the role manager contract is defined at the ERC721 contract level to guarantee that roles definitions are consistent across each token.
- Token's`owner` is never changed and can be updated independently from the roles
**IERC721RolesManager**
- This contract holds the logic and terms to acquire and revoke roles.
- It guarantees that roles are honored on-chain, by using callback `afterRoleRevoked` and `afterRoleGranted` when someone tries to update a role.
- The IERC721RolesManager is set at the tokenId level in this example, but we could have one unique role manager contract for all tokens as mentioned above.
- When someone tries to update the IERC721RolesManager contract, a callback is made to `IERC721RolesManager.afterRolesManagerRemoved` so that the manager can revert if a role agreement is ongoing.
Examples:
See `ERC721Roles` and `ERC721RolesRentalAgreement` for examples of implementation.
The later is a simple contract to allow NFT rental by granting Renter role
**IERC721Roles & IERC721RolesManager interactions**
<img width="1018" alt="Screen Shot 2022-03-24 at 2 07 34 PM" src="https://user-images.githubusercontent.com/24436667/159982043-71e4a454-23c0-4b26-8e41-884f5fa5bcc3.png">
Happy to collaborate on this idea
1 Like