*Restarted poll* [Signal Request] Raise the ESM threshold to 15% and increase the Governance Delay to 4 days

The maker protocol has grown significantly and is securing more assets than ever, as well as more battle tested than ever. The emergency shutdown feature has always been a critical part of the design of Maker, as it makes it possible to reduce the severity of many types of critical issues (such as governance attacks) to simply the shutdown of the protocol, rather than e.g. stealing all the collateral.

However, we are reaching a point where the core Maker security is so battle tested that the emergency shutdown feature is beginning to become a risk rather than a solution, as it increasingly looks like the most likely place for someone to try to damage the system, with only 75000 MKR currently needed to trigger ES. This is honestly making me quite nervous at this stage, and I dont think we should wait with fixing the vulnerability.

I propose we double this to 150000 MKR to make the risk of a sudden ES significantly lower and the system as a whole safer and more reliable.

To balance this change and mitigate the possibility that it might make a governance attack more attractive, I propose we also double the Governance Delay from the current 48 hours, to 96 hours (4 days). This way it will provide enough time to gather together enough MKR to react to a governance attack - obviously its not really possible to quantify this, but I think doubling both parameters is the simplest option that feels right.

  • Yes, increase the ESM threshold to 150000 MKR and the GSM delay to 96 hours
  • No, keep it as it is
  • Abstain

0 voters

Next Steps (added by LFW)
This poll will end on Thursday 21st October, and will proceed to an on-chain poll the following Monday if it ends successfully.

6 Likes

I’m concerned about the degree to which Maker is integrated with other blockchain protocols. If the GSM delay is extended to 96 hours and there is a vulnerability in, for example, the optimism bridge or G-UNI or D3M then could the 96 hour delay hamstring our emergency response?

5 Likes

When we start onboarding serious amounts of Real World Assets the Emergency Shutdown Module makes no sense anymore. We should be prepared to disable or replace it with a Partial Shutdown Module of some sort.

3 Likes

A “partial shutdown module” would mostly be implemented through offchain processes rather than by changing the protocol itself, as it relates to how you redeploy the system. Basically the new deployment would have pre-generated vaults that contain collateral tokens that somehow would take over the legal claim of the tokens in the old protocol, and pregenerated dai. All the pregenerated dai would then be sent to the ES claim contract, so lets say if maker is backed 50% by ETH and 50% by RWA, then in ES you would get 0.5 new dai (backed by RWA) and 0.5 USD worth of ETH.

2 Likes

Please use the recommended settings for the poll, and read through the other best practices for signal requests. You can find them here. This hasn’t been up for too long, so I’d recommend restarting the poll.

2 Likes

Personally, I think a longer GSM delay makes sense at this point, even without modifying the ESM threshold. Responding to a sudden issue like Black Thursday or a vulnerability in another protocol needs to be done in much less time than 48 hours to achieve meaningful results, and is why we build instant access modules for risks we’re really worried about (e.g. oracle attacks). OTOH it makes a big difference having 4 days instead of 2 to mobilize MKR holders to drop a malicious spell. 4 days is also still less than the time lag between sufficient bad debt accruing and flops starting, which is currently 6.5 days, so we’d have about 2.5 days to react and postpone flops if for any reason that were necessary.

The part I’m not sure about is the 150K MKR limit on the ESM. For comparison, there’s only about 150K MKR in the Chief currently, about ~75K of which is delegated. I worry that a 150K threshold is already enough to functionally disable the ESM, given how slow-moving large MKR whales tend to be. I’d prefer a more conservative increase, e.g. to 100K or roughly 10% of supply. Maybe around 110K at most, which I think is roughly the heaviest weight that’s ever been on a single spell at a given time.

8 Likes

If we have reliable ways to circumvent the GSM in a crisis, that moves me to support this — I had been a bit conflicted about a longer GSM after watching Compound last week.

Re: ESM itself, I feel uncomfortable with the actual ability for us to shut down. As DAI grows, we have to think not just about Maker or even vault holders, but systemic risk. There are increasing amounts of prices and debt obligations denominated in DAI, so it’s not as simple as just DAI holders, either. We should probably come up with some kind of new plan that can minimize possible disruption to financial markets. Making ESM more difficult to activate as we figure that out feels correct to me.

Agreed with increase to 150K MKR for emergency shutdown but I think we should not increase the governance delay any further. Hence voted no.

