[Informal Poll] Should We Raise the Minimum MKR Needed to Call End.Cage for Emergency Shutdown?

The Maker Community knows that in order to initiate Emergency Shutdown (ES) 50,000 MKR must be deposited into the Emergency Shutdown Module to trigger ES. This can be done by calling end.cage or, by an Executive Vote.

At the current 30-day trading average for the price of MKR, the cost to orchestrate such is approximately $110,000,000. Jeff Bezos made around $321 million per day in 2020. $110M is approximately 5% of Chiliz (CHZ) Market Cap per Coingecko – no disrespect to Chiliz, but think about that.

And yes, I know it’s hard to market buy 50,000 MKR in the open market, we can also Vote to Fork Maker, but what is stopping an attacker such as Nation-States from accumulating MKR one (1) MKR at a time and cause great damage to DeFi? Or even a Regulator who has a budget larger than $110M (SEC budget: $1.9B)? Honestly, would it cripple the entire DeFi ecosystem? Not sure, but it would set us back a few crypto years. With that in mind:

Should We Raise The Minimum MKR Required to Initiate Emergency Shutdown?
  • Yes
  • No
  • Abstain

0 voters

How Much MKR Should be Deposited Into the ESM to Trigger ES?
  • Same (50,000)
  • 75,000
  • 100,000
  • 150,000
  • Abstain

0 voters

EDIT: Sorry @Replenish2030 can you Poll again I forgot to make who voted public for the 2nd question.


Why isn’t this a signal request? Don’t be afraid of the process!

Some food for thought.

Screen Shot 2021-04-01 at 4.19.01 PM

Probably good for @Risk to weigh in on this.


I was thinking about it actually, we currently have a very poor security over the hat and ES.

If you can even borrow more MKR on aave + exchange then I believe paying them back should cost you close to zero.

Which should give you a potentially net income by shorting MKR.

There is currently probably around 85% of MKR which can be borrowed with in the known exchange ( aka bots). That is very close.

1 Like

Yea–Wanted to see what @LongForWisdom thought of all this.

Thanks for that screenshot–good catch!

1 Like

If you intend for this to continue to an on-chain poll and lead to a change in how much MKR is required to trigger emergency shutdown, then yes, it would need to be a signal request.

If you want to discuss the idea and get an idea of how people feel about it, then this is fine.


+1 for making this a Signal Request


Is the intention of the ESM to be a % of the total supply? Or is it meant to be a sufficiently large amount relative to the current state of the project?

1 Like

Alright, I have upgraded it to a Signal Request – Let’s see what the Community wants.

I believe it is the latter Shane. Maybe someone who has been with the Protocol since inception can comment. Not sure why 50,000 MKR was chosen in the early days. I suspect that the theory was that it would not be easy, and/or painful to burn millions of dollars (MKR) worth of value.

1 Like

@ElProgreso if it’s a signal request you need to make an effort to follow the Practical Guide to the Signaling Process


  • There should be a clear end date,
  • Category and tags should be fixed.
  • Title should be in the form of a question.

Ideally it should also begin with a summary of the essential information around the issue, perhaps in the form of pros and cons.

I just want to reiterate that the consequence of increasing the ES minimum is that we will probably have to increase the GSM to more than 48 hours. It should also be done in tandem with this parameter change. Hope to hear from mandated actors what an acceptable change would look like (96 hours? More?) This might create some new tail risks.


@LongForWisdom understood–as @Aaron_Bartsch has made some excellent points, I will keep it as an “Informal Poll” – perhaps the @risk Team can then take it from there. As Aaron mention there are some other Risk involved with increasing the ES minimum.

My biggest point is that it is very inexpensive for an attacker to have a go at it. With the inflation of Assets, the popularity of DeFI, and folks feeling more liquid–it’s no longer an expensive attack as it was in 2018.


I understand the risk but this might be mitigated in just a few more months if MKR appreciates in value.

I am not sure I like the idea of moving to >50k MKR.
50k makes it possible for single whales, or groups of big fishes, to start an ES in case of emergency.

