Is there a need for a MinterAdminRole in OpenZeppelin?

When developing Peepeth badges with @bbarton for https://peepeth.com there was a concern that the MinterRole allowed an existing minter to add additional minters, and if the minter was compromised there was no way to prevent additional minters being added or the number of tokens that could be minted.

In the end we used Ownable as a Minter admin and only the owner could add minters. Also we allowed the owner to renounce a specific minter. Though in retrospect it would have been nicer to create a MinterAdminRole (similar to WhitelistAdminRole). We also didn’t add any limits on the number of tokens that could be minted.

Since this was deployed, Looking at the Centre fiat contract they have a master minter and each minter has an allowance of tokens that they can mint.

My question is there a need for a MinterAdminRole in OpenZeppelin?

Interested to hear your thoughts. The answer might be that the existing MinterRole meets the majority of projects needs and there isn’t a requirement to add complexity to this, when individual projects could create contracts to meet their specific needs if they need something different.

1 Like

This has been brought up multiple times: a similar argument could also be made for an admin of accounts that can pause a contract, whitelist users, etc.

I think the key point is this one:

What if the admin is compromised? At the end of the day, there’s no getting around the issue of “if one of the critical accounts is compromised, we’re in trouble”.

I’d simply recommend having better security practices (the same ones you’d use for the admin account), as opposed to treating accounts with special roles lightly. After all, if such an account is compromised, odds are it’ll be used to cause irrecoverable damage before you’re able to use your admin powers.

1 Like

Thanks @nventuro

Great to have your recommendation.

I actually think that an admin is a good idea in that it allows you to contain the damage caused by an attack. If an attacker gains control of a minter key, you could later renounce this key, but if the attacker added their own key as a minter, there is nothing you can do about it.

Perhaps to mitigate that we can make it so that an account can remove all the accounts that it added, and so on? The implementation of that seems complex though.

1 Like