The current 2 days is already making the Maker governance some inefficiency, that any executive proposal passed needed to wait for 2 days to be in effect. 2 days can be long in the crypto timeline, where projects (e.g., Liquity) are using codes and algorithms to make things faster and efficient, while we are looking to further increase the GSM delay? I think we should focus on making things more efficient instead of increase further the GSM delay, perhaps consider some kind of automated algorithms to replace governance for some simple functions as the start? For example, if ES of 2 day is not sufficient, we can have an algorithm that once this specific module is triggered, it takes 4 days to be in effect, and the delay does not affect other executive proposals.

There was lots of discussion on this in the most recent governance and risk meeting, some of which was arguments against. If you were present, and had already voted, this is your reminder to update your vote if you’re inclined to do so.

1 Like

I couldn’t make it to the call last week, but my preference is to have ESM threshold be a bit lower than the 150k proposed and GSM delay kept the same at 2 days.

There was a good discussion on why a 4 day GSM delay may not have a significantly different outcome compared to 2 days when responding to potential bugs in most hypothetical cases, but I think the 4 day period is more problematic when it comes to changing system parameters for operational purposes, especially during volatile and unpredicted systemic events after this bull run. For instance if we needed to change auction parameters or lower debt ceilings (see Monetsupply’s post on DC-IAM gap/ttl parameters).

8 Likes

Having thought about this a bit more. I’d be concerned we may paint ourselves into a corner where we aren’t able to cast the spell after an executive in a timely manner once the office hours modifier is accounted for.

An example, exec is posted on Friday, doesn’t pass until Tuesday evening, GSM pause delay will expire on Saturday and office hours will delay things until the following Monday. This is 10 days after the executive was initially posted. This risk is probably higher now we have lost Planet’s voting power.

Is this an acceptable delay? Perhaps. More realistically if we are enacting this then we may want to move away from putting up execs on the Friday. Would be interested to hear thoughts on @prose11 and @LongForWisdom on this.

Definitely an important consideration. Basically the delay balances the time needed to detect an error/attack with the need to be nimble in the face of changing market conditions or undiscovered errors from previous proposals.

Doing the executives on a different day is something we can look into, especially if the delay becomes a concern. There are a few nice things about dining it on Friday however:

  • gives teams time to coordinate throughout the week
  • allows for discussions from the G&R to be considered in upcoming executive
  • prevents the need for weekend coordination outside of urgent/emergency situations

Basically it’s all a balancing act, but reworking our cadence is worth discussing if we do mess with some of the delay parameters.

1 Like

Thanks Payton. Perhaps we can discuss on the GovAlpha call later.

The current executive is a good example of this. With a GSM delay of 4 days if it hasn’t passed by end of office hours today it wouldn’t be executed until next Monday.

1 Like

Ok. My take because I have been flagging ES as a possible attack vector for a while.

Really would like to hear from PECO on this.

My take. Right now Maker has not even done a ES test. My understanding is MKR has to pull from governance to enter the ES contract. Without one single test on whether a ES could even be activated in a reasonable time (or what threshold is suitable) a number is just picked out of the air without data.

As to the GSM delay. Completely against 4 days because again without any data or sort of test we can’t even assess what is a decent delay or under what conditions we already have the required control.

What I really want to see here is a real Risk assessment (thank you @Primoz for commenting) and @Derek PECO to comment as well. I believe we need to run two different test scenarios at least once and probably a couple times before we can properly assess what these settings should be based on MKR participating in governance.

  1. govAlpha ES test dry run. A quick and easy way govAlpha to throw up a ES test for MKR inside and outside governance to signal it would be ready to accomplish the on-chain tasks with another on-chain signal) but to ‘not do them in actuality’.
  2. Emergency executive dry run test. Same deal - govAlpha throws up a emergency executive test and put up a on-chain response for MKR in governance to signal.

Ideally would like to run these kinds of tests on a cheaper chain or via a model where key signers can just sign when they would be ready to act.

Measure response time and use this data to determine the proper ES and GSM delay settings.

FYI: Without above data I sit with @Primoz with general impression here.

Because of the lack of data and even a lack of coherent response from CUs and the DAO here I am a no. Not because I don’t want to change this or see issues, but because the proposed changes are arbitrary and somewhat extreme and may have unintended consequences.

I really want to urge GovAlpha to come up with the proposed tests and to collect data on MKR/governance response times so we can properly tune these. We also need to make these tests part of the system operational readiness review process.

2 Likes

I voted against since 150k is too much. I am ok with 4 day GSM delay, although I would prefer 3 days.

This signal failed at the on-chain polling stage here. I would recommend repeating the signal and splitting the parameters and providing a range for each. A more data-based approach would also be welcome if possible.

Thank you to all who voted.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.