Signal Request: How do we handle executive bundling in relation to technical changes?


Recently we’ve had a couple of potential issues come up around executive bundling with regards to technical changes. Initially, we had the proposed flopper change detailed here. Then, more recently we had the activation of the Governance Security Module, detailed here.

These technical changes have brought to light a question as to how we handle the bundling of executive votes with monetary policy changes. Thus far we have largely managed to avoid controversy around the issue, however it makes more sense if we can agree on a policy and vote on-chain before we run into another issue of this nature.

Previous discussion has happened in the threads linked below. My hope is that we can use this thread as a single point of discussion and agreement going forward. To this purpose, I will be locking the previous threads, and leaving a link to this signal request.

Non-Emergency Technical Changes

Emergency Technical Changes

The Negatives to Bundling

The issue with bundling monetary policy with technical changes (both emergency or non-emergency) is that it has the potential to either:

  • Force voters to vote for something they do not want. (In the case of them liking one change, and disliking the other.)
  • Force voters to vote against something that they do want. (in the case of them disliking one change so much that they cannot countenance the other.)

In the extremes, this sort of bundling can:

  • Lead to us adopting bad monetary policy (because we needed an emergency technical fix.)
  • Lead to abuse of the system and the aggregation of highly charged political changes.
  • Lead to governance paralysis at a time when we need to be as nimble as possible (for example an unacceptable monetary policy change gets bundled with an emergency technical fix.)
  • <Further negatives here! If you have more disadvantages, please bring them up below, and I will append them to this list.>

The Positives to Bundling

On the other hand, proponents of this system name the following advantages:

  • So long as changes are not controversial, it allows us to make more changes more quickly. This can be particularly beneficial in terms of technical changes.
  • Having less votes reduces voter exhaustion, potentially increasing or helping to maintain long-term engagement.
  • <Further positives here! If you have more advantages, please bring them up below, and I will append them to this list.>

Moving forward to resolution with this issue, I propose we take the following approach (and will continue assuming consent to this approach unless people express their discontent).

  • Given that we have already had two signalling threads with positive consensus for desired change, I do not believe it is necessary to put forward a ‘general opinion’ poll as detailed in Stage 1 of the Current Signalling Process.
  • Stage 1 would normally contain a gathering of potential solutions to this problem. Given the discussion of the issue so far, and the relative simplicity of the subject, I am also not convinced that this is necessary.
  • Given the above, I will begin this thread at stage 2: A multiple choice vote on the specific options of how to handle executive bundling with technical changes in the future.
  • Given the holiday, in three weeks we will review the outcome of these signal polls, and (given consensus) move on-chain. If we cannot find consensus, we will attempt to generate alternative options and then vote on those.

In voting in these polls, vote for all options that you agree with. Due to the nature of these polls, any non-conflicting consensus options will be put to an on-chain poll.

A word on terminology:

Supersede: Replace the contents of the executive vote. Anything replaced is not voted on in an executive vote, and is essentially ‘skipped’ for that week.
Separate: Create multiple consecutive executive votes in the same week to push through the different changes.
Bundle: Include multiple sets of changes in the same poll.

  • Non-emergency technical changes should supersede non-emergency monetary policy changes.
  • Non-emergency technical changes should be separated from non-emergency monetary policy changes.
  • Non-emergency technical changes should be bundled with non-emergency monetary policy changes.
  • Emergency technical changes should supersede non-emergency monetary policy changes.
  • Emergency technical changes should be separated from non-emergency monetary policy changes.
  • Emergency technical changes should be bundled with non-emergency monetary policy changes.
  • Abstain (I just want to see results)
  • Abstain (I have no opinion)
  • Abstain (I don’t feel I am knowledgeable on the subject)
  • Abstain (I disagree with the poll options)
  • Abstain (I have a different objection)

0 voters

Poll is now closed. Summary can be viewed in my reply below.


I have just closed the previous two threads. Further discussion should take place here.

1 Like

Even if I have to vote for a (not especially controversial) monetary policy change I don’t like, its worth it to quickly pass the pressing technical change. Reduces voter exhaustion as well. So far the market dosen’t seem particular sensitive to most monetary policy changes, so reducing time to pass emergency technical fixes seems more important to optimize.

Could situations come up in which a technical issue merits a specific monetary policy change due tot he nature of the risk posed by the bug? Maybe something to consider, if not sure how likely it is

Non emergency technical change should convince voters alone on its merit. Non emergency technical changes are non essential and poses a new risk right?

1 Like

I agree. In that situation, everything is fine. The problem is that you can’t guarantee that the monetary policy change isn’t controversial.

Likewise, this is true at the moment (that the market is somewhat insensitive to monetary policy changes) but it isn’t guaranteed. If the bundling policy is only okay because monetary policy changes are currently ineffective/non-controversial, then I don’t think that is a good justification for bundling them. We have to think in worst-case scenarios.

