Introducing the Shutdown Mechanism of the Maker Protocol
The Maker Protocol, which powers Multi Collateral Dai, is a smart-contract system that backs and stabilizes the value of Dai through a dynamic combination of Vaults, autonomous system of smart contracts, and appropriately incentivized external actors. The Dai Target Price is 1 US Dollar, translating to a 1:1 US Dollar soft peg. Shutdown is a process that can be used as a last resort to directly enforce the Target Price to holders of Dai and Vaults, and protect the Maker Protocol against attacks on its infrastructure.
Shutdown stops and gracefully settles the Maker Protocol while ensuring that all users, both Dai holders and Vault holders, receive the net value of assets they are entitled to.
In short, it allows Dai holders to directly redeem Dai for collateral after an Emergency Shutdown processing period.
The process of initiating Emergency Shutdown is decentralized and controlled by MKR voters, who can trigger it by depositing MKR into the Emergency Shutdown Module.
Emergency Shutdown is triggered in the case of serious emergencies, such as long-term market irrationality, hacks, or security breaches.
Emergency Shutdown stops and gracefully settles the Maker Protocol while ensuring that all users, both Dai holders and Vault users, receive the net value of assets they are entitled to.
For more information about the Shutdown of the Maker Protocol, read the below End - Detailed Documentation as well as the
Dai holders can, after a waiting period determined by MKR voters, swap their Dai for a relative share of all types of collateral in the system. The Maker Foundation will initially offer a web page for this purpose.
Dai holders always receive the same relative amount of collateral from the system, whether they are among the first or last people to process their claims.
Dai holders may also sell their Dai to Keepers (if available) to avoid self-management of the different collateral types in the system.
Shutdown
Contract Name: end.sol
Type/Category: DSS
The End's purpose is to coordinate Shutdown. In short, Shutdown closes down the system and reimburses Dai holders. This process can occur during upgrades (Dai iterations), as well as for security reasons in the event that implementation flaws arise in both in the code and in the design.
cage - Locks the system and initiates shutdown. This is done by freezing the user-facing actions, canceling flap and flop auctions, locking the rest of the system's contracts, disabling certain governance actions that could interfere with the settlement process, and starting the cool-down period.
cage(ilk) - Tags the Ilk prices / Sets the final price for an ilk (tag).
skim - Settles a Vault at the tagged price / Cancels owed Dai from the Vault
free - Remove (remaining) collateral from a settled Vault. This occurs only after there is no debt in the Vault.
thaw - Fixes the Dai supply after all Skims / Fixes the total outstanding supply of stablecoin.
flow - Calculates the fixed price for an ilk, possibly adjusting the cage price with surplus/deficit.
pack - Locks Dai ahead of Cash / Puts some stablecoin into a bag in preparation for cash.
cash - Exchange packed Dai for collateral / Exchange some Dai from bag for a given gem, share proportional to bag size.
file - The Governance configuration—sets various parameter values.
skip - optionally cancel live auctions.
wards(usr: address) - Auth Mechanism
vat - Vat contract
cat - Cat contract
vow - Vow contract
spot - Spotter contract
live - Cage flag
"Live" contracts have live = 1, indicating the system is running normally. Thus, when cage() is invoked, it sets the flag to 0. This includes the End contract, which means that cage() can only be invoked once and the subsequent functions cannot be invoked until we are "dead" and in the End process
ilk - A collateral type
when - Time of cage / the time of settlement.
wait - Processing cooldown duration / the length of processing cooldown.
debt - Outstanding Dai after processing / outstanding stablecoin supply, after system surplus/deficit has been absorbed.
tag - Cage price / price per collateral type at time of settlement.
gap - Collateral shortfall / shortfall per collateral considering undercollateralised Vaults.
Art - Total debt per Ilk/outstanding stablecoin debt.
fix - Final cash price / the cash price for an ilk (amount per stablecoin).
bag(usr: address) - Dai packed for cash / nontransferable stablecoins ready to exchange for collateral.
out - Cash out / the amount of already exchanged stablecoin for a given address.
skip - Optionally cancel live auctions.
wad - Some quantity of tokens, usually as a fixed point integer with 10^18 decimal places.
urn - A specific Vault.
tend - To make a bid, increasing the bid size.
bid - The quantity being offered for the lot.
lot - The quantity up for auction.
dent - To make a bid, decreasing the lot size.
The cage is the most complex mechanism within the Maker Protocol. This is because the cage must alter the behavior of almost every component of the system as well as perform under a variety of possible undercollateralization regimes. Listed below are a number of key properties, such as Dai and Vault parity, or the lack of race conditions, which are desirable (nice-to-have) properties of Shutdown, and are not, in fact, all satisfied by the real-world implementation of Shutdown.
Dai Parity - Assuming there is enough collateral in the system, it is the sum of the values of each collateral redeemed from 1 Dai equal to the target price (i.e., $1.00 ), as judged by the collateral price used by cage.
Vault Parity - Where each Vault is settled at the collateral price during the time of global settlement. For example, the value of the collateral left in every Vault after cage will be the equity value of the Vault before cage, as judged by the collateral price used by cage, or zero, whichever is greater.
Dai no-race condition - every dai holder will be able to redeem the same quantity of collateral, regardless of when they interact with the contract.
Vault Parity - Vault Owners are prioritized and are allowed to redeem their excess collateral before Dai holders.
At the time of Emergency Shutdown (ES), individual Vaults, entire collateral types, or the Maker protocol can be undercollateralized, which is when the value of debt exceeds the value of collateral ("negative equity").
Dai Redemption vs. Vault Redemption Discussion
Since in some edge cases it will not be possible to satisfy all desirable properties at once, a choice must be made about which to prioritize. For example, in the presence of Vaults that have become less than 100% collateralized, a choice must be made between prioritizing Dai holders and Vault holders. If Vault holders are prioritized, those with over-collateralized Vaults keep their excess collateral, while Dai holders receive less than $1 of value per Dai. If Dai holders are prioritized, some collateral must be taken from over-collateralized Vaults to ensure Dai holders receive as close to $1 per Dai as possible. When choosing between Dai vs. Vault priority, Vault priority was chosen because we want to first prioritize Vault holders, meaning that even with a processing period for auction settlement, all Vault holders above their Liquidation Ratio (LR) should be allowed to retrieve their over-collateralization (This is accomplished by calling skim first on the Vault to remove the debt and the backing collateral and then calling free to release the remaining collateral from the Vault).
There is a time delay in Shutdown that is configurable by governance. The time delay must expire before any cashing can take place. The general guidance is that it should be long enough to ensure all auctions either finish or get skipped, but there is no guarantee of this in the code. Note that anyone can cancel a flip auction at any time by calling skip(ilk, auction-id) after the ilk has been caged (with cage(ilk)). Flap and flop auctions are frozen by the initial cage(). Both Flap and Flop auctions can be yanked to return the bids to the last bidder.
As mentioned above, the End's purpose is to coordinate the Shutdown of the system. This is an involved and stateful process that takes place over the nine following main steps.
cage() :The process begins with freezing the system and locking the prices down for each collateral type (ilk). This is done by freezing the following user entry points:
Halt the ability to deposit collateral and draw Dai from Vaults
Flap/Flop Auctions
Dai Savings Rate (DSR)
Governance entry points like rely/deny and file
Next, the system will stop all of the current flop/flap auctions allowing individual auctions to be cancelled with calls to yank on the respective auction contract. One reason these auctions get frozen and canceled is because the shutdown process was designed to pass along the system surplus or system debt to Dai holders. Additionally, there are no guarantees regarding the value of MKR during a shutdown, so mechanisms that rely on MKR's market value cannot be relied upon, which means there is no reason to keep running the auctions that impact MKR supply. More specifically, the reason for flop and flap auctions getting canceled is as follows:
flap auctions will no longer serve their purpose. This is because, after a shutdown, the surplus is designed to be allocated to Dai holders. Thus, canceling flap auctions during shutdown allows the system to return the surplus Dai back to the Vow’s balance and ultimately back to Dai holders.
flop auctions also stop serving their purpose. This is because the bad debt is passed as a haircut (lower-than-market-value placed on an asset being used as collateral in a Vault) back to Dai holders if there is no other system surplus available.
As for flip auctions, they are not immediately canceled (but can be canceled by any user) because they are still tied to the valuable collateral in the system. Collateral auctions continue to run and Keepers can continue to bid on them, and if not, the auctions can be skipped.
Despite the fact that auctions can continue to run, this does not guarantee that all of the remaining Vaults are overcollaterlized. There is also nothing that can prevent the undercollateralized and unbitten Vaults from existing at the moment cage() is called.
During this time, cat.bite cannot be called as the function requires live == 1, disabling liquidations after shutdown. Additionally, after the End begins, all vaults must be skimmed and then freed.
Overall, this results in flip auctions being able to continue during Shutdown or by having them reversed by a user by using skip() (similar logic to flap auctions). If an auction is skipped, the bids are returned to bidders and collateral is returned to the original Vault (with the liquidation penalty applied in the form of increased debt).
Other notes regarding flip:
End calls yank on the Flipper.
yank closes a tend-phase (allows bids to be made, thereby increasing the bid size) of the auction by returning the guy's Dai bid and moving the Gems from the Flipper to the End.
Notes:
MKR could still have value if the same token is tied to another deployment of the system. Note that the system makes no assumptions about the economic value of MKR post-Shutdown.
It is important to note that on-auction debt and surplus are canceled and balances are transferred to the End contract. The last step in this process is to begin the cooldown period.
cage(ilk) :The cage(ilk) works by setting the cage price for each ilk. It does this by reading off of the price feed. This is required as we must first process the system state before it is possible to calculate the final Dai/collateral price. In particular, we need to determine two things:
(a) The gap, which is the collateral shortfall per collateral type by considering under-collateralized Vaults. (b) The debt, which is the outstanding Dai supply after including the system surplus/deficit.
We first determine (a) by processing all Vaults with the skim function described below. Next, you can see how (b) unfolds below.
skim(ilk, urn)The skim(ilk) function works to cancel all of the owed DAI from the Vault. Any excess collateral remains within the Vault(s) for the owner(s) to claim. Then, the backing collateral is taken.
We then determine debt (b) by processing the ongoing Dai generation processes of the auctions. This is done to ensure that the auctions will not generate any further Dai income. This guarantees that ongoing auctions will not change the total debt of the system. This includes the two-way auction (Flip) model not allowing for any more Dai to be generated. This means that the Dai generation comes from tend auctions. Thus, if everything is in dent we know the generation is over. This occurs when all auctions are in the reverse (dent) phase. In addition to ensuring that the auctions will not generate any further Dai, the Dai Savings Rate (pot.drip) must also be shut off during the End so that the total debt does not change.
Example:
In terms of user scenarios, this means that the process begins with users starting to bid more and more Dai until reaching the debt. Next, they start offering less and less collateral.
The auctions that are in the second phase (dent - reverse auctions) no longer affect any more of the total debt, as the Dai was already recovered. Lastly, for the auctions in the first phase, they can be canceled and return the collateral and debt to the Vault.
There are two methods of ensuring this:
By using wait; or
By using skip.
wait or skipwait sets the cooldown period. The time duration of wait only needs to be long enough to be able to skim all of the undercollateralized Vaults and skip all tend-phase auctions. This means that it can, in fact, be quite short (for example 5 minutes). However, due to the possibility of scenarios such as network congestion occurring, it may be set longer.
When using skip, it will cancel all ongoing auctions and seize the collateral. This allows for faster processing of the auctions at the expense of more processing calls. This option allows Dai holders to retrieve their collateral much faster. The
Note that both of these options are available in this implementation, with skip being enabled on a per-auction basis. When a Vault has been processed and has no debt remaining, the remaining collateral can be removed.
free(ilk) :The free(ilk) method will then remove the collateral from the caller's Vault. After skim has been called, free(ilk) allows the owner to call as they need. It will remove all of the collateral remaining after step 3, basically, all of the collateral that was not backing the debt. If you did not have debt in your Vault at the time of the End you do not need to do step 3 and can proceed directly to this step to free your collateral.
thaw()After the processing period has elapsed, the calculation of the final price for each collateral type is possible using the thaw function. The assumption is that all under-collateralized Vaults are processed and all auctions have unwound. The purpose of thaw is to fix the total outstanding supply of Dai. Note that it may also require extra Vault processing to cover the vow surplus. The vat.dai(vow) == 0 requirement is what guarantees that the vow surplus has been taken into account, which means that before you can thaw, you must skim as many Vaults as needed in order to cancel any Dai surplus in the vow. Canceling Dai surplus is done by calling vow.heal before thaw.
flow(ilk)The flow(ilk) function will calculate the cash price for a given ilk (fix) and adjusts the fix in the case of deficit/surplus. At this point in the mechanism, we have computed the final price for each collateral type and Dai holders can now turn their Dai into collateral. Each unit of Dai can claim a fixed basket of collateral. Dai holders must first pack some Dai into a bag. Once packed, Dai cannot be unpacked and is not transferable. More Dai can be added to a bag later.
pack(wad)The pack(wad) will place Dai into a bag in preparation for cash, which dispenses collateral to bag holders. The bigger the bag, the more collateral can be released.
cash(ilk, wad)Lastly, we use cash(ilk, wad) to exchange some of the Dai from your bag for gems from a specific ilk. Note that the number of gems will be limited by how much packed Dai you have (how big your bag is).
We expect Keepers to buy up Dai from smallholders in order to claim collateral.
This is because a majority of Dai holders are uncertain on how to do perform specific actions during the End process. Due to this fact, we depend on third parties to buy up post-cage Dai to use for reclaiming large portions of Dai. Overall, there will be large amounts of Dai leftover in the system.
cashAt the end of the Global Settlement process, users will get a share of each collateral type. This will require them to call cash through each ilk in the system to completely cash out their Dai.
Example: Users will need to call cash(ilk, wad) to redeem the proportional amount of the specified collateral that corresponds to the amount of Dai that was pack’ ed, where the pack function is used to aid with the redeeming of the different collaterals in different transactions. For example, let’s say you have 1000 Dai. You first pack for the respective collateral types (ilks), then for each cash call, you will redeem what the 1000 Dai represents from the total Dai supply. In return, you will get the same proportion of that same collateral that was locked for all Dai holders. Therefore, the best approach a Dai holder can take is to cash every collateral type (ilk).
In order to prevent a DOS attack, whatever entity calls the thaw function should ensure that Vow.heal() is called within the same transaction.
Example: An attacker can send small amounts of Dai in the vat to the vow. This would prevent thaw from being called and thus, End from progressing. To prevent this, we would call heal to clear out that excess Dai and proceed with thaw.
It is important to set the correct wait period. If you set an incorrect wait/cooldown period (if this is set early on) then auctions are later extended and this is not reset.
It is important to note that the main problem to point out here is that if the wait allows thaw to be called too early, all the Flip auctions may not have completed and the system may have an incorrect accounting of total debt.
The Cooldown period's purpose is so that auctions can be skipped and skim applies to all Vaults (not just the undercollateralized ones).
Once the time period between global settlement and the cool-down period has passed, Dai holders are exposed to the ability to redeem their Dai for collateral.
Therefore the wait
Since End will read the Collateral price from the pip, this can result in the collateral price being only as accurate as the last recorded price. If pip returns a bad price due to oracles getting hacked, the End will be affected.
For example: Calling Global Settlement because an oracle is getting attacked, we must make sure the oracles attack won’t affect the Global Settlement price because End reads the price off of the pip (for reference, this occurs on of end.sol).
If a bad price is queued up in the OSM, we need to make sure to fix the tag before the price is called on Global Settlement.
Example Scenario: If a bad price goes through the median, it takes approximately 30 min for the OSM, and then the Global Settlement process takes over an hour to work. Therefore, by the time it triggers, you will have a bad price in the pip and this will cause the system to fail.
Saving this from happening depends on how quickly you react when it comes to an oracles attack as well as overall governance decisions.
An Oracle attack can be caused by two main events:
Low prices, which makes liquidations easy.
During Global Settlement, setting fake low prices would allow Dai holders to get too much collateral for their Dai, making this attack profitable.
High prices, which helps with buying a lot of Dai.
End.wait when set to maximum can result in it not being possible to call thaw and therefore resulting in the Shutdown not being able to proceed.
End.wait, when set to the minimum, can result in thaw being called before all auctions have finished, resulting in debt being calculated incorrectly and ultimately setting a wrong collateral price.
How to prepare for ES as a partner
Dai no-race condition - Where every Dai holder will be able to redeem the same quantity of each type of collateral, regardless of when they interact with the contract. This is the most important property, as it ensures fairness for all Dai holders.
Near-immediate Dai redemption - where all Dai can be redeemed for collateral immediately after cage.
Near-immediate Vault redemption - Where all free collateral can be retrieved immediately after cage .
No off-chain calculations - where the system does not require the cage authority to supply any off-chain calculated values. For example, it can rely entirely on the last OSM price feed values.
Maker's current implementation favors Vaults owners in all cases by allowing them to free their entire amount of excess collateral. Thus, in the low likelihood event that Vaults become undercollateralized, the Dai holders receive a "haircut" to their claim on collateral. In other words, Dai holders’ claim may be less than a dollar’s worth of collateral.
Immediate Vault redemption - After ES is initiated, Vault owners are allowed to free their collateral immediately, provided that they execute all contract calls atomically.
No off-chain calculations - The system does not require the cage authority to supply any off-chain calculated values (e.g. it can rely entirely on the last OSM feed prices).
Vow Buffer Assistance - After ES is initiated, any surplus (and bad debt) in the buffer acts as a reward (and penalty) distributed pro-rata to all Dai Holders. e.g. if 10% of total system debt is in the form of net surplus in the Vow, then Dai holders receive 10% more collateral.
It’s important to note that auction cancellation is not an immediate process as ecosystem participants must call skip for flip auctions or call yank directly for flap and flop auctions. If no one calls these functions, the auctions will not be canceled.
dentlotdealskip(ilk, id)tenddentwaitskipAn additional thing to note is that if any ilks are undercollateralized, Dai holders will end up taking a bit of a cut as a result. This is because other ilks will not be used to "cover for" an underwater collateral type.
Vault (Skim/End) Keeper - is a tool to skim underwater Vaults if not all undercollateralized Vaults are accounted for. This Keeper could be used by Maker Stakeholders such as large Dai holders/custodians, MKR governors, Redemption keepers and more.
When paired with a subsequent Global Settlement, this could be used to steal a lot / all of the collateral as that Dai would then be used to cash out.
Example: If a user is able to push up the price of a collateral type, it would allow them to mint a larger amount of Dai, resulting in a larger share of the Dai pool. Thus, they could claim a larger proportional share of the collateral whether it was of one type or a slice of all types. They could then readjust the manipulated prices before that collateral slice was fixed in the End.
End.cage is called, all Dai holders are left holding an unstable asset in place of their desired stable asset. This could result in a market price crash across all collateral due to liquidations & sell-offs.Catastrophic Scenario: End.vat / End.vow / End.cat / End.spot - when set to attacker (address: set to attacker-controlled address), can cause shutdown to fail. This is unfixable. For this scenario to occur, the malicious entity (governance or otherwise) would need to be auth'ed on the End.
The Maker Protocol, which powers Multi-Collateral Dai (Dai), backs and stabilizes the value of Dai to a Target Price of 1 US Dollar, translating to a 1:1 US Dollar soft peg. The stabilization mechanism is handled through an autonomous system of smart contracts, a dynamic combination of Vaults, and appropriately incentivized external actors, such as Keepers.
Keepers play a critical role in maintaining the health of the system and Dai stability. In March 2020, the Maker Foundation underlined the need for a more developed Keeper ecosystem. An increase in Keeper participation would ultimately improve the health and function of the Maker Protocol. For more information on how to get a Keeper up and running, see this guide.
The Maker Protocol has an Emergency Shutdown (ES) procedure that can be triggered as a last resort to protect the system and its users against a serious threat or to facilitate a Protocol upgrade.
Emergency Shutdown is intended to be triggered in the case of a system upgrade or serious emergencies, such as long-term market irrationality, a hack, or a security breach. When triggered, ES stops and shuts down the Maker Protocol while ensuring that all users, both Dai holders, and Vault users, receive the net value of assets they are entitled to under the Protocol’s smart contract logic. However, the value of Collateral that Dai holders can redeem may vary, depending on the system surplus or deficit at the time of ES. It is, therefore, possible that Dai holders will receive less or more than 1 USD worth of Collateral for 1 Dai.
The process of initiating ES is decentralized and controlled by MKR voters, who can trigger it by depositing MKR into the, a contract with the ability to call or by an Executive Vote. In the case of the ESM method, 50,000 MKR must be deposited into the ESM to trigger ES. Additionally, once users deposit MKR into the ESM, it is immediately burned. Whether through the ESM or Executive Vote method, when Cage is called, it must alter the behavior of almost every component of the system, as well as perform under a variety of possible undercollateralization scenarios.
Dai no-race condition: Every Dai holder will be able to redeem the same relative quantity of collateral proportional to their Dai holdings, regardless of when they interact with the contract.
Vault Parity: Vault Owners are prioritized, allowing them to withdraw their excess Collateral before Dai holders are able to access Collateral.
At the time of ES, individual Vaults, entire collateral types, or the Maker Protocol can be undercollateralized, which is when the value of debt exceeds the value of the Collateral ("negative equity"). Thus, the value of Collateral that Dai holders can redeem may vary, depending on the system surplus or deficit at the time of ES. It is, therefore, possible that Dai holders will receive less or more than 1 USD worth of Collateral for 1 Dai.
Vault owners can retrieve excess Collateral from their Vaults immediately after the initialization of ES. They can do this via Vault frontends, such as , that have ES support implemented, or via command-line tools.
Dai holders can, after a waiting period (for processing) determined by MKR voters, barter their Dai for a relative pro-rata share of all types of Collateral in the system. The amount of Collateral that can be claimed during this period is determined by the Maker Oracles at the time ES is triggered. It's important to note that Dai holders will always receive the same relative pro-rata amount of Collateral from the system, whether their claims are among the first or last to be processed. The Maker Foundation will initially offer a web page for this purpose to make the process easier for Dai holders.
The prioritization of Vault Owners over Dai Holders during ES can be broken down into three main points:
Overcollateralized Vaults do not subsidize the Maker Protocol for undercollateralized Vaults during the current operation of the system, so it's consistent for ES to have the same behavior. The main difference is that a potential haircut is transferred from MKR holders to DAI holders, as no assumptions can be made about the value of MKR after a shutdown.
Giving priority to Vault owners to recover their excess Collateral (if their Vault is not undercollateralized) incentivizes them to maintain overcollateralization. This is important because the incentive remains even if an ES seems likely, which ultimately makes the Protocol more resilient.
Stability fees accrued pre-ES are not waived by ES. Vault owners may accept higher fees if they know they are protected from the collateralization levels of others, potentially resulting in a higher surplus during ES scenarios as well as allowing for a higher DSR during normal operation.
There is a time delay in the Emergency Shutdown that is determined by governance. The delay must expire before any exchange of Dai for Collateral can take place. The general guidance is that the delay should be long enough to ensure all auctions either finish or get skipped; but, there is no guarantee of this in the code. Importantly, anyone can cancel a collateral (Flip) auction at any time, whereas Surplus (Flap) and Debt (Flop) auctions are frozen by the initial calling of Cage. Both Flap and Flop auctions can be called to return the bids to the last bidder.
Note also that auction cancellation is not an immediate process, as ecosystem participants must cancel all ongoing collateral auctions to appropriate the Collateral and return it to the collateral pool. This allows for faster processing of the auctions at the expense of more processing calls. As for the surplus and debt auctions, they must also be called. If no one calls these functions, the auctions will not be canceled.
Emergency Shutdown may take two main forms. For one, ES may be triggered, and the system is terminated without a future plan for redeployment. This allows users to claim excess Collateral or claim Collateral from their Dai.
On the other hand, Emergency Shutdown may be initiated with a Redeployment Scenario. This situation may arise when the system has been triggered into a shutdown event. Still, MKR token holders, or a third party, have decided to redeploy the system with necessary changes to rerun the system. This will allow users to open new Vaults and have a new Dai token while claiming Collateral from the old system.
During an Emergency Shutdown, each of the various Maker Ecosystem Stakeholders should act accordingly:
If your wallet has the viable interface to claim Collateral or migrate your Dai, or it has a Dapp browser built into it, you may use the to claim Collateral and/or migrate. If your wallet does not support the above functionality, you must transfer your Dai to a new wallet that enables the functionality before proceeding to use the .
If you use to manage your Vault, proceed to the and follow the outlined emergency redemption process.
If you are a user of a third-party interface, such as or , verify that they have Emergency Shutdown Interfaces built-in before proceeding. If so, use their interface to claim the excess Collateral or migrate to a newly deployed system. If the third-party provider does not have the redemption process built-in, transfer to the if possible.
MKR holders may vote on polls and executive votes as it relates to the Emergency Shutdown triggering process. This is done in the Emergency Shutdown Module (ESM) frontend or directly through the . Additionally, MKR holders may also vote as it relates to a future redeployment of the Maker Protocol on the .
In the case of Emergency Shutdown, service providers may follow the actions recommended below.
Recommended Procedure
Alert users to the current situation and provide guidance on the right action(s) to take. Depending on the ES scenario, Shutdown, or redeployment, advise them to act accordingly.
Give users options to withdraw their Dai/MKR from the exchange, or inform them that the exchange/wallet will handle the Emergency Shutdown process on their behalf.
Scenario: Shutdown
Choose one of the following options:
Option 1: Let users withdraw Dai and MKR from the platform, and then guide them to the for the redemption process.
Option 2: Claim Dai equivalent in Collateral on behalf of users using the .
Scenario: Redeployment
Migrate Dai holdings to new Dai token on behalf of users using the .
Alternatively, carry out-migration by interacting directly with the migration contracts using CLI tools. See .
If applicable, migrate MKR token holdings on behalf of users using the
In case of Emergency Shutdown, non-custodial wallet providers should alert your user base about ES and provide public links for more information. You may follow the recommended procedures listed below in the case of Emergency Shutdown.
Scenario: Shutdown
Redirect users to the to claim their Dai equivalent in Collateral, or create an interface to handle the process locally.
Scenario: Redeployment
As a decentralized exchange, you can inform users with a banner about the current status of the Maker Protocol and direct them toward relevant communication channels to find out more. You may choose one of the two following options to allow your users to carry out the ES redemption process:
Direct them to the , where they can start the claiming process for their Dai.
Build an interface to handle the ES process on your platform, inform your users, and have them act accordingly.
Scenario: Shutdown
Inform users to claim equivalent value of Dai in Collateral on the or create an interface to handle the process locally.
Scenario: Redeployment
As a dapp browser, please make sure to alert your user base about ES and provide links to more information (e.g., or). In case of either an emergency system shutdown or system redeployment after ES is triggered, redirect your users to the to claim their Collateral.
As a Vault integrator, it is very important that you integrate with Maker Protocol contracts (more specifically, end.sol). This crucial integration will allow you to quickly create a reactive logic that will handle the post-ES process for your users. If you are a custodial service, such as a centralized exchange, please inform your users in advance about your plan on handling the Emergency Shutdown event. You may follow the recommended procedures listed below in the case of Emergency Shutdown.
Recommended Procedure
Scenario: Shutdown
Claim users’ funds through the or by direct interaction with the migration contracts, and make them available in their accounts.
Scenario: Redeployment
As a non-custodial Vault integrator, please make sure to integrate with the Maker Protocol contracts (end.sol). This allows you to be notified at the exact moment the Shutdown has been triggered. Otherwise, it is suggested that you inform your users on how they can free Collateral in Vaults. This can either be done in the non-custodial Vault integrator’s UI or you can direct them to if the users need to migrate their Vault. If you do decide to use your own services, you will need a UI that allows users to withdraw their Vaults from a proxy contract so it shows up on the . Direct your users there. Alternatively, you may create an interface that will help users migrate their Dai in case of a new redeployment, or allow users to claim their Collateral in case of an only shutdown scenario.
Dapps are suggested to integrate with Maker Protocol contracts (end.sol), which effectively provides a notification system that shows if Emergency Shutdown has been triggered. In terms of preparation, when ES has been triggered, have the following ready for your users:
A UI interface that alerts and informs users about the event.
If your Dapp uses a proxy, you will need to enable users to exit from the proxy in order to use the migration app/portal.
Provide official communication channels for more information as well as a link to the for Dai and Vault redemption.
If you control access to the smart contracts backing your Dapp, it is suggested to allow your users to retrieve Dai or access their Vaults from their personal wallet as well as direct them to the for the ES redemption process. Alternatively, you may claim Dai collateral or claim excess Collateral from Vaults on behalf of your users at the, and proceed to distribute it to your users, ensuring that they successfully retrieve it.
If you don’t control the smart contracts backing your Dapp directly, then you may direct your users to the for Dai and Vault redemption. Alternatively, you may create an interface that allows your users to claim a Dai equivalent in Collateral, or claim excess Collateral from Vaults in case of a system shutdown. Additionally, if there's a redeployment of the system, migrate Dai to the new redeployed system and/or claim excess Collateral from Vaults.
As a market maker during ES, you may provide liquidity in the market so that Dai holders can exchange their Dai for other assets. After there is no market to cover, you can act as a Dai holder and start migrating Dai to new Dai in case of system redeployment or claim equivalent Dai collateral in case of a system-wide shutdown.
This is an involved and stateful process that involves the following 9 steps.
Locking the prices down for each collateral type is done by freezing the following user entry points:
Vault creation
Surplus/Debt Auctions
Dai Savings Rate (DSR)
Governance entry points
Next, the system will stop all of the current debt/surplus auctions, allowing individual auctions to be canceled by calling a function that moves the first phase of a collateral auction to the End. This process is completed by retrieving the Collateral and repaying Dai to the highest bidder of the respective auction contract. One reason these auctions are frozen and canceled is that the Emergency Shutdown process is designed to pass along the system surplus or system debt to Dai holders. In general, there are no guarantees regarding the value of MKR during a Shutdown and the mechanisms that typically rely on MKR's market value cannot be relied upon, ultimately resulting in there being no reason to keep running the auctions that impact MKR supply. More specifically, the reasons debt and surplus auctions get canceled are as follows:
Surplus auctions no longer serve their purpose. This is because, after a shutdown, the surplus is designed to be allocated to Dai holders. Thus, canceling surplus auctions during Shutdown allows the system to return the surplus Dai back to the Settlement engines balance and ultimately back to Dai holders.
Debt auctions also stop serving their purpose. This is because the bad debt is passed as a haircut (lower-than-market-value placed on an asset being used as Collateral in a Vault) back to Dai holders if there is no other system surplus available.
As for collateral auctions, they are not immediately canceled (but can be canceled by any user) because they are still tied to the valuable Collateral in the system. Collateral auctions continue to run, and Keepers can continue to bid on them. If there are no bidders, the live auctions can also be canceled.
Despite the fact that auctions can continue to run, this does not guarantee that all of the remaining Vaults are overcollateralized. There is also nothing to prevent the undercollateralized and unbitten Vaults from existing at the moment cage is called.
During this time, the function that adds the debt (total Dai wanted from the auction) cannot be called, as the function requires the system to be running normally, disabling liquidations after Shutdown. Additionally, after the End begins, all Vaults must be settled at the tagged price, and then the remaining Collateral from a settled Vault must be removed.
Overall, this results in collateral auctions being able to continue during Shutdown or by having them reversed by a user by canceling live auctions (similar logic to the surplus auctions). If an auction is canceled, the bids are returned to bidders, and Collateral is returned to the original Vault (with the liquidation penalty applied in the form of increased debt).
Notes regarding collateral auctions:
End moves the first phase of collateral auctions to the End by retrieving the Collateral and repaying Dai to the highest bidder.
The second phase of auctions allows bids to be made, while decreasing the quantity up for auction. During this phase, completed auctions are settled as they have already raised the necessary Dai and are already in the process of returning the Collateral to the original Vault holder.
Other Notes:
MKR could still have value if the current MKR token is tied to another deployment of the system. Note that the system makes no assumptions about the economic value of MKR post-Shutdown.
It is important to note that on-auction debt and surplus are canceled, and balances are transferred to the End contract. The last step in this process is to begin the cooldown period.
This process is completed by setting the system shutdown price for each collateral type. The final prices are determined by reading the price feeds from the Maker Oracles. This is required, as the system must first process the system state before it is possible to calculate the final Dai/collateral price. In particular, we need to determine two things:
(a) The shortfall per collateral type considering undercollateralized Vaults.
(b) The total quantity of Dai issued (total debt), which is the outstanding Dai supply after including the system surplus/deficit.
Firstly, this is determined (a) by processing all Vaults with a function that cancels owed Dai from the Vault (described below). Next, (b) unfolds as described below.
Next, the system will allow for the canceling of all the owed Dai from the Vault(s) in the system. Any excess collateral remains within the Vault(s) for the owner(s) to claim. Then, the backing collateral is taken.
Next, the debt is determined (b) by processing the ongoing Dai generation operations of the auctions. Processing the ongoing Dai generation ensures that the auctions will not generate any further Dai income. This guarantees that ongoing auctions will not change the total debt of the system, which also includes the two-way auction (collateral auction) model not allowing for any more Dai to be generated. Due to this, the Dai generation comes from the first phase of collateral auctions. Thus, if everything is in the second phase of an auction (bidding on the decreasing quantity up for auction), we know the generation is over. Generation is over when all auctions are in the reverse/second phase. In addition to ensuring that the auctions will not generate any further Dai, the Dai Savings Rate (DSR) must also be shut off during the End so that the total debt does not change.
Example:
In terms of user scenarios, the process begins with users bidding more and more Dai until the debt is covered. Next, they start offering less and less Collateral.
The auctions that are in the second phase (reverse auctions) no longer affect any more of the total debt, as the Dai was already recovered. Lastly, for the auctions in the first phase, they can be canceled, and the Collateral and debt returned to the Vault.
One of two methods can ensure that Collateral and debt are returned to the Vault:
The processing cooldown duration (length of the debt queue); or
By canceling live auctions.
Set the cooldown period. The duration of the cooldown period only needs to be long enough to cancel owed Dai from the undercollateralized Vaults, and cancel the live first phase auctions. This means that it can, in fact, be quite short (i.e., 5 minutes). However, due to the possibility of scenarios such as network congestion occurring, it may be set longer.
Canceling a live auction will cancel all ongoing auctions and seize the Collateral. This allows for faster processing of the auctions at the expense of more processing calls. This option allows Dai holders to retrieve their Collateral much faster. The next procedure is to cancel each of the individual Collateral (Flip) auctions in the forward first phase auctions and retrieve all of the Collateral and return Dai to the bidder. After this occurs, the second phase—reverse auctions—can continue as they usually would, by setting the cooldown period or canceling the live auctions.
Note that both of these options are available in this implementation, with the canceling of the live auctions being enabled on a per-auction basis. When a Vault has been processed and has no debt remaining, the remaining Collateral can be removed.
Next, the system will remove the Collateral from the Vault. After the Vaults have been settled at the set final price and the owed Dai from the Vault has been canceled, the Vault owner can call this process as needed. It will remove all of the Collateral remaining after step 3—basically, all of the Collateral that was not backing the debt. If the user did not have debt in a Vault at the time of the End, he can bypass steps 3 and 4 and can proceed directly to this step to free his Collateral.
After the processing period has elapsed, the calculation of the final price for each collateral type is possible using the thaw function. The assumption is that all under-collateralized Vaults are processed, and all auctions have unwound. The purpose of this function is to stabilize the total outstanding supply of Dai. Note that it may also require extra Vault processing to cover the system's surplus. Checking that the amount of Dai surplus in the core Vault engine is 0 is a requirement during this phase. This requirement is what guarantees that the system surplus has been taken into account. Furthermore, this means that before you can stabilize the total outstanding supply of Dai, you must cancel the owed Dai from as many Vaults as needed to cancel any Dai surplus in the Vow. Canceling Dai surplus is done by canceling out the surplus and debt in the system's balance sheet before you can stabilize the total outstanding supply of Dai.
In this step, the calculation of the exchange price for a given collateral type is determined, as well as the potential adjustment of that final exchange price in the case of deficit/surplus. At this point in the mechanism, the final price for each collateral type has been computed; Dai holders can now turn their Dai into Collateral. Each unit of Dai can claim a fixed basket of Collateral. Dai holders must first lock their Dai so that they can be ready to exchange it for Collateral. Once the Dai is locked, it cannot be unlocked and is not transferable. More Dai can be locked later, as well.
This step is when Collateral is dispensed to the Dai holders who have already locked their Dai in to be exchanged. The larger the amount of Dai locked in, the more Collateral can be released to the Dai holders.
Lastly, the system will allow the exchange of some of the Dai that has been locked for specific collateral types. Note that the number of collateral tokens will be limited by how much locked Dai users have.
. Support channels include but are not limited to:
#general
#dev
Immediate Vault redemption: After ES is initiated, Vault owners are allowed to free their Collateral immediately, provided that they execute all contract calls atomically.
No off-chain calculations: The system does not require the cage authority to supply any off-chain calculated values (i.e., it can rely entirely on the last OSM feed prices).
Vow Buffer Assistance: After ES is initiated, any surplus or bad debt in the buffer acts as a reward or penalty distributed pro-rata to all Dai holders. For example, if 10% of total system debt is in the form of net surplus in the Vow, then Dai holders receive 10% more Collateral.
Choose one of the following:
Distribute Collateral to users.
Get withdrawal address from users for collateral types not supported on the exchange.
Keep the Collateral (to sell off, for example) and update user internal fiat balances to reflect their entitled amount.
Inform users to migrate their Dai on the migration portal, or create an internal interface to handle the process locally.
Add featured support for new token(s).
Inform users to migrate their Dai to the new Dai (and MKR if applicable) on the migration portal, or create an interface to handle the process on your platform.
Add new token(s) to the exchange.
Migrate users’ funds to a new redeployed system using the migration portal or by interacting directly with the migration contracts.
#help
The ESM is the trigger system for the shutdown of the Maker Protocol
Contract Name: esm.sol
Type/Category: Emergency Shutdown Module
The Emergency Shutdown Module (ESM) is a contract with the ability to call End.cage() to trigger the Shutdown of the Maker Protocol.
Key Functionalities (as defined in the smart contract)
rely - Grant an address admin powers
deny - Revoke admin powers from an address
file - Allow admin to update threshold min and address of end
cage - Permanently disable the shutdown module
fire - Trigger shutdown by calling End.cage
denyProxy - Following the wards rely/deny pattern, calls deny on a given contract
join - Deposit MKR to the shutdown module
burn - Burn any MKR deposited into the shutdown module
Other
gem - MKR Token contract [address]
wards(admin: address) - Whether an address has admin powers [address: uint]
sum(usr: address) - MKR join balance by user [address: uint]
Sum - Total MKR deposited [uint]
min - Minimum MKR amount required for fire and denyProxy [uint]
end - The End contract [address]
live - Whether the contract is live (not caged) [uint]
MKR holders that wish to trigger Shutdown must join MKR into the ESM. When the ESM's internal Sum variable is equal to or greater than the minimum threshold (min), the ESM's fire() and denyProxy() methods may be called by anyone. The fire() method, in turn, calls End.cage(), which starts the Shutdown process.
The ESM is intended to be used in a few potential scenarios:
To mitigate malicious governance
To prevent the exploitation of a critical bug (for example one that allows collateral to be stolen)
In the case of a malicious governance attack, the joiners will have no expectation of recovering their funds (as that would require a malicious majority to pass the required vote), and their only option is to set up an alternative fork in which the majority's funds are slashed and their funds are restored.
In other cases, the remaining MKR holders may choose to refund the ESM joiners by minting new tokens.
Note: Governance can disarm the ESM by calling cage() (this is distinct from End.cage()).
It is important for users to keep in mind that joining MKR into the ESM is irreversible—they lose it forever, regardless of whether they successfully trigger Shutdown. While it is possible that the remaining MKR holders may vote to mint new tokens for those that lose them triggering the ESM, there is no guarantee of this.
An entity wishing to trigger the ESM but possessing insufficient MKR to do so independently must proceed with caution. The entity could simply send MKR to the ESM to signal its desire and hope others join in; this, however, is poor strategy. Governance, whether honest or malicious, will see this, and likely move to de-authorize the ESM before the tipping point can be reached. It is clear why malicious governance would do so, but honest governance might act in a similar fashion—e.g. to prevent the system from being shut down by trolls or simply to maintain a constant threshold for ESM activation. (Honest governance, or even deceptive malicious governance, would be expected to then replace the ESM.) If governance succeeds in this, the entity has simply lost MKR without accomplishing anything.
If an entity with insufficient MKR wishes to trigger the ESM, it is better off first coordinating with others either off-chain or ideally via a trustless smart contract.. If a smart contract is used, it would be best if it employed zero-knowledge cryptography and other privacy-preserving techniques (such as transaction relayers) to obscure information such as the current amount of MKR committed and the addresses of those in support.
If an entity thinks others will join in before governance can react (e.g. if the delay for governance actions is very long), it is still possible that directly sending insufficient MKR to the ESM may work, but it carries a high degree of risk. Governance could even collude with miners to prevent cage calls, etc if they suspect an ESM triggering is being organized and wish to prevent it.
The ESM itself does not have an isolated failure mode, but if the other parts of the system do not have proper authorization configurations (e.g. the End contract does not authorize the ESM to call cage()), then the ESM's fire() method may be unable to trigger the Shutdown process even if sufficient MKR has been committed to the contract.
