Governance Chief Contract Redesign: A Pre-MIP Discussion

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 interface and could be made more user friendly than what is possible on the 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.

Challenges Description Opportunity
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.

Voter Weight
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.

Spell Creation
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.

Spell Expiry
To protect the system from old spells, the system will support spell expiry in order to prevent spells from being executed multiple times.

Gas Costs
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.


Could we please either name it:

  • DSBoss (or something more distinct from DSChief)
  • DSChiefV2 (or something that is obviously the second iteration of DSChief)

DSChief vs DssChief is just too confusingly similar, imo.

There could also be a delay to the threshold change that mitigates this. For example the target threshold is x% of the total MKR locked, and the actual threshold moves towards the target threshold over a period of time.

This hard boundary should possibly be based on the total amount of MKR in existence.

A thousand times yes.

We should allow this for delegation though, if possible.

Not sure I understand this, could you elaborate?

Good idea. This should be a settable lever by governance. In addition there should be a lever that allows DssChief to burn some percentage of the MKR bond in the event the executive does not pass before it expires.

I would also add to this that we should try to replace MIP3 (the governance cycle) in parallel or shortly after DssChief goes live. Many of the design constraints that led to its current form would no longer be constraints under DssChief.


When exactly does any of the fixed minimums (as % of total in the Chief) get locked and how will this interact with respect to the delay mechanics. My concern here is that using %'s might trap us somehow if governance needs to act but some whale removed their MKR from the chief. I also have a concern that the dynamics of MKR moving into and out of chief or voting/not voting might cause issues with governance not being able to act when they need to.

Since 50K is sufficient to ES the protocol should there be some minimum amount of Maker that can cause a reset of the Chief parameters to override delays and levels that can get slashed if governance feels it was in error or a governance attack of some kind.

I like a lot of what I see in this re-design and please do rename this so that it is distinctively different DSChief_v2 would be nice.

I really would like to see a deposit delay in DSChief_v2 btw so we can’t have flash MKR loans screwing with governance as I have suggested before.

I have to look a bit more at the details here but glad to finally see delegation come up and grouping executive votes, decaying others etc. I still have to digest the hat security mechanics but this looks interesting.

One thing that is concerning me here is the compensation group has been trying to get some traction on Compensation plan yet we are being told that governance bandwidth is being eaten by other things (COMP/compound, DAI PEG) but we are being saddled with new (and def good) changes that is putting the whole compensation issue in a backseat mode.

I understand the need for the foundation to drive forward on important matters but the lack of any bandwidth regarding compensation with respect to governance is giving vault owners waiting on this a feeling that their issue is not as important as the rest of these bigger issues popping up and demanding governance bandwidth.


Great input, thanks guys!

@LongForWisdom , regarding your points:

  1. Renaming the Chief to something more distinct. Great, I see that ComDev are already debating naming so as long as we stick to “Dss…” to fit the DappHub naming convention, I can’t wait to see what you, @twblack88 and team come up with :slight_smile: Pretty cool opportunity to name a critical contract in the Maker protocol!

  2. Re: The threshold hard boundary with respect to the amount of MKR in existence (not necessarily the amount locked in Chief), is certainly possible, but the problem is that the amount of MKR in the chief may vary quite significantly from the minted amount of MKR - we wouldn’t necessarily want an MKR mint event to extend the threshold beyond boundaries that make sense for what is in Chief. Interesting alternative though, I’ll contemplate this scenario some more.

  3. Re: Delegation, yes good point, I know there is appetite for one address to delegate to multiple delegates. We’ll have to assess what capabilities are needed for the ChiefWrapper to support this. Something to consider here and dive into in a separate Delegation Proposal Idea.

  4. Re: decay-time for MKR locked in the Chief. Sorry, I think I just reiterated myself there - same concept, whereby if MKR is locked in the Chief for e.g. 6 months (or whatever the Governance community decides), it decays to a ‘holding address’ for retrieval only by the owner. This would prevent the Chief from having a stale balance that could potentially enforce an unreachable threshold. Note, we still run the risk that if a large amount of MKR gets locked in the Chief and does not participate in voting, we must wait until it can ‘decay-out’ (if that’s the right term). Similarly, we need to consider the mechanism to remove decayed MKR from the Chief - is it automatic, is it an incentivised activity etc.

  5. Re: Defining a minimum MKR balance in order to create and submit an executive. Yes, the intention is for this to be set by Governance. I do not think it needs to be very high at all - just something to illustrate ‘skin-in-the-game’. I had not considered a slashing of the ‘bond’ in the event that a spell does not pass. If that were the case it would only be fair to offer an incentive in the event a spell passes. Food for thought.

  6. Revisiting MIP3 - yes, agree we will need to revamp the governance cycle. Charles is close to this so I’ll work with as we get closer to definition and development.


Perhaps a suitable social mechanism is that a proposal that doesn’t pass can be optionally marked as spam by another proposal with a larger bond than the initial proposal. Only if the spam proposal passes is the bond slashed. This mechanism could be used recursively to challenge a spam classification as spam.

On the other hand, I’m not sure if we’re going to see enough spam to justify such a complicated mechanism to combat it.


@MakerMan , regarding your points:

  1. Re: When exactly do we define Threshold and Quorum levels - These levels will be defined when the proposal is created and available for voting. I will add proposal states (created, plotted, executed as detail definitions - thank you for the prompt!).

  2. Using percentages for the threshold is much safer than absolute numbers, because it is relative to the current MKR amount in Chief. Absolute numbers would potentially trap us more if the weight in Chief were to shift. (You make a good point about MKR movements in & out of Chief - I’ll look to analyse this).

  3. Re: Your mention of ES - I suggest as part of this initiative we also revisit the ES parameters and expand the Threshold/Quorum model for use in that scenario too. This is something that you have brought up some months ago and I think fits nicely with/alongside this proposal.

  4. Re: Introducing a reset of Governance parameters if Governance is deemed to have acted incorrectly/maliciously. Yes, Governance can always vote through an executive to change multiple protocol parameters - which could be considered a reset - we could always have a ‘Defcon’ spell created as a just-in-case reset.

  5. Re: Flashloan consideration - I had not considered a delay after the specific deposit/lock action, instead we were looking to prevent any actions (deposit, vote, withdraw) from happening within a single transaction. If there was a reason, we could extend this ‘within a single block constraint’ to e.g. 10, 100 etc blocks.

  6. Re: Delegation - this is dependent on the wrapper solution implemented for Chief. As per my above comment, yes we need to do more design work in this space.

  7. Re: Competition for resources - yes, it’s a continuous challenge, the COMP discussion, peg deviation, and liquidation system designs are all priorities. My aim of getting this socialised is to build the runway so that once resources become available, we will be in a solid place to implement designs.


Hi all, it’s been a while since I updated this thread so I wanted to let you know that we have been working on various improvements to the original design and that what I have shared above is going to evolve due to community discussions, forum and R/C feedback.

At a high level we expect to include snapshotting to support multiple concurrent proposals while reducing the gas cost (an improvement over the Chief wrapper lock/free action initially envisioned). We have been talking to and expect to support Layer 2 solutions to be able to integrate with the Chief for off-chain voting, and we intend to support delegation from the Chief contract itself. I’m hoping to share these designs and an updated timeline with you within 2 weeks.