Lower Proposal Thresholds v2


Currently, the proposal threshold is 65K, which enables 12 addresses (excluding those on the whitelist) to make direct proposals to governance. Governor Bravo enables Compound’s community to change the proposal threshold (which was previously executed upon via Proposal 52 to reduce the threshold to 65K). Though there has been discussion on reducing the proposal threshold following Proposal 52 that fell through, we believe that over the past several months we’ve seen several key issues that warrant the community revisiting lowering the threshold.

  1. Current Compound delegates are unable to create CAPs (unless they own 100 COMP), and as such current delegates are unable to participate in governance. Additionally, any users below 100 COMP in holdings are unable to even create a proposal (CrowdProposalFactory contract).
  2. Current Compound delegates are unable to lend support to CAPs (as they can’t delegate delegated funds), effectively limiting the ability of delegates to participate in governance if they’re below the 65K limit.
  3. Compound users are not incentivized to participate in governance & token-holders feel a lack of ownership in Compound. At this time, we believe reducing the proposal threshold is an important step of many towards increasing governance participation & contributions by community members in the long-term by reducing the friction to create proposals.


We believe that the community should consider lowering the proposal threshold in order to increase the number of potential proposers & speed up the governance process. We’ve created a poll below that corresponds to potential voting thresholds and want to get community input on which proposal threshold Compound’s proposal limit should move to.

Potential Thresholds
65K (Current) => 12 Addresses
50K => 24 Addresses
10K => 41 Addresses
1K => 59 Addresses
100 => 75 Addresses

What should the new minimum proposal threshold be?

  • 65K (Current)
  • 50K
  • 10K
  • 1K
  • 100

0 voters

On January 14, if the community decides that Compound’s proposal limit should reduce from the current 65K (~$13M) limit, we (Blockchain at Berkeley) will take the result from this poll and put up a proposal that changes the minimum proposal threshold to the community-decided result.

We believe reducing the CAP threshold limit from 100 COMP (~$20K) to 1 COMP (~$200) would enable smaller token holders & delegates to be able to propose changes via autonomous proposals, but we believe this warrants more discussion (and consideration of potential negative implications) before being put to a vote.


Generally, we think lowering the proposal threshold to 50k is a good next step.

As for the CAP limit, 1 might be low, but we wouldn’t oppose it either since it is rather arbitrary and has little downside. The CAP contract is external to the protocol: CrowdProposalFactory | 0x54a06047087927D9B0fb21c1cf0ebd792764dDB8

1 Like

Generally supportive of this initiative but would prefer reducing the CAP threshold by ~1 order of magnitude at a time (~10 COMP). I haven’t looked closely at wallet data recently but suspect that, unlike the case at the very top, the number of eligible wallets jumps exponentially from 10^2 to 10^1 and then to 10^0.

1 Like

@allthecolors Because the CAP contract is external to the protocol anyone would be able to deploy a “new” CAP contract with the nonzero compStakeAmount that they wish (i.e. 10 COMP, 1 COMP, 0.1 COMP, etc.) As such, we’ll likely deploy a new CAP contract based off of consensus here on behalf of the community, but anyone could go ahead and deploy a new CAP contract if they wish to do so with a lower limit (w/ the disincentive being the contract deployment cost).

Based off of the poll, we’ll go ahead and move to put up a proposal in the next week that drops the proposal threshold to 10K & separately will be redeploying the CAP contract with @allthecolors suggested limit of 10 COMP.


Must say, thats a really good proposal by Blockchain @Berkeley
I’m pretty excited to see the governance process evolving with more opportunities Compound users to participate.

1 Like

Deployed the new GovernorBravoDelegate contract & passing sims as intended. Pending whitelist, will put up a proposal to reduce proposal threshold to 10K!


New GovernorBravoDelegate: GovernorBravoDelegate | 0x30065B703DE5d473975A2db5bBB790A23FD6EFbD

  • Reduced the minimum “setable” proposal threshold to 1K COMP

Worked off of @arr00’s tests for whitelisting users, and proposal passes as expected (with newly deployed GovernorBravoDelegate contract).

You can see the tests here, and the paste of successful output here!

I’ve opened a PR to reflect the updated GovernorBravoDelegate contract, the new simulations & updates to the ABIs.



After discussing with community members, we’ve decided to put up a proposal to reduce the threshold to 25K to be closer to the weighted average of the votes by the community. Proposal is live here!


This is a long-standing conversation in the community; the bar to creating proposals has been lowered multiple times (the introduction of Autonomous Proposals, lowering the threshold from 100k to 65k, and the introduction of a community-set whitelist), each time with the goal of making proposal creation more accessible while balancing protocol security.

To date, proposals with community support easily make it to the proposal stage; at this point, a proposal sponsor simply has to ask to be whitelisted for proposal creation. Case in point: this very same Proposal 89.

Lowering the COMP-based proposal threshold will make it easier for proposals like Proposal 84 (Coindesk article) to be introduced.

While I strongly agree with the goal of widening governance participation, I don’t believe this is the right approach. Introducing changes to a protocol that manages $10B+ is a high-stakes task, and following the Proposal 62 bug, one that I think should be made more difficult, not less. I will be voting against lowering the proposal threshold, and encourage the community to find new ways to expand governance participation.


With respect to @rleshner 's point, I am wondering what other measures could be taken to mitigate the protocol security concern, other than limiting those who can bring a proposal based on # of tokens/votes they control? Basically, how can we ensure that those risks that can/should be a concern that have been are addressed by the appropriate mechanism?