A number of key community members lack sufficient COMP to create governance proposals. We want to keep the proposal threshold high to avoid spam but also want to create a smooth governance experience for those dedicating time and effort to improving the protocol. Gaining sufficient delegation to a CAP isn’t a huge issue for one-off proposals/contributors but is more of a hassle for frequent contributors.
For example, Compound is now paying @getty indefinitely for contributing to the protocol but still requires him to rally 65k COMP to propose an improvement. Assuming Getty is the first of many contributors that have longer-term economic relationships with the Compound Protocol, it may make sense to grant these individuals special privileges in governance (namely, the right to propose).
One solution: create a whitelist of addresses that can create proposals. Rather than just checking to see if an address has 65k COMP delegated to it, we could also check to see if the proposer’s address is on a whitelist of trusted community contributors, allowing them to sidestep the COMP requirement.
@arr00 took the lead on ironing out the implementation details of this. The code below allows addresses to be whitelisted for a specified period of time, after which the special authority expires.
Who manages the whitelist — governance or a multisig?
Proposals from whitelisted addresses can’t be canceled for falling below the proposal threshold, so perhaps we allow a multisig to cancel proposals from whitelisted proposers?
Admittedly, this is a pretty minor possible improvement on the governance process (and there are some hacky ways to accomplish a similar result), but the bigger point here is that we should be empowering key community contributors with the tools they need to contribute actively to the Compound Protocol (a mix of funding, resources, privileges, etc).
Awesome idea! It can be frustrating trying to get the votes necessary to pass a CAP. This could be a great way to fuel Compound governance while we are still in the early stages.
I think governance should manage who is on the whitelist, and the community multisig can have cancel power. Canceling should only be done at the proposer’s request.
I am in the process of trying to get 65k votes (I have ~11k rn) so I can propose myself. There are many low-hanging items the protocol should be maintaining/adding, but due to my limited ability to create proposals, I tend to pick one big improvement/issue at a time. If I add the ability to create proposals, I would likely almost always have something going through governance.
PS: Very cool to see Polychain and arr00 working together.
I think this is a great idea to help bolster community efforts and allow core contributors to improve the protocol with less overhead work. I’ll keep working on this and update the community along the way.
The proposal threshold (now 65,000 COMP) was designed as a tool to prevent hasty or malicious proposals from entering the voting process.
Whitelisting known / trusted / experienced contributors fits the spirit of governance, while maintaining the high standard that needs to be demanded of governance proposals broadly.
This is a creative idea that I am excited to support; in terms of implementation, empowering the community multi-sig to whitelist addresses (rather than the complete governance process each time) makes sense.
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.
whitelistAccountExpirations - an array of timestamp expirations for the whitelist status of each account. An account is whitelisted if now < whitelistAccountExpirations[msg.sender].
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:
isWhitelisted(address account) - isWhitelisted returns a boolean value of whether an account is whitelisted. This logic is isolated into its own function for readability.
_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.
_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.
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.
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.
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
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