Summary: This post is a request for comment on a proposed redesign of the chief contract. Instead of using the existing hat mechanism to cast a spell, this redesign introduces a threshold and minimum quorum that must be exceeded for a spell to be cast and successfully make protocol changes. This will support voting on concurrent proposals as well as protection against flashloans.
The purpose of this forum post is to introduce a redesign of the governance chief contract to gather feedback and design ideas. Together with the feedback from the community and the prior research done at the Maker Foundation, the smart contracts domain team will create a formal Maker Improvement Proposal (MIP) for a rebuild of a new Chief contract. The redesign will be called: DssChief.
Please note that this initial description and the request for comments period does not have any formally defined timelines or estimations of the work required. The idea is first to identify the ‘what’ in terms of needed/requested features as well as the capabilities of a new governance system, and use that information to inform the technical ‘how’ of what is possible. Once this is known, a comprehensive roadmap can be mapped out, including a formal delivery plan of the agreed-upon feature functionality.
This post will start by identifying some of the opportunities for improvement in the current system as well as some of the problem spaces that participants of the governance process are familiar with. We will then describe a number of features that outline a concept for a new design. These are described as individual categories however they are designed to complement each other. We welcome all comments and feedback as we build this into a comprehensive solution.
The Existing Governance System
In the current governance system, the process of voting for proposals is done through a token-weighted continuous approval voting system, where users vote by putting their MKR in support of a proposal. When any particular proposal exceeds the amount of MKR in the hat, it can become the new governing proposal. This system works well for continuous approval voting but can be particularly problematic if there is a proposal with much more MKR in support which has not yet been lifted.
For example; Let’s say the actual hat has 25,000 MKR, meanwhile a new proposal secures 75,000 MKR, however it hasn’t been lifted yet as this is a separate action. During this period before the hat moves to the new 75,000 MKR proposal, the system is exposed to any malicious proposals attempting to secure the hat with 25,000 + 1 wei MKR. With this amount it could then be chosen and implement system changes as the new hat.
The Existing Governance System - Consideration for Frontend Update?
It has been suggested that we make enhancements to the frontend UI to use slates. Slates are an existing backend feature that allow users to vote on a bundle of spells. Ideally the user’s slate includes the chief as well as any new proposal they wish to pass. Currently the use of slates is not supported in the vote.makerdao.com interface and could be made more user friendly than what is possible on the chief.makerdao.com site.
The problem with this mechanism is that even if we improved the front end UI to support voting on a bundle of spells, users at some point still have to move the hat out of their slate to allow the new proposal to gain a greater majority than the existing hat. In doing so, this exposes the same window of vulnerability whereby the chief may have substantially less MKR in support. These and other failure modes are documented in further detail here
Challenges & Opportunities
In addition to the above security concern example, there are also usability challenges that can be improved as shown below. These challenges give us a starting point from which to build and improve a new version of the chief contract.
|Protect during vote transition||Slates are not widely used to prevent an unexpected spell from becoming the hat||Either improve the UI or introduce the concept of a threshold (vs a hat)|
|Delay MKR lock/free actions||Currently, a user is able to deposit, vote and withdraw their MKR without any sort of time delay or deposit-time restriction (flash loan risk)||Introduce a delay between user actions|
|Introduce MKR expiry||MKR holders often leave their MKR on old spells leading to a broad distribution and making hat security a challenge||Introduce vote-decay, or a mechanism to return MKR to a user’s wallet, and/or use a threshold to pass proposals|
|Support multiple proposals||Currently we only support a single executive which is unmanageable and doesn’t scale||Support multiple concurrent proposals which would require a rewrite of chief|
|Gas costs when voting||Users have mentioned that gas costs factor into their decision to vote or not when there is network congestion||Explore ways to reduce tx cost or support alternative gas payment mechanisms|
|Support formal verification||Chief is not currently formally verified||Minimise the use of loops to simplify FV and reduce gas usage|
Taking the above items as inspiration, we can see that much of the complexity stems from the existing hat/chief paradigm. Rethinking this design gives us an opportunity to explore more secure and usable methods of governance.
Introducing a New Chief Contract: DssChief
The newly proposed DssChief uses a threshold that must be exceeded in order for a spell to be cast and make protocol changes. This threshold is accompanied by a minimum quorum that protects the protocol from low-bid proposals. Similarly, because users are not shifting MKR weights as they did in a hat/chief paradigm, this redesign allows for multiple concurrent proposals once voters have locked their MKR in DssChief. This new contract works alongside a proxy contract called ‘DssChiefWrapper’ which allows locking, freeing and delegating user MKR.
These concepts and more are detailed below with accompanying examples where necessary.
Using a Threshold as a Benchmark for Passing Spells
The critical difference with the new DssChief is that it has no concept of a hat. Instead, it has a threshold that must be passed in order to introduce protocol changes. It will be the responsibility of governance to define the threshold as a percentage of the amount of MKR locked in Chief. Furthermore, to prevent Governance setting the threshold at a dangerous level - i.e too high or too low, there should be a preset hard boundary allowing the threshold to be active only within a range of for example 40-60% of the total amount of MKR locked in chief.
For example; let’s say the threshold is determined by governance to be set at 50%. This would mean that a proposal would require 50% of the amount locked in Chief (currently 290k MKR) for it to pass, meaning that a threshold of 145k would be in effect.
This value can of course be changed by governance through an executive vote. Please note that it is advised that the threshold should not be an absolute number otherwise the system may not function if that number is unable to be reached.
A further important distinction is that as long as the MKR weight locked in Chief remains the same, the threshold required to pass proposals will also remain the same - the threshold does not change if users move their votes from one proposal to another.
System Security With a Minimum Quorum
In addition to the threshold there is an equally important minimum quorum that must be exceeded regardless of the threshold in order to successfully pass a proposal.
For example; let’s say that the amount of MKR locked in Chief drops to 80k, meaning that a threshold at 50% would allow a spell to pass with only 40k MKR. However, with a quorum set at 50k MKR (or another absolute or percentage based value, tbd), it would be possible to defensively prevent spells from passing with any amount less than that.
As with the threshold value, the quorum poses a risk if it is specified too high and may render the whole system unusable. To prevent this risk we will also introduce a hard boundary that cannot be exceeded by governance. This will prevent an unreachable level from being introduced.
There may be instances where an extremely high quorum is necessary, for example when migrating from the old chief to the new DssChief. In this instance a one-off minimum quorum could be set for a single vote and then removed once the spell has passed and the system is secure. This mechanism also needs to be able to support future upgradability.
Multiple Concurrent Proposals
The threshold and quorum design enables a voter to participate in multiple concurrent proposals. Again, because there is no notion of a hat, there is no action needed to shift MKR weights from one proposal to another, the user is instead voting on as many proposals as they wish to support.
The ability to have multiple concurrent proposals means there is no need to bundle individual parameter changes as they can be created and elected independently. As one may expect, this requires a robust locking and freeing capability, which we will discuss next.
DssChiefWrapper to lock and free MKR
To facilitate user locking and freeing actions across multiple proposals, we are introducing a DssChiefWrapper to simplify the interaction which will be necessary when a user is in support of more than one proposal.
For example; if a user is voting on multiple proposals and wishes to free their MKR from the governance system it will first be necessary to remove their support from all proposals that they are in support of before being able to free their MKR.
This necessitates the use of a Chief wrapper as a proxy contract to manage the removal of support from multiple proposals in a single action. This action would also be necessary when users want to lock additional MKR in the system to put towards new proposals.
DssChiefWrapper to Support Vote Delegation
DssChiefWrapper will also enable users to delegate their vote to other addresses. The documentation of this function is currently being discussed and will be shared once completed.
The user’s MKR can be used to support proposals in full only - there is no planned capability to use a partial amount of MKR.
MKR in Chief Expiry
To ensure the threshold does not go stale by becoming unattainable through ‘old’ MKR, it will be necessary to have a timeout on the MKR locked in Chief if it has not participated in voting beyond a defined period of time. For example this could be defined as a year, or another value that governance deems appropriate. We are also exploring the potential of a decay-time for the MKR that is locked in Chief. This is an ongoing conversation and we welcome your input.
As the ecosystem grows and the creation of proposals becomes decentralized, there is appetite to enforce a minimum specified amount of MKR to be held by the address that submits an executive. This would act as a bond to prevent the spamming of spells and ensure that only legitimate spells find their way onto our and other 3rd party front ends.
DssChief to Interact Directly With the Pause
A pause mechanism enforces a delay between the time that a proposal is voted-in and the time when said proposal actually changes system protocol values. It is envisioned that the system will be able to support multiple protocol pauses, the technical mechanism and whether DssChief will have authority over the pause/s through ‘SpellActions’ allowing us to plot, cast and drop spells is currently being explored.
To protect the system from old spells, the system will support spell expiry in order to prevent spells from being executed multiple times.
It is understood that the ability to lock and free MKR across multiple spells may be a gas intensive exercise that will require additional testing and optimisation of the ChiefWrapper.
Process & Next Steps
Gather feedback and thoughts on the above points to help inform further research and development. This will ensure that we have a rigorously tested implementation that is optimised and efficient, enabling us to document a formal MIP to be submitted for a governance vote, followed by development, testing and formal verification.
I intend to actively maintain this forum post with the latest information, and to complement ongoing discussion, I have created a Community RocketChat Channel at #chief-redesign-ext for more free-flowing dialogue. If you wish to join, please join or DM me.