Really bad form to group process votes on the SF structure with a USDC fee rise

We should agree as a community that this is completely bogus to lump in a SF fee rise on USDC - which has not been supported by many in the community - with a popular change in the SF fee structure in the latest executive vote. Fee rises should be their own vote. Process changes should be their own vote. This just feels like dirty pork barrel politics.


Really dislike the entire thing where multiple policies are all voted on at once in general. I don’t think any changes should be grouped together. My understanding is this grouping is done to make voting overhead lower? Because we cannot vote on multiple policies at once with the same mkr? I would love to see a solution to this in the near future though, bc there’s way too much power/influence in the hands of the person who submits the vote.

1 Like

I do not agree that this is “completely bogus”. The decision to group monetary policy and governence decision making together was passed through MakerDAO governence and was the winning vote. There are pros and cons to it, but it’s the system that was voted in.

If you think it should change, the process is to put forward a signalling vote in these forums. If you make a good argument and people agree with you, it can be added to on chain voting and can be updated.

All of us are part of this DAO. Any one of us can make a change if we are passionate enough about it. I don’t believe it’s a good attitude to complain about something and not offer a solution.


The MIPs framework exists to solve these kind of issues that occur in the weekly cycle. The weekly cycle is a process that grew completely organically, and thus has a lot of problematic edge cases, in addition to being way too fast and loose for making big long term changes - and ultimately containing a lot of risk that could potentially blow up and cause issues later due to malicious or bad proposals that could get pushed through too fast with not enough oversight.

In the Foundation MIPs working group we are preparing to create one or more MIPs that will formalize the weekly cycle into a more streamlined process that primarily exists to deal with a few specific things where a weekly cycle is appropriate, namely SF/DSR adjustments, debt ceiling adjustments, and time sensitive proposals - and put some constraints and checks in place to de-risk its use outside of those categories in order to instead direct general proposals to the full MIPs process of the monthly cycle.

In order to support the near consensus that has already been reached regarding the new SF structure, we will also include the new base rate structure directly in the first draft of the proposal, even if this executive vote doesn’t pass, so it will be formalizing the weekly cycle as it would look assuming this proposal passed.

And of course keep in mind that it’s just going to be another proposal that will go into RFC, and then put to a vote in the monthly cycle, so the community will be able to offer input and create competing MIPs, just like with the MIPs that have already been ratified.


I did offer a solution: don’t group stability fee votes together with votes on other types of governance issues. This is susceptible to abuse by a small group of people who want to pursue their own fee agenda by tying the vote to a governance change that may otherwise be very popular.

1 Like

The addition of the Base Rate change in the Exec was a mistake on my part.

The community signalled for a process change which was ratified in the poll so it will be implemented on Monday.


Thanks for your reply. I’m sure you didn’t have any bad intentions, I just wanted to flag that as a general practice, I think grouping votes together like this is vulnerable to abuse,

I’ve commented on this multiple times, and I 100% agree with you. Bundling is rubbish, and we should try to get rid of it as soon as is feasible.

Unlike Rune, I don’t believe that the MIPs process solves the problem satisfactorily (though it may prove to alleviate the severity of the issue.) It’s really important imo not to conflate the following two issues:

  • There should be a strict schedule for votes, such that everyone knows when they need to pay attention, and when they don’t.
  • Votes should be atomic in that each issues is voted on separately (though potentially in one transaction after going through a pick-and-choose UI)

These issues can be solved with a process where a large set of atomic votes occur at a fixed time every month.

If a group wants to come together and start an anti-bundling campaign movement of some sort I’d love to be involved. I have a couple of ideas for implementation, but the change isn’t costless, so it will require a coordinated movement to make change happen in this area.


Count me in too- but why is it so complicated? I guess anyone can submit a bundled executive vote? I’m not clear how is controlled


So, yeah there are complexities to this that aren’t super obvious. A couple of points:


This is controlled by the governance facilitators if you are feeling charitable, and the Foundation if you aren't. Anyone can submit on-chain executives or polls, however they will not appear on the frontend unless they come from a set of whitelisted addresses.

On System Defence

The obvious first order solution to bundling is to simply put up multiple executive votes on-chain at once, each containing a single change. However, this causes a serious issue with regards to defending the system from governance attack. The threshold to reach for each executive to pass is to 'beat' the current highest executive, because of this, splitting MKR across many executives is bad, and makes it easier for an actor to attack the governance system with a smaller amount of MKR.

On Slates and Multiple Voting

A little known fact is that the smart contracts allow voting on multiple executives at once, however this is not supported by the front end for reasons of complexity.

However, even if the front-end did support multiple-proposal-voting there remains the issue that each executive still needs to have the most MKR before it can be executed. Say you vote for three executives under this system, you would expect the most popular to pass first. But then, everyone that voted for it needs to change their vote to exclude that executive in order to ‘clear the way’ for the other executives to pass.

On Complexity

In terms of complexity, the change itself is not that complex (at least so far as I understand.) The minimal change to allow atomic voting is to change the 'pass/fail system' from:

A proposal must exceed the highest proposal to get the hat


A proposal must exceed a percentage of MKR locked in voting contract DSChief (50% by default) to get a hat

This allows multiple proposals to have access to the protocol at once, and allows us to pass things atomically.

On Migration

Edit: Rune added some additional clarity below, which may simplify any migration.

So far, so good. However here is where we meet the sticking point. The current implementation of DSChief does not support a frictionless migration. Migration is possible, but it’s quite dangerous and requires a lot of coordination between MKR Holders to do safely.

MKR has to move from the old contract to the new contract, and also maintain the ‘hat’ in both versions during the migration period in order to ensure that the system is secure from governance attack throughout the process.

Subsequently, after the migration takes place, all the MKR that is in the old contract needs to move to the new one to secure the system (see system defence above.)

1 Like

Wow- that is complicated. Thanks for the explanation. It seems like the best strategy for now is just to convince the people that control to stop bundling like this.

An easier approach to upgrading the voting logic would be to install a “long term hat”, basically an active proposal that is meant to remain the active proposal for a long period of time, and then itself contains the more advanced voting logic, which people then vote in using IOU tokens, that is then passed through the hat to the GSM.

Ds-chief was designed to support this, and an important security feature is that if the more complicated voting solutions starts failing for some reason, it is quite easy to turn it off and revert back to the base layer governance system by voting in another spell.


Ooooohhh, I never even considered that! That makes the migration hardly an issue at all, and as you say, lets us upgrade and/or revert to default if things break. That’s actually huge, and makes the whole ‘lets-not-bundle’ thing way more feasible.

Really appreciate the input, Rune, thanks.

I would love to be a part of the anti-bundling campaign