*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?

4 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.

2 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.

1 Like

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.