Shared Whitelist TM

[F-OBrien]

Please check if the PR fulfills these requirements

• [x] The commit message follows our Submission guidelines
• [x] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

New Transfer Manager that allows an issuer to attach an external whitelist dataStore. This allows an issuer with more than one token to share a whitelist between multiple tokens or to use a whtelist maintained by an external provider.

(Note: Due to current methods used to call flags e.g. isAccredited and Can not buy from STO these need to be managed on the token specific DataStore and not the shared whitelist.)

What is the current behavior?

Token specific whtelisting only

What is the new behavior?

Support external and internal whitelists at the same time

Does this PR introduce a breaking change?

No

Any Other information:

[F-OBrien]

Just another note on this. If the address is whitelisted on the attached external whitelist but the issuer does not have access to edit it, or if they wish to restrict transfers for one specific token, that address would need to be added to a token specific blacklist. This could be done with the BlacklistTM but that possibly makes it a bit more complicated than needed. Another option to blacklist the address could be to add a blacklist to the SWTM contract or blacklist flag could be added to the investor flags which can be checked during transfer.

[maxsam4]

If the address is whitelisted on the attached external whitelist but the issuer does not have access to edit it, or if they wish to restrict transfers for one specific token, that address would need to be added to a token specific blacklist. This could be done with the BlacklistTM but that possibly makes it a bit more complicated than needed. Another option to blacklist the address could be to add a blacklist to the SWTM contract or blacklist flag could be added to the investor flags which can be checked during transfer.

I think using BlacklistTM is fine for it. That's literally what BlacklistTM is meant to do :).

We can obviously develop custom modules later that combine use cases of multiple modules if an Issuer wants. The Issuer can even have the modules developed by third-party developers :)

[F-OBrien]

@F-OBrien This is an impressive start! Thanks for pushing this.

I have left a couple of comments and the other thing I'd like you to do is split this and GTM into a base contract and individual contracts that extend that base contract to reduce code redundancy (how we have used DividendCheckpoint.sol for both Ether and ERC20 dividends modules).

EDIT: I realized that you are already doing what I wanted so marked the comments as resolved :).

Can you please refactor this as I mentioned above? There's no hurry as code cut has already been done for 3.0 and this module will be part of next release only.

Thanks for the feedback. I'll look into the refactoring over the next few weeks.

Actually the refactoring would help with another TM I had an idea for. I felt some of the features in the GTM don't fit there very well like the flags. They are set there but not used by the module. What I was considering (actually started work on but parked it) was a Flag Transfer Manager.

Outline functionality as follows: Restrict transfers based on flags with the following options:

• Always restricted flags (i.e. if any one of these flags are set the transfer is always invalid, held in a single restricted flag register/bit mask for comparison with investor flags)
• Restricted combinations (i.e. if a specific combination of flags is set the transfer is invalid, with the ability to add multiple restricted combinations)
• Required Combinations (with options) (i.e. transfer is N/A only if any one of the combinations in a group of combination options is true) e.g. you could have a US investor flag and accredited flag. You could allow only US and accredited OR Non US and accredited OR Non US and non accredited (I know you could just say US and non accredited is restricted instead but just giving a simple example with two flags more complex combinations could be used).
• Flag count restrictions (i.e. limit the number of holders with a specific flag) e.g. limit number of non accredited investors.

This module would allow for more complex conditional restrictions as more flags are assigned. Yes an issuer could just not whitelist those that they don't want to hold the token but if you are using a shared whitelist it may be more important to have more flexibility to restrict users based on specific attributes.

If interested I can take another look at it.