This EIP offers an alternative to Access Control Lists (ACLs) for granting authorization and enhancing security. A uint256 is used to store permission of given address in a ecosystem. Each permission is represented by a single bit in a uint256 as described in ERC-6617. Bitwise operators and bitmasks are used to determine the access right which is much more efficient and flexible than string or keccak256 comparison.
Special roles like Owner, Operator, Manager, Validator are common for many smart contracts because permissioned addresses are used to administer and manage them. It is difficult to audit and maintain these system since these permissions are not managed in a single smart contract.
Since permissions and roles are reflected by the permission token balance of the relevant account in the given ecosystem, cross-interactivity between many ecosystems will be made simpler.
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.
Note The following specifications use syntax from Solidity 0.8.7 (or above)
Compliant contracts MUST implement IEIP6366Core.
It is RECOMMENDED to define each permission as a power of 2 so that we can check for the relationship between sets of permissions using ERC-6617.
It is RECOMMENDED for compliant contracts to implement the optional extension IEIP6617Meta.
SHOULD define a description for the base permissions and main combinaison.
SHOULD NOT define a description for every subcombinaison of permissions possible.
Compatible tokens MAY implement IEIP6366Error as defined below:
Needs discussion.
First implementation could be found here:
Need more discussion.
Copyright and related rights waived via CC0.