Implement ERC-6366: Permission Token and ERC-6617: Bit Based Permission

[chiro-hiro]

🧐 Motivation

Special roles like Owner, Operator 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 place. This made difficulty to handle cross-interactive or manage a complex system.

ERC-6366 reflected address's permission by the permission token balance of the relevant account in the given ecosystem, cross-interactivity between many ecosystems will be made simpler and secure with the ability to grant/revoke/delegate mechanism.

ERC-6617 will be used to pack multiple permissions in one single uint256 make permission checking and update efficiently in term of gas cost.

📝 Details

I'm going to implement ERC-6617 and ERC-6366 in a separated pull request if you think it worth a try.

[Amxx]

Hello @chiro-hiro

ERC-6617 looks very similar to AccessManagerLight that we have in the community repository. This is a "light" version of the AccessManager contract that support 256 roles (including one public role, and one admin role, so actually 254 configurable roles). It implements the IAuthority interface.

If you want to permission an ERC20 based on this, you can use the AccessManager helper contract to link to that AccessManagerLight.

This method of doing access permission is standard to OZ contract, and is upgradeable in the sens that the AccessManagerLight can later be replaced by a full AccessManager if needed.

Spiko uses that combon in productions: Token, Manager.

I'm not sure why people decided to come up with these ERC, but it feels like "one more standard" that is just going to confuse devs as to "what they should use", without providing any feature that is not currently supported by existing systems.

I'd personally pass on implementing these unless we get multiple independant requests by teams that have strong usecases for using this over what we already have.

[chiro-hiro]

Hi @Amxx,

I agree with you that you can wrap permissions with ERC20 and then link them with AccessManagerLight. It will work without ERC6366. However, the point of an ERC is to standardize the interface.

We could reuse ERC20, but that would create confusion for users. They may not realize they are approving/transferring a permission token since the interface looks the same. Existing wallets would recognize the permission balance just like a normal token balance, which leaves users vulnerable.

ERC6366 is not really an “improvement,” but it does separate the interfaces for fungible tokens and permission tokens. That separation reduces confusion and risk.

If you compare of ERC6617 with AccessManagerLight, ERC6617 is more simple:

• Gas cost efficiency
• Describe permission to human readable, with metadata interface

I'd personally pass on implementing these unless we get multiple independant requests by teams that have strong usecases for using this over what we already have.

So we go with, being popular enough to be a standard?

[codebyankita]

Hi @chiro-hiro,

Thanks for raising this. I see the value in ERC-6366/6617, especially the idea of separating permission tokens from ERC20 to avoid user confusion and the efficiency gains from bit-packing roles. At the same time, OpenZeppelin already provides AccessControl and AccessManagerLight, which cover most of these use cases today with well-tested patterns.

From a best-practice perspective:

Clarity – separating permissions from ERC20 makes sense conceptually. Efficiency – bit-based permissions are already achievable with AccessManagerLight. Adoption risk – since ERC-6366/6617 are still draft and not widely used, adding them now may fragment the ecosystem.

For now, I’d recommend sticking with AccessManagerLight or AccessControl, while keeping an eye on whether these ERCs gain real adoption. If they do, standardization could be very useful.