One important security feature of the Maker Protocol is called Emergency Shutdown. This crucial security feature allows the system to shut down and make underlying collateral available for redemption by Dai holders and Vault owners.
Emergency Shutdown is activated: If MKR voters believe that the system is subject to a high-severity attack, or if an Emergency Shutdown is scheduled as part of a technical upgrade, they can activate an Emergency Shutdown. This locks the system, freezing the DSR, stopping Vault creation and the ability to generate Dai, and locally freezes the Reference Prices. Vault owners can immediately withdraw excess collateral.
Cooldown Period: After Emergency Shutdown is activated, a time period is needed to allow any ongoing collateral auctions to conclude. Once all collateral auctions finish, the system can calculate the distribution of collateral to remaining Dai in circulation.
Dai owners claim collateral: Each Dai holder can redeem their Dai directly for a fixed amount of collateral.
There are two primary ways that an Emergency Shutdown could be triggered. One way is through the Emergency Shutdown Module(ESM), which allows for a shutdown to be triggered by a minimum number of MKR called the Emergency Shutdown Threshold. Emergency Shutdown may also be triggered through a regular Executive Vote, though the ESM would be a more direct method that does not have to wait for the delay period imposed by the Governance Security Module.
Technical documentation about how the Governance Security Module works can be found here.
Emergency Shutdown may be used in the cases of attacks on the system, significant economic issues, and major upgrades.
Examples of attacks on the system include hacking or security breaches of the smart contracts, manipulation of the Oracles, and attacks on governance through ratified malicious proposals.
Examples of significant economic issues include the scenario of a severely broken peg (as decided by MKR voters), and other market scenarios if they pose a significant and real threat to a majority of users.
An example of a major technical upgrade that will warrant an Emergency Shutdown is the upgrade to Multi Collateral Dai, as a method to shut down Single Collateral Dai after the transition period. Governance is encouraged to avoid Emergency Shutdown unless absolutely necessary. Technical upgrades of a smaller scale can be done without Emergency Shutdowns.
Hitting a Debt Ceiling marks the moment where new Dai cannot be generated by a particular Vault type. This is not an immediate threat to the stability of the system as Dai can still be minted from other Vault types. Additionally, any problems can be mitigated by raising debt ceilings, therefore it is not necessary to perform an Emergency Shutdown on the system. Emergency Shutdown is a very disruptive process and should only be used in cases of last resort and planned upgrades.
The redemption of collateral claims will occur manually. After a cooldown period which waits for all collateral auctions to complete, Dai holders will be able to redeem collateral through a series of individual transactions for each collateral type.
When Emergency Shutdown is triggered there may still be auctions running. The delay period gives time for those auctions to settle and for the internal system balances to become final.
Both Vault owners and Dai holders need to redeem collateral. However, they do so in different ways. Vault owners will be able to withdraw all excess collateral, netting them out of their positions as the remaining collateral value is equal to their outstanding generated Dai. Dai holders will go through the main collateral claim process.
Yes, it is possible for users to get less than a dollar worth of collateral for their Dai. Vault owners are able to immediately redeem their excess collateral and are less likely to experience a haircut. Dai holders are subject to the volatility of the underlying collateral portfolio after Emergency Shutdown is triggered.
To trigger an Emergency Shutdown, a minimum threshold of 50,000 MKR must be placed into the Emergency Shutdown Module(ESM). Therefore, it depends on how quickly MKR token holders can come together to decide on whether to trigger an Emergency Shutdown. All MKR placed in the ESM is permanently lost, and can only be retrieved after redeployment as a decision of MKR governors.
After Emergency Shutdown is triggered, the collateral redemption process takes place. It is up to anyone whether they want to redeploy the system or not, and how they would deploy it.
Anyone can redeploy the system since the Maker Protocol is open source.
Since the Maker Protocol is open source and decentralized, anyone can redeploy the system and decide with what configuration. Ideally, the parameters of redeployment should depend on the reason for the Emergency Shutdown, and should not be altered unilaterally and arbitrarily. What will likely happen is that the Maker governance community will come to decide on the most appropriate redeployment, or to launch a redeployment themselves with the appropriate configuration. Here is a rough example of a framework for protocol changes on redeployment:
Fork out malicious MKR holders and reimburse MKR placed in the ESM in new redistribution, redeploy system with everything else as-is.
Fork out Oracle module for a new one with a vulnerability fix, reimburse MKR placed in the ESM, redeploy system with everything else as-is.
Black Swan event in the Markets
Allow MKR voters to decide how best to address this event through new or improved system mechanics that can be added into the new deployment. Redeploy with the new improvements if necessary, reimburse the MKR placed in the ESM.
Unwarranted Emergency Shutdown
Fork out malicious MKR holders that triggered the ES, redeploy system with everything else as-is.
Depending on the details of each redeployment, the market, along with various system participants will have to choose the one with the most appropriate changes. Some factors include:
No unwarranted code changes
Changes in the distribution of the MKR token
Changes in the Risk Parameters
During Emergency Shutdown, excess collateral is immediately made available for withdrawal by Vault owners. The remaining collateral in all Vaults is made available for redemption by Dai holders.
MKR holders are incentivized to preserve the value of their MKR. Performing an Emergency Shutdown because of the fear of imminent dilution may have a negative impact on the value of their MKR. Emergency Shutdown also puts their MKR ownership at risk, as the MKR placed in the Emergency Shutdown Module is permanently lost unless it is reimbursed as a part of a redeployment.
Any Dai or Vaults that have been stuck or lost will remain so afterward, they will effectively be stuck or lost collateral instead.
Stability Fees are part of the accounting of the system. They are continuously added to a Vault owner’s generated Dai balance as they accrue. During Emergency Shutdown, this means Vault owners will indirectly pay their Stability Fees by not being able to withdraw more collateral than the excess in their Vault.
Emergency Shutdown will:
Set the Dai Savings Rate to zero.
Cancel or allow auctions to finish depending on the type of auction and phase it is in.
Freeze Oracle price-feeds locally to the Maker Protocol.
No longer allow the use of Maker Vaults.
Any applications that plug into the Maker Protocol by utilizing MakerDAO Auctions, DSR and Vaults will experience a disruption in these areas. Projects depending on the Maker Protocol’s Oracle infrastructure will not experience a disruption in service.
Yes, an Emergency Shutdown has been performed on the old Sai system, before Single Collateral Dai. Emergency Shutdowns have also been performed in staging environments on the current Maker Protocol as a part of functionality and scenario tests.
Emergency Shutdown was originally introduced and tested with the Sai prototype deployments. Besides the tests in the code itself, there were three live runs, all of which happened on deployments of the Sai prototype on the Ethereum mainnet.
For Multi-Collateral Dai, the Maker Foundation performed shutdowns on both Kovan and Mainnet deployments of MCD as well as unit tests.