Rising it to 100k or 150 would make it almost completely depend on Governance processes or significant coordination, anyway. I am not sure, really.

This is indeed something for the risk team, I believe: there are several types of (conflicting) risks. We can’t set this number just on ‘gut feeling’.

For this reasons I voted “abstain”.


Yea totally—but you got to have more than a “gut feeling” to stay ahead of the game, right? Perhaps intuition? Sort of like following trends, and looking for the next big thing—you know what I mean… it’s kind like the intuition you had when joining this community.


Since there seems to be some contention around this, I want to explain the thought process behind my vote to increase. I believe that setting the ES trigger at different levels adds not only a practical, but cultural implication for when it should be triggered. If it’s low enough for one large holder to trigger (like it is now), there’s an implication that it should be triggered more easily and a greater likelihood that it will be triggered.

I think as a community we need to outline explicitly when we believe an ES should be triggered and set the level at a rate that’s in line with the difficulty of our choice. For me personally, the only situation where I would consider triggering ES is one where a bug or hack is causing the protocol to lose its over-collateralization. For instance, if the system is (in aggregate) 250% over-collateralized, I would not consider triggering ES unless 60% of the collateral was at risk or Dai was able to be inflated enough to drag the aggregate collateralization below 100%. I’d also want to know that there was absolutely no other way to solve the problem, but I think that goes without saying.

I’m aware that this may be a controversial opinion or even an unpopular one, which is why we need to have this stuff written in stone and voted on in advance - so that whichever actor has the unfortunate responsibility of pulling that trigger (and let’s hope they never do), they can do so with the confidence that the community will not fork them out of the system in a redeployment.


Yeah I totally agree with this.

Just to add a note on your comment, I also consider this event:

Suppose the (majority of) MKR holders become greedy, for whatever reason, and decide to print unbacked DAI, or to onboard a ridiculous amount of very risky assets.

At the current ES level (50k), a responsible MKR whale might not be able fight this vote (because they have only 5% of the MKR) but they are able to trigger a ES protecting the DAI holders.

NOTE: We voted, around October, for a ‘declaration of intent’ saying that we are ready to burn the MKR of anybody triggering the ES for reasons that are considered not adequate. So, in the above Example, the whale might accept to see their 50k MKR evaporate to save the DAI holders (maybe themselves) from risk.


Hey folx,

I wanted to weigh in with some thoughts from the @Risk side. Also worth mentioning that emergency shutdown mechanism is interrelated with technical, oracle, and governance matters. Emergency shutdown is both a source of risk to the protocol and a key risk mitigation mechanism, so any changes need to be carefully balanced.


Emergency shutdown can become necessary in response to auction issues, critical technical faults, oracle issues, or governance attacks (among other things). The response timelines needed and alternative options vary based on the circumstance:

  • For critical oracle faults where a bad OSM price was queued, MKR holders would need to muster a response within 1 hour. If it was not possible to sufficiently mitigate losses via other means (e.g. by deactivating liquidations on affected collaterals), holders would need to trigger shutdown.
  • For technical issues, it may be possible to organize a fix via the Dark Spell Mechanism. If it was not possible to issue a fix safely, or if the system was being actively exploited or drained, it would be necessary to trigger emergency shutdown to limit damage.
  • For governance attacks, MKR holders could first attempt to pass a further vote to cancel the malicious pending executive. This requires surpassing the MKR balance on the current executive within the governance delay period (currently 2 days). If it’s not possible to meet this higher token threshold, MKR holders would need to trigger emergency shutdown.
  • For auction issues, MKR holders may be able to avoid losses by deactivating liquidations (which is not behind the GSM delay). If this does not sufficiently mitigate the issue, it would be necessary to pass an executive and wait for the GSM delay, or trigger shutdown.

