Whitelist of addresses that can create proposals

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

I am recommending @arr00 & @TylerEther to be added to the whitelist. @arr00 is a critical community member and has made significant contributions to the protocol and the entire DeFi ecosystem. @TylerEther is one of the few people to add an asset (LINK) to the protocol and is currently finalizing RFP 16 (split COMP rewards).

Both of them are “no-brainer” additions imo. I think the community multisig can add each of them; however, if people don’t like that, I will make an onchain proposal.

If someone speaks up and would rather a governance proposal add them, I’ll make it on Monday. Otherwise, the community multisig should add them on Monday.


Your protocol, your call.




Governance delegate address verification:

  "address": "0xc8A69971DAa3C3ADd85Ab0d0AF297515769ddfFC",
  "msg": "To: Compound Community Multi-sig\nDate: Monday, September 20, 2021\nTime: 15:08 PST\n\nThis address is controlled by TylerEther for the purpose of protocol governance.\n\nTwitter: https://twitter.com/tylerether",
  "sig": "0xd1eaeaec32cff436f30307b6557a17a6271585f0b81fa4ae60d4560a339addba4b544b4cae7f9b475890f71c53c67f8554e793f3ee73cc0aa8b58332fdfa5ff101",
  "version": "2"
1 Like

I’ll be using my existing governance address 0x2b384212edc04ae8bb41738d05ba20e33277bf33

1 Like