For certain situations, such as the recent COMP distribution bug, we may need faster acting Governance actions, especially around a standard set of actions that would reduce various operational or financial risks of the protocol (think of it like a fast acting emergency brake for the system). One example would be suspending the COMP distribution, or perhaps reducing the borrowing cap as I suggested last year. I feel this could be done two ways: one being a special type of fast governance vote, the other through community multi-sig. The first step would be the same, a standard governance vote where we agree which sort of actions would fit this classification. I’d be happy with either style implementation with a preference towards fast governance. If of community interest, it would be great to use this thread or another to brainstorm what sort of actions, in addition to the two suggested above, would be useful to have in this framework.
Agreed, that would be a good additional security layer for the protocol. I would also favour a fast governance approach which is a stronger mechanism than a multi-sig in my view. What do you have in mind for the fast process?
I am thinking something like: Voting lasts for [24] hours (vs. 3 days for regular process); if a majority, and at least [300,000] votes (vs. 400,000) are cast for the proposal, it is queued in the Timelock, and can be implemented [8 hours] later (vs. 2 days). And the voting period could also stop earlier as soon as [400,000] votes or more are cast.
I’ve been working on a new system over the past month - “governance boards.”
Rather than one governor and one timelock, we’ll have many, all with their own purpose. Each different governance board will have different configurations and permissions.
We could then have an emergency governance board that is quicker to action but requiring a 2/3 majority and a higher quorum to keep things secure (just an example of what’s possible).
The end goal for governance boards is to effectively decentralize all kinds of roles and responsibilities. Governance boards would effectively replace executives, directors, managers, supervisors, etc.
Governance boards is a cool framework for generalizing this concept. I definitely think that should be explored more carefully, and perhaps it should be the framework for implementing this particular case. To help simplify the discussion for this thread I think we should focus on this particular use case, since the parameter space of governance boards seems vast and might bog us down. To be more precise, I see the “emergency brake” decision space basically being a subset of what a risk committee might do.
One concern about 2/3 majority is the possibility of something like a treasury exploit that needs to be fixed- not sure how much COMP is in treasury vs out, so need to think about that right % to handle this- you could argue a smaller percentage might be appropriate for a very fast, risk reducing emergency vote (or just quantify as a number of votes based on voter turnover from recent X proposals). Another point to consider is there’s a big potential difference in how many people actually vote vs have the right to vote, so we sort of need to normalize for that reality in the percentages required to pass an emergency governance vote, hence my interest in using a number rooted in number of votes on recent proposals.
I like these general time frames; perhaps we can start with values in that area, but make those variables upgrade-able too (through a standard governance vote), in case some attribute of the protocol requires a faster or slower risk process down the line.
In general I love the idea of lowering the barrier to enacting an action, especially security critical ones.
I would advocate strongly for a pause guardian which can be revoked by the DAO. This way the worst case of a malicious guardian is a few days of paused functionality, but the best case is preventing a serious vulnerability from being exploited.
I like this idea. We could probably have the two approaches in parallel, (i) governance boards with the capability to change certain parameters in an accelerated fashion, and (ii) a pause guardian in case of emergency (maybe in the form of a [3/7] multi-sig) that could pause deposit/withdrawals, COMPS distribution and maybe outflow from the Treasury.
In term of scope for the emergency governance board, here is what come to my mind:
- Push security patches that don’t break integration with other protocols
- Change COMP distribution speed
- Reserve factors?
- Borrowing caps?
I would not include the collateral factors in the “emergency” category because of the risk of triggering liquidations without letting borrowers enough time to hear the news and adjust their positions. Am I missing something?
There’s already a Pause Guardian that controls Mint, Borrow, Transfer, and Liquidate. Assuming it still works as expected, adding distributeSupplierComp , distributeBorrowerComp , and claimComp under its control should be trivial. I agree we should create a fast-acting govenance process, which I also discussed here. However, for the immediate-term, I believe updating the Pause Guardian is the simplest and lowest risk change we can make right now to protect ourselves from future bugs related to COMP distributions. If others agree, I can put a PR together.