(from https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1292)

The old (pre 2.0) contract changed significantly in the migration to the Roles paradigm: whitelisted accounts were now able to, in turn, give the whitelistee role to other accounts. Because of this, it was removed from the release.

We should settle on a new design, that addresses the following requirements:

  • whitelisted accounts have no special role-related powers (i.e they cannot add or remove other accounts to the whitelisted set)
  • whitelisters can add accounts to the whitelist, and remove them from it

It is not clear if the whitelisters should be able to add other accounts to the whitelisters set. I'd go with the standard Roles approach and allow them to add accounts, but not remove. If needed, this power can be easily removed with

contract WhitelisterRoleNoAdd is WhitelisterRole {
  function addWhitelister(address account) public {

There's also the question of whether a Whitelistee is also a Role, or if it is simply a mapping of address to booleans. If it were a Role, it'd be different from the other ones in that the add operation should be internal instead of public (alternatively, we could couple Whitelistee and Whitelister and make addWhitelistee onlyWhitelister). This may be an interesting case to experiment on.

1 Like

I don’t think “whitelisted” should be a role. I think all roles should have the same default interface, and that includes the public add operation. So it should be a simple mapping.

We shouldn’t lose sight of the fact that this feature is motivated by legal requirements of some real-world contracts. @nventuro do you remember the details? I wonder if the peculiarities of whitelisters being a role are compatible with those legal requirements.

They aren’t, which is what I meant by add being internal (like remove). It may be worthwhile to explore having a Role with a subset of the standard interface, to reuse the ‘simple mapping’ operations in Roles (add, remove, is), along with their safety checks (no operations on the zero address, remove requires is, etc.).

Hm, I see the value in reusing the operations in Roles, yeah.

An interesting point is what this could mean for the proposed autogeneration mechanism for role contracts: the Whitelistee's add function behaves differently than the others, in that only Whitelisters can call it. Some sort of parametrization might make sense, e.g. for the add function, which roles are allowed to call it (the same one by default).

Additionally, we wouldn’t want the contract creator to be assigned the Whitelistee role during construction, so that’s another point where they diverge.

edit: I created a separate topic to discuss this: Role contracts autogeneration

I just noticed that, according to @mjdietzx here, Whitelisters being able to remove the role from a Whitelistee is a non-optional requirement, which is yet another difference from the roles we already have.

This is what the final design ended up looking like: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1525

  • Whitelisters are a regular role
  • The Whitelisted role is different from the other ones, it is managed by Whitelisters, who can add and remove accounts at will
1 Like