Yes, probably. I did consider adding in a bunch of options around emergency monetary policy changes, but I felt that the poll was already way too complicated. We’ll have to deal with it as and when it comes up, and potentially amend the policy then.

Pretty much in agreement with this.

I mean it can still be controversial, just not so controversial that someone would delay/not vote for an emergency technical fix because of it.

If we choose for the worse case scenarios in every decision we can hurt ourselves by being paranoid. So far the experimental evidence is that in the vast majority of circumstances monetary policy changes dosen’t immediately influence the market, I dont see why we should be super suspicious of that trend in this point in time. Definitely should revise that observation if market behavior changes

Its also not okay only because the monetary policy is insensitive/non controversial. The time it takes for an emergency technical fix to pass might be super important. IMO more important than an inaccurate monetary policy change.

You are right, there are trade-offs in terms of efficiency but in the case of potential security issues, I think we should give worst-case scenarios a higher priority.

So here’s a summary of my views on this:

  • The time it takes for an emergency technical fix to pass might be super important. (as you said)
  • Adding a monetary policy component to an emergency-fix executive can only slow down the passing of that executive.
  • Either the monetary policy change is non-controversial, and it’s just as fast, or it is potentially negative and it causes any number of voters to hesitate for any amount of time.
  • Therefore there is no benefit to bundling the changes, and a cost that could vary wildly depending on the contents of the bundle.

I agree that the argument is more nuanced for non-emergency technical changes though, hence why I split the two cases in the poll above.

1 Like

@Mitote @LongForWisdom

I Think the main concern around this , maybe it is not related to it but in parallel with the fact that multi-transaction speed is low right now and to me, not fast enough .

What i mean is everything is slow. To make things looks good and doing good, there should be a way to make the hole process faster , but way faster.

Either the Emergency Shut-off or just the fact that you make a daily transaction with your online wallet, is too slow. Solving this issue, would be like, something crazy good for MakerDAO and in general. Then we would not need to consider all of the good ideas that we talk about, they would become a Low-Priority changes or work-order , situations.

For me the monetary policy changes then we would not need to talk about it anymore because it would not be a issue anymore, the same for the vote, we should not need to rush even if right now is almost like a Gold-Rush period where a lot of things evolute super fast.

Not sure if you will like they way i think about it, but speeding this up, would fix many things and the Gouvernance-at-a-Glance would go nice and easy.

What do you think ?

Apologies, but I’m quite sure what we’re being asked. I think we always going to have to talk about monetary policy changes, I dont really see how that could ever go away.

Definitely optimizing speed for certain things will be important as we emerge as an actual DAO, but I dont think we have any solution for eliminating bureaucracy and I’m not sure how the fundamental UX of voting can change dramatically. Ethereum is ethereum (personally I’m interested in looking into other options).

I think my reply is unsatisfactory, feel free to clarify what I missed about your comment

1 Like

I don’t think your comments is unsatisfactory, right now, it is what it is like you say. That’s why i am here, to bring new and fresh ideas on the table.

I study your projects every days, and i can just be more competent overtime. Finding a solution i don’t think this forum is great for this since it’s mainly for Gouvernance and his attribution or direct applications, but it does have a subsection where we could use for this, fresh idea.I think this would have direct impact but would lead to many more things. Maybe i just dream about it but that is what i can tell from personal experience since i use Cryptocurrency or tokens etc.But this is just a small idea here on the side because i was reading you and i found it interesting what you said about bureaucracy elimination. We already eliminate so many of them creating the Cryptocurrency… For the one that work in those area they will probably not be happy, but for the others like me, the idea of having much more in my pocket is pretty interesting.

MD5, SHA-1, SHA256, SHA512, MD5 produce 32 hash while SHA512 is doing 128 hash . A lot of encoding that is not relevant here but that is my point.

Feel free to give your opinion about it. But to reply for the part you were missing, i think we are giving too much power about the Emergency Shut-Down to the community. This is a decision and action that when it will happen you cannot start to make post on forum that somebody is hacking us and they took all. Just to make sure what i say is related to this post and clarify that this have direct link to monetary policy.

While I think your comments are interesting @Sirlupinwatson1 , I think they’re veering off-topic for this thread. Lets try and keep the discussion focused around the signal above. Namely: What do we do about getting technical changes through the executive system in addition to monetary policy?

1 Like

One day late on coming back to this. Apologies all.

I don’t feel that 12 voters is enough to make a decision on this topic. Given the holiday and the other more interesting signalling votes going on, I’m going to give this another week and attempt to convince more people to vote.

I shall update this topic again on the 13th of January, 2020.

Thank you everyone who participated in this signaling thread. Here is my summary of the thread, and my suggested next steps.


It’s now the 13th January, and the poll is sitting at 19 voters. Only two options presented have >50% agreement:

