Options for implementing whitelisting

[adamgall]

This applies only to token voting DAOs, so Azorius is a given.

Azorius is implemented as a Zodiac Module. In Zodiac, Modules (much like a Safe itself) can have a "guard" added to it. The Zodiac modules and guards patterns follow the same interface as Safe itself, so it's simple to extend their concepts up a level.

The first option this presents us is the ability to add a new guard to Azorius. This Guard contract could reference a whitelist, and allow or disallow a proposal from executing based on if the msg.sender of the proposal that's attempting to execute was submitted by someone who was on the whitelist at the time of proposal creation.

Typing this out, it seems pretty far fetched that we'd be able to reference all of that information onchain. I doubt that guard contract will have the necessary context to know the address of the proposal submitter, and the block/timestamp of when the proposal was submitted.

The second option seems more achievable.

Take advantage of STRATEGIES. The Azorius contract utilizes a pattern of multiple "strategies" which can be added to a given Azorius instance. When a proposal is created, the proposer chooses which strategy to utilize for the given proposal.

The strategy is responsible for 3 things:

1. Determining if the given address is even allowed to create a proposal using this strategy.
2. Determining who can vote for the given proposal, and when, and how.
3. Determining if a given proposal has passed or not (based on the aforementioned voting results)

We can write a new strategy(s) to implement whitelisting, which is covered by the first of the three responsibilities of a strategy contract: deciding if a given address is allowed to create a proposal.

There are different "configurations" that a Safe might be in, with regards to how they approach proposal creation restrictions.

Pre whitelist functionality, there are 2 configurations. They are:

1. Anyone can create a proposal
2. Only addresses holding at least the threshold amount of voting tokens can create a proposal.

After whitelist functionality, they will be:

1. Anyone can create a proposal
2. Only addresses holding x number of tokens
3. Only addresses on whitelist
4. Only addresses both holding x number of tokens and on the whitelist
5. Only addresses either holding x number of tokens or on the whitelist

The different strategies that are on an Azorius instance, and the way they're configured, must cover cover each of the above use cases.

After actually writing and deploying this new strategy, we'll need to get DAOs to utilize the correct combination of strategies on their DAO for whatever configuration they want. This will require frontend code to dynamically attach/detach and configure strategies as users go through their DAO's settings adjustment flows.

[adamgall]

Currently, our frontend codebase only expects/supports a single strategy per Azorius.