Whitelist of addresses that can create proposals

Are we thinking a change on the contract itself to whitelist addresses? And while I’m sure everyone that would be whitelisted is trustworthy, would adding this on the contract require some sort of security assumptions about the whitelisted addresses?

What if we just rebuilt the Autonomous Proposal contract to be a single contract (not a factory) that accepts proposals from only a whitelisted group of individuals, but then the larger comp community can delegate their voting power to this contract.

Governance would be responsible for adding or removing whitelisted addresses, but the community would still be responsible for delegating their voting power to the contract itself. This way if the community were to lose faith in the white listed individuals, it would be easy enough to remove delegation power.

I get that rounding up the delegated votes is tricky, but I think folks would be up for doing it once to a single contract, and I like the social dynamic more than making a chance on the governance contracts themselves.


I think @arr00 originally envisioned something not far off from this. I believe the idea was to create a sort of perpetual CAP with a whitelist of possible proposers that would allow anyone on the whitelist to use the COMP delegated to the CAP to create a proposal (so like Polychain could have its own whitelist, Robert could have his own, blck could have their own, etc. and then there could be community pools with separate whitelists).

One issue related to the current way CAPs work IIRC: I think certain community members should always have the freedom to propose things to the community, but we may not always agree with them (or would like token holders to have veto power), so letting them always use capital in a CAP to propose & vote would not be ideal.

Creating the whitelist within the governance contracts seems to be the simplest way to do this and sufficient from a security perspective with the help of the community multisig.


We at Blockchain at Berkeley are in support of this - Arr00 & Getty are fantastic contributors to the protocol, and I see this as a great way to reduce barriers for strong ideas to be put in front of the Compound community. Agreed with @JacobPPhillips here, I believe that leveraging the multisig and the format @arr00 put together strikes a balance by enabling trusted contributors to put forward proposals in a way that doesn’t require significant changes to existing governance smart contracts.


I think this is a great idea and was my original idea; however, the limitation on throughput is quite significant. A single proposer, as this contract and its subsidiaries would be considered, can only have one proposal at a time. As such, it is definitely a solution that does not scale. Once we start to try removing the restrictions for this one contract, we should go the more direct route currently being take.


This proposal is a step forward to incentivize contribution to Compound. @Arr00 has made an invaluable contribution to Compound with Governor Bravo and other changes and it makes perfect sense for governance to allow him to add proposals w/o going through the tedious CAP process. On top of this, the risk of giving people these permissions is low - mostly just proposal spam, which is unlikely and further mitigated by gas costs.

While its valuable for token holders to enable more progress within the protocol between votes, I think the impact this change is quite small at the moment. Arr00 mentions this as well - “the limitation on throughput is quite significant”. We might want to consider other changes that would give power to the community, but would more directly target specific use cases. For instance, allowing a specific group of people (e.g. a subDAO) to change a subset of parameters. You could imagine an Interest Rate Group that could change IR curve for different assets (within some limits). This would allow the the community to increase its pace of contribution, probably even more so than via address whitelisting. At the same time, this would continue to enable the helpful restrictions on protocol changes that governance currently provides.

On @getty’s community call, @JacobPPhillips mentioned this would be hopefully the first of many changes to increase the speed of Compound governance. We’re looking forward to continue the discussion and work with the community to see this come to fruition.


I’m approaching completion with the engineering work for this project and would like to provide an update on the technical details of the implementation. This is the first update to the Governor Bravo implementation and acts as an example of how to update the Governance system.

At a high level, the new features allows for governance or the community multisig to set whitelist status expirations for any account. It was done with this format to introduce a concept of a term to governance. Users are granted special permission for a limited time and need to actively participate and perform to have their special status renewed. This term is set as an expiration timestamp after which their special whitelist status expires.

Due to the whitelist status, whitelisted proposals can’t be canceled for falling below the proposal threshold, so as a safety precaution, the community multisig will be able to cancel these proposals. It is unlikely that this feature will ever be used. The community multisig does not receive unlimited veto powers—it is only able to cancel proposals from users with less votes than the proposal threshold.

Technical Details

You can view the code changes here.

I have opted to create two new stored values:

  1. whitelistAccountExpirations - an array of timestamp expirations for the whitelist status of each account. An account is whitelisted if now < whitelistAccountExpirations[msg.sender].
  2. whitelistGuardian - an address which is in charge of monitoring and setting whitelisted accounts. The whitelistGuardian will initially be the community multisig. The whitelistGuardian is able to add and remove whitelistedAccounts and cancel proposals by whitelisted accounts. The guardian is unable to cancel a proposal by an account which meets the proposal threshold.

There are three new functions:

  1. isWhitelisted(address account) - isWhitelisted returns a boolean value of whether an account is whitelisted. This logic is isolated into its own function for readability.
  2. _setWhitelistAccountExpiration(address account, uint expiration) - setWhitelistAccountExpiration stores a new expiration for a given account’s whitelist status. An expiration of 0 removes the account from the whitelist. This is a permissioned function callable by governance and the whitelistGuardian.
  3. _setWhitelistGuardian(address account) - This function sets the whitelistGuardian. It is a permissioned function only callable by governance.

