Transitioning governance of the Compound protocol to the community is the most exciting, and powerful experiment we’ve ever conducted.
It’s up to all of us, working together, to create the governance standards and processe that will carry Compound forward for years/decades to come—standards that ensure that the protocol is resilient infrastructure for developers, and a series of predictable financial markets for end-users.
Previously, I’ve laid out some principles for how I vote as an individual COMP token-holder; now, I’d like to share some thoughts on what I believe good governance looks like. The community can adopt, extend, modify, or reject any/all of this as you see fit - these are notes, to start—and I’ll try to keep this updated by incorporating your suggestions. Please weigh in .
Discussion
Governance Proposals should all start with community discussion, questions, and analysis; a single forum post in the Ideas is a great way to organize conversation on a topic.
The goal, at this stage, should be to add as much knowledge & information as possible about the effect of a potential proposal. Either by adding data/analysis, or by asking questions that can lead to more insight. Saying you like or dislike an idea is fine, explaining why is better, backing it up with information why is best. Suggest alternatives; and keep an open mind.
Give the community time to process your ideas, and add their own.
Know the Tools
All changes to the protocol modify data stored on-chain; changing a parameter from A to B, or changing a contract address (e.g. which contract to use) from X to Y. It’s important to understand how the protocol works, and the difference between parameters, and contracts. If you’re not sure whether a proposal would modify a parameter or contract, what something means, or how it works, just ask!
Changing a parameter is simple; it introduces no new code, and very likely no technical risks.
Risk Parameters:
COMP Distribution Parameters:
- COMP Distribution Speed
- Add Market as Eligible for COMP
- Remove Market as Eligible for COMP
Changing a contract is complex; any change will introduce new code, and potential technical risks. The primary modular contracts are:
- cToken Contracts
- Interest Rate Models
- Comptroller (Risk Model & COMP Distribution logic)
- Price Feed
Lastly, there are administrative functions, and traditional on-chain functions that can be called by Governance proposals; these likely introduce no new technical risks, but should be carefully considered:
- Reduce Reserves
- ERC-20 Transfer
- External function calls
Introducing New Contracts
Any proposal that introduces new code should be thoroughly audited by the community, with technically capable members of the community weighing in.
Development should be conducted in the open; pull requests, code diffs, test cases, and sample deployments of new code should all be completed for the community to inspect. Expect this process to take time.
Significant changes should undergo a professional third-party audit; this can be paid for by the Compound Governance system by removing reserves. Together, we’ll develop standards for introducing complex changes—but until you’re completely satisfied that a proposal introduces little technical risk, fight against it.
Creating a Proposal
In order for the community to weigh a your proposal, they need to know which parameters or contracts would be changed (and to what). Create a discussion in the Proposals category, focused on a narrow set of changes, and not try to suggest multiple scenarios or changes simultaneously.
Use this as an opportunity to solicit support, answer questions, and build public support. When you feel that the proposal has a high likelihood of success, create it. Let the community know, and be ready to engage in active dialogue about your proposal. COMP will speak for itself, and the economic incentive to protect & grow the protocol should carry the best idea through.