Should we bundle monetary policy changes with technical changes in executive votes?

Pros

  • Lets us get more done faster, and react more quickly to technical issues. (Based on @Mariano_Conti 's input)

Cons

Technical changes have a higher degree of importance, than monetary policy changes. They either:

  • Fix exploits or technical weaknesses. This class of changes is vital to pass as quickly as possible.
  • Change the functioning of the system. This class of changes is extremely important, and requires a high degree of consideration before passing.

Neither of these changes should be wrapped up with monetary policy changes. When this happens, you either:

  • Risk delaying essential technical fixes due to bundling with undesirable monetary policy changes.
  • Risk passing functional changes to the system without due consideration due to desirable monetary policy changes.
  • Or vice versa, with positive monetary policy changes being blocked by undesirable technical changes.
  • No, we should not bundle technical changes with monetary policy changes.
  • Yes, we should bundle technical changes with 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

I created this poll in a bit of a rush (as we’re expecting said bundled executive tomorrow). Apologies for the rushed points above and poor grammar. If anyone has other points, please express them below. I’ll add them to this post as they come in.

I would have liked more time to write up and discuss this. Unfortunately I only realised this was happening in the governance poll half an hour ago, and the technical fixes are due to be bundled in the executive tomorrow. If someone else wants to create another poll about the Foundation providing enough lead time for us to register objections, that could be valuable.

3 Likes

What are the two policy changes being bundled?

I was okay with the previous bundle of debt ceiling increase to 120 and stability fee decrease to 5% for SAI, but in general I think these types of policy packages should be avoided.

Based on the governance and risk meeting, it sounds like it will be:

  • SCD SF Change from 5% to 4%.
  • Two technical fixes presented by @wouter in the most recent Governance and Risk meeting (There should be forum posts detailing these arriving soon.)

I voted yes, because right now if we want to be nimble, it’s really the only way to do it.

Further on, once a better system is in place, we probably shouldn’t.

8 Likes

So to be clear, I’m not suggesting that we should delay the technical change in this circumstance. I’d much rather we let the monetary policy lapse for a week and prioritise technical issues.

If we’re in a situation when both require urgent changes in a single week, then I would be willing to see them bundled. Two emergencies at the same time? Fine, bundle them up. But an urgent (though non-emergency from the language used in the presentation?) technical change + a largely unnecessary monetary policy change? No.

In retrospect I should have added a poll option for ‘only in emergencies.’

Also thanks for explaining your reasoning, @Mariano_Conti. Would love to see more of that from all sides.

2 Likes

I voted yes, but i think this should be only temporary, maybe, 2-3 months. Even if there is no better system in place.

2 Likes

Having multiple executive’s means the already minimal amount of MKR taking part in governance is spread over more proposals which lowers the bar for an attacker to mess with the system, especially at the moment with the governance delay set to zero. (x-post from g&r RC channel)

3 Likes

This is true, however this is already the case.

There is 170k MKR voting in the Chief, it is split across five executives. The hat has 50k. Adding any new executive splits the MKR and increases the security risk, but we still do them. Furthermore, we do them on a fixed schedule, meaning that an attacker can wait until a new executive is launched and the MKR is maximally split before acting.

If the risk of doing multiple executives in one week is deemed to be too high, then I suggest we postpone monetary policy (in the absence of an emergency) if there is a technical change to be made.


I feel like the argument is being laid out between the best possible case for bundling, and the worst possible case for the alternative.

Would you still be arguing for bundling if this weeks SCD SF poll had resulted in a 0% fee for SCD? The poll passed with 900MKR. A better attack vector given bundling would be to vote for a ridiculous stability fee and force a bundle with an unacceptable monetary policy change along with a required technical change. What happens in that situation? As an initial thought, the executive would probably be really conflicted which results in splitting MKR across executive votes which opens up the same attack vector only it could very well be worse, espeically since we may then need to split the unacceptable bundle and create one or two more executives.

It’s possible that a single controversial executive bundle (along with the cleanup in the aftermath) could split the Chief MKR worse than two ‘easy pass’ executives back to back.

Also, out of curiosity, what is the objection to the poll options @rich.brown @twblack88 ?

I will echo what a few have written before me. For now, it seems to be the least complicated solution to bundle these proposals, due to the limitations of the current governance system. The downsides of splitting them up now are too severe.

I would support splitting them up in the future, if a satisfactory governance system can be designed and implemented that is (1) secure and (2) allows for short enough governance cycles to react in a timely manner to externalities without being hindered, or blocking proposals, or creating too much overhead.

Hey all. Here’s a simple solution for preserving monetary policy cadence (i.e., not breaking precedent), and dealing with the technical fix.

Tomorrow (Friday), we put out an executive vote just for the stability fee change.

As soon as the vote passes, within 24 hours we can put out a new executive vote for the technical fixes:

  • Flopper auction fix
  • OSM fix

After the flopper is fixed, the MKR authority can then transfer authority to the flopper so we can have debt auctions.

There may have been some confusion regarding the severity of the technical issues. I’ve spoken with the engineering team, and I don’t think there is an “emergency,” per se.

To be clear, there is minimal downside to currently not having a debt auction. If a tail event occurs, the bad debt will just sit there for a few days until the flopper is activated and business can proceed as usual.

Let’s not overcomplicate this.

6 Likes

My initial objection was the need for a middle ground. ‘Do it this time but not again’. Cyrus is going to post a better solution in a second.

1 Like

What if a week goes by and it hasn’t passed?

Apologies for over-complicating things, but I dislike solutions that don’t consider all the possibilities. Several executive votes haven’t passed. I’d say it’s reasonably likely that this will be one of them, considering that the poll only passed by 900MKR. That could indicate that most don’t see a necessity for change, and are unlikely to vote the change through in an executive.

Good to hear that the technical fixes aren’t high-severity though.


Makes sense, I’ll try to remember to include ‘just this once’ options in the future.

1 Like

I think the Maker team already expressed what I would add (need a middle ground, not all technical changes are to be rushed nor are they emergencies; rarely, singular bundling is OK).

1 Like

Then we start a new executive next friday, and technical fix can go after that one passes. Other than that, I think you bring up a good point. Do you have any other ideas?

This signal thread has moved to: Signal Request: How do we handle executive bundling in relation to technical changes?

I am now locking this thread.