There is extensive testing done through scenario unit tests here along with a forking simulation here. I do not consider this code frozen yet, but in the coming days I hope to finish and begin a bug bounty.


I took a look at the code overall it looks great and elegant. Why not allow the whitelist guardian to upgrade itself? Not a huge deal but just to understand the reasoning.

I’m sure the Fei community would be interested in a feature like this as well.


Thanks for taking a look at the code! I think generally we should restrict the power of external accounts to allow only the intended powers. I don’t see a situation where the multisig should be transferring this power to another address. If the community decides to transfer this power to someone else, that should be another proposal.


plz give me whitelist, like I would create spicy proposals


I deployed the new governor implementation to kovan here. It is currently the implementation of kovan governance which is here. It is working as expected.

1 Like

hi @arr00 , nice to meet you. I was wondering if I could get a letter of recommendation to get whitelisted for proposals. Please and thank you, Sam.

attached is my resume and GitHub

I’ve created a PR adding the code for this feature. Any feedback on the code would be appreciated at this point and bugs found will be rewarded. As of now, I am not planning on getting this change audited—It is fully covered by new unit tests and a forking simulation. The perceived risks from adding this feature is quite low.


when i was reading through the code, the if-else require statement in the cancel function sorta broke my

head cuz it was a really long hard to read line

the most confusing part to me was the fact that the require statement was like a || (b && c).

i think this is functionally equiv and seemed a bit easier to read, correct me if im wrong tho

if(msg.sender != proposal.proposer){
	if(isWhitelisted(proposal.proposer)) {
		require((comp.getPriorVotes(proposal.proposer, sub256(block.number, 1)) < proposalThreshold) &&	
		msg.sender == whitelistGuardian,
		"GovernorBravo::cancel: whitelisted proposer");
	}else {
		require((comp.getPriorVotes(proposal.proposer, sub256(block.number, 1)) < proposalThreshold),
		"GovernorBravo::cancel: proposer above threshold");

another thing that is equally pedantic so feel free to ignore me - since you added the events in govbravoevent, maybe it would be good to add a fetcher for isWhitelisted in GovernorBravoValue?

everything looks good to me, i hesitate to say otherwise cuz neither of these are really issues or problems haha


Great points on both. I like your format better as it eliminates the double check for msg.sender == proposer. I’ll update the PR accordingly.

Thanks so much for taking a look and giving feedback!


If the goal is to give more people the ability to submit proposals, why not simply lower the proposal threshold to 1000 or even 100?

Maybe i’m missing something, but if Quorum is still 400k what’s the actual danger of a bad proposal?

It could spam the UI, I think 1000 is too low of a bar for on-chain proposals, especially all at once. Signal votes are great for having super low barriers to entry. I do think proposal threshold could be lowered to something like 10-30k COMP though as a start.

It would be interesting to consider lowering quorum to be much less prohibitive perhaps 100-200k COMP. This would force large holders to play a more active role potentially leading to more failed votes than we currently see. @getty was mentioning on the community call he’d like to see more proposals fail which is an interesting heuristic that shows faster iteration on the governance side.

This is a bit off-topic so if there is general interest in the idea of lowering thresholds we should spin up another thread


This prop should be ready to submit on-chain early next week.

To simplify and reduce bias in the decision process, here’s a possible framework for how the multisig would manage the whitelist:

  • Any contributor who wishes to submit a proposal that has gone through the full off-chain governance process (community feedback, temperature checking, testing & peer review — to be more defined later) should be whitelisted for a short period of time (1 week) to submit a single proposal.
  • Active contributors — defined as those who have been a core contributor on at least 2 successful proposals OR those who are salaried by the DAO — may be whitelisted for an extended period of time.
  • Extended whitelisting will start at 3 months. Upon completion of this period, if the contributor has upheld community governance standards and continues to be an active contributor, they may have their whitelisting renewed for 6 months, and subsequently 12 months (max term) at the discretion of the multisig.
  • If a whitelisted contributor fails to uphold community governance standards, this contributor should be removed from the whitelist.

The community multisig is welcome to flex/update this framework as they see fit. This exact framework isn’t a fundamental part of this proposal; it’s merely meant to offer some initial guidance for the community multisig on how to use the newly granted power.


reviewed Add Governance Whitelist Users Feature by arr00 · Pull Request #149 · compound-finance/compound-protocol · GitHub, no obvious bugs stuck out to me, seems to do what it says.

id personally vote yes


I’ve added post deploy and post propose simulations which sanity check the proposal. Everything checks out.


This thread highlights some potential risks not clearly outlined in this proposal. It’s worth having a look.

I still feel confident that this is the right path forward, in light of these long-tail risks. However, if others feel differently, I just want to highlight the possible steps we could take to alleviate these concerns.

  1. Have a vote to remove the whitelist functionality (revert back to standard COMP gov bravo with only a 65k COMP threshold for proposals)

  2. Change the whitelist guardian to COMP governance, allowing token holders to control the whitelist

  3. Revamp and/or expand the size of the multisig to enhance it’s security