Address Whitelist for Submitting Proposals
01Summary
Proposal to add a whitelist of contributor addresses (managed by community multisig) who can submit proposals without the standard 65k COMP delegation requirement, while maintaining the 65k COMP threshold for other contributors.
- Type
- governance change
Key changes
- Implementation upgrade to governance contract to enable whitelist functionality for proposal submission(high)
- Set whitelist guardian to 0xbbf3f1421D886E9b2c5D716B5192aC998af2012c to manage the contributor address whitelist(high)
- Exempt whitelisted addresses from 65k COMP delegation requirement for proposal submission(high)
- Community multisig to manage whitelist of eligible contributor addresses(medium)
Notable concerns
- Whitelist management concentrated in community multisig governance
- Potential for whitelist to create tiered access to proposal submission
- Code changes require security audit confidence given governance criticality
Generated by Kvorum
02Description
Address Whitelist for Submitting Proposals
Right now, to make a proposal, a contributor must have (or have delegated to them) 65k COMP. This threshold is a good spam deflection mechanism, but creates a burdensome hurdle for some contributors.
In additional to keeping the 65k COMP threshold, we propose including a whitelist of contributor addresses, managed by the community multisig, who will always have the right to submit proposals, regardless of the # of COMP delegated to them, relieving a pain point in the current contributor experience.
Arr00 wrote the updated code, wrote tests/simulations, and did a bug bounty program. The overall code change is relatively small.
Changes: https://github.com/compound-finance/compound-protocol/pull/149/files
Forum discussion: https://www.comp.xyz/t/whitelist-of-addresses-that-can-create-proposals/1996
03Mismatch analysis
A calldata-vs-description analysis is not generated yet. Review the decoded actions →
04Actions
- Target
- 0xc0da…6529
- Value
- 0 wei
- Function
- _setImplementation(address)
- Arguments
{ "0": "0x563A63d650a5D259abAE9248dddC6867813d3f87" }- Calldata
- Target
- 0xc0da…6529
- Value
- 0 wei
- Function
- _setWhitelistGuardian(address)
- Arguments
{ "0": "0xbbf3f1421D886E9b2c5D716B5192aC998af2012c" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| D50xd544…8772 | For | 306K | 0.00% | — | 5y ago |
| 660x6626…c35c | For | 126.1K | 0.00% | — | 5y ago |
| 880x88fb…3981 | For | 105K | 0.00% | — | 5y ago |
| 810x8169…9806 | Against | 101K | 0.00% | — | 5y ago |
| 540x54a3…e189 | For | 100.1K | 0.00% | — | 5y ago |
| 8D0x8d07…a265 | For | 77.5K | 0.00% | — | 5y ago |
| 9B0x9b68…2984 | For | 66.1K | 0.00% | — | 5y ago |
| 5B0x5bc9…d76c | For | 63.3K | 0.00% | — | 5y ago |
| 1D0x1d29…5d1f | For | 50K | 0.00% | — | 5y ago |
| 450x458c…730e | For | 50K | 0.00% | — | 5y ago |
| 070x0703…961b | For | 50K | 0.00% | — | 5y ago |
| 130x13bd…8548 | Against | 50K | 0.00% | — | 5y ago |
| 100x10f8…1f92 | For | 48.9K | 0.00% | — | 5y ago |
| 0A0x0a09…b92e | For | 15K | 0.00% | — | 5y ago |
| DAdakeshi.eth0xe3c9…6b21 | For | 14.8K | 0.00% | — | 5y ago |
| 2B0x2b38…bf33 | For | 7.7K | 0.00% | — | 5y ago |
| 580x582c…d468 | For | 6.6K | 0.00% | — | 5y ago |
| 520x5274…59d2 | Abstain | 4.8K | 0.00% | — | 5y ago |
| A50xa5dc…d648 | For | 3.3K | 0.00% | — | 5y ago |
| FC0xfc04…5ac2 | For | 2.3K | 0.00% | — | 5y ago |
| D20xd2cb…b9a9 | For | 900 | 0.00% | — | 5y ago |
| 840x84e3…5a95 | For | 151.5 | 0.00% | — | 5y ago |
| 3B0x3be3…e156 | For | 90.1 | 0.00% | — | 5y ago |
| 910x9140…3013 | For | 30 | 0.00% | — | 5y ago |
| 030x03f0…7618 | For | 25.1 | 0.00% | — | 5y ago |
| E80xe8d8…3f31 | Against | 1.7 | 0.00% | — | 5y ago |
| 880x88b3…1d42 | For | 0.3 | 0.00% | — | 5y ago |
| 8A0x8aba…7940 | For | 0.3 | 0.00% | — | 5y ago |
| 3E0x3e61…322b | For | 0.2 | 0.00% | — | 5y ago |
| 8A0x8aef…4bf8 | For | 0 | 0.00% | — | 5y ago |
| E20xe25d…2362 | For | 0 | 0.00% | — | 5y ago |
| DE0xdec2…4f36 | For | 0 | 0.00% | — | 5y ago |
| 530x5381…4149 | For | 0 | 0.00% | — | 5y ago |
| 6C0x6c51…76d3 | For | 0 | 0.00% | — | 5y ago |
| 620x6216…8c4c | For | 0 | 0.00% | — | 5y ago |
| 0F0x0f83…74f1 | For | 0 | 0.00% | — | 5y ago |
| BA0xba9e…56a4 | For | 0 | 0.00% | — | 5y ago |
| FF0xff21…f241 | Against | 0 | 0.00% | — | 5y ago |
07Forum
- Whitelist of addresses that can create proposals ↗discourse · high confidence
Arguments for
- Whitelisting lets trusted, high-value contributors (e.g., getty, arr00) submit proposals without repeatedly rallying 65k COMP, easing friction for frequent contributors.— JacobPPhillips, getty, arr00, rleshner, jmo
- A multisig-managed, time-limited whitelist (with expirations and renewal requirements) fits the spirit of governance while preserving high standards, since privileges must be earned and periodically renewed.— rleshner, arr00, JacobPPhillips
- The design carries low risk since the whitelist guardian only gains narrow cancel powers over sub-threshold whitelisted proposals, not broad veto authority, and spam risk is further limited by gas costs.— arr00, jmo
- The code implementation is elegant, well-tested (unit tests and forking simulations), and reviewers found no bugs, supporting technical readiness.— joeysantoro, elee, maxcwolff
- Community groups like Blockchain at Berkeley support the change as a way to reduce barriers for strong ideas from trusted contributors without altering core governance contracts significantly.— ratankaliani
Arguments against
- A single perpetual-CAP-style whitelist contract limits throughput since only one proposal can be active at a time, making it a non-scalable solution.— arr00, jmo
- Simply lowering the proposal threshold (e.g., to 100–1000 COMP) could achieve the same goal of broader proposal access without adding new whitelist infrastructure.— jacob
- A shared community concern (raised via an external Twitter thread) suggested unspecified long-tail security risks in the whitelist design that weren't fully addressed in the proposal.— JacobPPhillips
- Alternative architectures—such as a single non-factory Autonomous Proposal contract with community-delegated voting power, or subDAOs empowered to adjust specific parameters—might better balance flexibility and community control than a whitelist on the core governance contract.— dennison, jmo
Unresolved concerns
- Whether governance itself or the community multisig should ultimately control the whitelist was debated without full consensus, though multisig control was adopted by default.— dennison, JacobPPhillips, rleshner
- Long-tail security risks flagged in an external Twitter discussion were acknowledged but not concretely resolved beyond proposing possible future mitigation steps.— JacobPPhillips
- Whether the whitelist guardian should have the ability to transfer/upgrade its own power was questioned and only partially addressed by restricting such changes to future governance proposals.— joeysantoro, arr00
- Whether adding on-chain whitelisting introduces new security assumptions about whitelisted addresses compared to alternative off-contract designs was raised but not fully settled.— dennison
- Whether the proposal threshold or quorum should be separately lowered as a complementary or alternative reform was raised but tabled as off-topic for a future thread.— jacob, joeysantoro
Notable participants
- JacobPPhillipsOriginal proposer who framed the problem, proposed the whitelist framework, and raised later risk considerations.
- arr00Lead technical implementer who designed, coded, tested, and iterated on the whitelist feature based on community feedback.
- gettyKey contributor whose situation motivated the proposal; provided implementation input and later nominated whitelist candidates.
- rleshnerCore governance voice who endorsed the idea and suggested multisig-based whitelist management.
- dennisonRaised alternative architecture concerns about contract-level whitelisting and security assumptions.
- jmoProvided balanced support while highlighting scalability limits and suggesting alternative governance mechanisms.
- joeysantoroReviewed the code, raised design questions, and expressed cross-community interest (Fei).
- eleePerformed detailed code review and suggested readability improvements that were incorporated.
- jacobProposed an alternative simpler solution of lowering the proposal threshold instead of whitelisting.
- maxcwolffReviewed the pull request and confirmed no bugs, expressing support for the proposal.
Generated by Kvorum
08Similar proposals
- compoundexecutedLower Proposal Threshold to 25K COMP69%
- compoundcanceledLower Proposal Threshold to 10K COMP68%
- compoundexecutedLower Proposal Threshold to 65,000 COMP68%
- compoundexecutedAdd Proposal Guardian to Governor Bravo63%
- compoundexecutedRenew Proposal Guardian Role for the Community Multisig62%
- compoundexecutedRenew Proposal Guardian Role for the Community Multisig62%
- compoundexecutedExtend Proposal Guardian Role for the Community Multisig62%
- compoundexecutedCompound Governor Contracts Upgrade61%
- compoundexecutedMigration to Governor Bravo60%
- compoundcanceledThis proposal will upgrade Compound's GovernorBravoDelegator and GovernorBravoDelegate contracts. We'll use the latest contracts from OpenZeppelin(OZ) library with some modifications to preserve many…59%