If emergency shutdown was triggered in a case where it was not necessary, this would cause substantial disruption to Maker and the wider defi ecosystem. DAI would cease to function as a stablecoin, instead tracking its underlying basket of collateral. While impact on DAI holders would vary depending on market conditions, it seems likely there would be a rush to dispose of unstable collateral in exchange for an alternative stablecoin, likely leading to losses at least in the short term. Integrated lending or derivatives products collateralized in DAI would also become unstable.

While this would be extremely problematic, an alternative case where emergency shutdown was unable to be triggered when necessary would be even more disastrous. In a worst case scenario, all system collateral could be lost which would result in total losses for both vault owners and DAI holders.

DAI holders don’t necessarily benefit from the aggregate system collateral levels, as vault owners are able to receive excess collateral first before DAI holders can redeem during emergency shutdown. It’s possible for DAI to become underfunded well before system collateralization reaches 100%.

While mitigating governance attacks are one important use case for emergency shutdown, the window of opportunity for triggering ES is relatively long. Increasing the GSM delay could impede responses to oracle, auction, or technical issues, in addition to slowing down non emergency governance action.

Malicious Shutdown Threat

To trigger emergency shutdown, users must burn their MKR tokens. In most cases this would impose a substantial financial cost upon an attacker, but there may be certain hedging mechanisms available that would make the process less costly. For example, an attacker could borrow tokens from Aave v1 or v2 and use them to trigger shutdown, on the assumption that they’d be able to repurchase at low prices in the ensuing market turmoil. It may also be possible to open short positions via futures or perpetual contracts to offset the cost of the MKR tokens burned.These strategies assume MKR tokens would substantially fall in value during an emergency shutdown attack.

Certain competing protocols or hostile organizations may also have a vested interest in MakerDAO’s failure, with financial stakes that outweigh the cost of acquiring and burning 50,000 MKR.

Next steps

We can help mitigate risk of emergency shutdown through a holistic approach to operational readiness and governance security.

First, we should adopt and implement a protocol continuity plan. Continuity planning is a standard practice (often required by regulators) for mission critical businesses like financial institutions. Testing response plans for various emergencies will give us a better idea of the appropriate token requirement for triggering shutdown and minimum response times required to take action.

We can also engage with parties offering short interest on MKR to see if we can encourage them to curtail these products. Without borrowing or derivatives liquidity, it will be much more difficult for potential attackers to avoid the financial cost of triggering emergency shutdown. Aave is a primary source of MKR borrowing liquidity and would be a good target for DAO engagement. MKR is also listed on several centralized derivatives and lending venues, which may be more difficult to curtail.

Offering additional utility for keeping MKR tokens within the Maker system is another strategy to help mitigate the issue. The governance rewards mechanism would make holding long MKR positions through derivatives or lending platforms less competitive, which would increase the cost of financing short positions. Offering MKR holders an opportunity to borrow through the Maker may also incentivize users against supplying assets to external platforms.

Finally, a continuous monitoring program for MKR tokens could help MakerDAO understand governance risk conditions and set relevant parameters. This could include review of MKR liquidity and availability on spot, lending, and derivatives platforms, as well as ownership changes and concentration.

With respect to the emergency shutdown threshold, I propose an increase to 75,000 MKR. This is comfortably above the MKR liquidity on Aave v2 (35,000), Aave v1 (7,000), and reported open interest on perpetual swaps on Binance and FTX (roughly 5,000), which helps reduce attack risk. On the other hand the threshold would remain low enough to be confident in voters’ ability to respond in an emergency - MKR holders were able to activate nearly 75,000 votes within a few hours to pass last week’s executive vote.


+1 for a Signal Request… From my lens, this needs to happen.


I think we should also take into consideration that aave is in constant increase. While today we can find 47k as “know sources”, which is very close to the 50k. In one month how much can be sourced from there?

Also if you assume MKR will drop by 50%. With 75k, you can still be close to be profitable by provide 25k on top of the 50k shorted.


@ElProgreso When does this informal poll go to a full signal request?


We’re going to discuss this some in the Governance and Risk Meeting tomorrow. TLDR: We need to replace the end contract anyway for liquidations 2.0, so we’re considering doing an increase to 75k as part of that change.