63% - 12 Votes - Emergency technical changes should supersede non-emergency monetary policy changes.
52% - 10 Votes - Emergency technical changes should be separated from non-emergency monetary policy changes.

Given these are mutual exclusive, it is fair to say that the consensus option in the case of emergency technical changes is that they should supercede planned non-emergency monetary policy votes.

In the case of Non-Emergency technical changes, no option has reached the threshold of 50% that is currently deemed to indicate ‘consensus’. The highest voted option is:

47% - 9 Votes - Non-emergency technical changes should be separated from non-emergency monetary policy changes.

Given the outcome of this vote, I am advocating for the Governance Facilitator @rich.brown to create an on-chain vote that concerns emergency technical changes only. I recommend that this on-chain vote should be created in the form laid out below, but I am open to adjustments from the Governance Facilitator in the case of concerns over wording.

On-chain Poll Wording

Title: In the case where emergency technical changes to the Dai Credit System are required, should those changes supersede (replace) non-emergency monetary policy changes in the next executive vote bundle?


If passed, when emergency technical changes to the Dai Credit System are required they will supersede non-emergency monetary policy changes when the next executive bundle is created.

The decision over whether or not a technical change is an Emergency is determined by the Technical / Development team employed by the Maker Foundation. In the future, this authority may be voted to an alternative entity.

The decision over whether or not a monetary policy change is an Emergency is determined by the Interim Risk Team employed by the Maker Foundation. In the future, this authority may be voted to an alternative entity.

When non-emergency monetary policy changes are superseded in an emergency:

  • They are not added to the next executive vote spell.
  • They may or may not be added to a subsequent executive vote spell at the discretion of the Governance Facilitator once the current governance period (currently one week) has passed.

Background and discussion: Signal Request: How do we handle executive bundling in relation to technical changes?

Options: Yes/No


Not sure if it is right time to put those remarks here I already introduced it In thread:

There are two tools in governance currently in place

  1. Polls
  2. Executive votes

Polls are for continously querying MKR Holders for their position on separate “atomic” properties of a system

Executive votes are making changes that reflects that position.

It is actually matter of using this tools In little different way

Lets have polls that never expires. One for each parameter:
Separate polls for SCD/MCD SF
Separate poll for MCD DSR
Separate YES/NO poll for every feature of a system which might be enabled/disabled (Governance Security Module is good example)

Every predefined period of time snapshot of results are being taken and if it is different than snapshot from previous period then Executive Vote, that reflects this changes, is being formed and waits for acceptance

If Executive Vote is not accepted, next Executive Vote will be constructed based on next snapshot of polls results.

This way any controversy with reintroducing changes like GSM will not be possible. There simply will be YES/NO poll and every executive vote will reflect current status of this poll.

Polls should have quorum requirement to have results to be included in Executive Vote. It would prevent changes to be introduced by small amount of MKR.

That creates very transparent proces of introducing changes to the system and is in line with “continous approval” concept of Maker governance.

That also enables any MKR holder to change his mind on any matter at any time.

There is very little space left for subjectivity or “bureaucratic process”.


Took me longer than it should have to get my head around this. I actually like it quite a lot, I think the key change is having polls that don’t expire and building each weekly executive based on those polls.


Great idea.

If polls don’t expire, how do you expire polls that are voting on expiration of some feature and mkr locked is above quorum? They are ‘invalid’ polls by not being possible to be executed, but technically included in the snapshot.

Hm, i guess if they are not executable, this is not a problem, since nobody is able to code such spell/contract. Still, do we need mechanism to destroy poll (remove from snapshot)?

1 Like

Not sure If I understand a question but in case of a polls you do not lock any mkr tokens You can participate in many polls in paralel

You should have simply one poll for each topic.

And Yes I believe that it should be not only possible to turn On some feature but also to turn it off if poll results backs off from initial support for a feature

Yes, I should not use the word ‘locked’.

What am i asking is if anyone can create a poll (if we disregard the user interface)?

Not sure why I got confused and forgot that “Rich and Company” controls webpage for voting.
They have ability to add/remove poll visibility, right? So, if poll becomes obsolete, they just filter it out.

I like this solution a lot. One question I have is how we would decide to add a new kind of poll and how many kinds of polls could be running at the same time?

Yes @jernejml ,

Anyone with the accorded privileges can create a pool.

Either a Administrator or a moderator can delete the pool but not everyone.

Creating a pool leave trace so it’s not obsolete.

I think that there is no limit on number of polls -as many as there is needed,

one for every parameter of a system that can be customized, maybe at some point in time they will need to be categorized but that is surely down the road.

Currently I believe adding a poll is in hands of MKR Foundation maybe at some point it can be decentralized as well, but I guess it is not urgent.

One of ways of decentralizing it is to allow anyone to register a poll it he puts a deposit of let say 1000 DAI if poll will reach Quorum (or some other participation level) then deposit is being returned If not poll is considered a spam and DAI are being sold for MKR and burned :wink: