KVORUM
compoundSource: Compound governor bravo · #60

Address Whitelist for Submitting Proposals

executedSep 15, 2021, 06:46 PM UTCbyD50xd544…8772

01Summary

AISummary by Kvorumclaude-haiku-4-5

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
Contracts0xc0da02939e1441f497fd74f78ce7decb17b66529
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

112 words

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

AIMismatch analysis by Kvorum

A calldata-vs-description analysis is not generated yet. Review the decoded actions →

04Actions

2 total
#0_setImplementation(address)chain 0x1
Target
0xc0da…6529
Value
0 wei
Function
_setImplementation(address)
Arguments
{
  "0": "0x563A63d650a5D259abAE9248dddC6867813d3f87"
}
Calldata
#1_setWhitelistGuardian(address)chain 0x1
Target
0xc0da…6529
Value
0 wei
Function
_setWhitelistGuardian(address)
Arguments
{
  "0": "0xbbf3f1421D886E9b2c5D716B5192aC998af2012c"
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total
Filter:
VoterChoice% of totalRationale
D50xd544…8772For306K0.00%—5y ago
660x6626…c35cFor126.1K0.00%—5y ago
880x88fb…3981For105K0.00%—5y ago
810x8169…9806Against101K0.00%—5y ago
540x54a3…e189For100.1K0.00%—5y ago
8D0x8d07…a265For77.5K0.00%—5y ago
9B0x9b68…2984For66.1K0.00%—5y ago
5B0x5bc9…d76cFor63.3K0.00%—5y ago
1D0x1d29…5d1fFor50K0.00%—5y ago
450x458c…730eFor50K0.00%—5y ago
070x0703…961bFor50K0.00%—5y ago
130x13bd…8548Against50K0.00%—5y ago
100x10f8…1f92For48.9K0.00%—5y ago
0A0x0a09…b92eFor15K0.00%—5y ago
DAdakeshi.eth0xe3c9…6b21For14.8K0.00%—5y ago
2B0x2b38…bf33For7.7K0.00%—5y ago
580x582c…d468For6.6K0.00%—5y ago
520x5274…59d2Abstain4.8K0.00%—5y ago
A50xa5dc…d648For3.3K0.00%—5y ago
FC0xfc04…5ac2For2.3K0.00%—5y ago
D20xd2cb…b9a9For9000.00%—5y ago
840x84e3…5a95For151.50.00%—5y ago
3B0x3be3…e156For90.10.00%—5y ago
910x9140…3013For300.00%—5y ago
030x03f0…7618For25.10.00%—5y ago
E80xe8d8…3f31Against1.70.00%—5y ago
880x88b3…1d42For0.30.00%—5y ago
8A0x8aba…7940For0.30.00%—5y ago
3E0x3e61…322bFor0.20.00%—5y ago
8A0x8aef…4bf8For00.00%—5y ago
E20xe25d…2362For00.00%—5y ago
DE0xdec2…4f36For00.00%—5y ago
530x5381…4149For00.00%—5y ago
6C0x6c51…76d3For00.00%—5y ago
620x6216…8c4cFor00.00%—5y ago
0F0x0f83…74f1For00.00%—5y ago
BA0xba9e…56a4For00.00%—5y ago
FF0xff21…f241Against00.00%—5y ago
Showing 38

07Forum

AIForum synthesis by Kvorumclaude-sonnet-5
sentiment · favorablethread · constructive

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
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Open the thread ↗