Emergency Shutdown

Emergency Shutdown is the last-resort safety mechanism built into Sky Protocol (formerly MakerDAO) that allows the entire system to be gracefully wound down in the event of a catastrophic threat. When triggered, Emergency Shutdown freezes the protocol, locks collateral prices at their last known values, settles all outstanding debt positions, and enables holders of USDS (formerly DAI) to redeem their stablecoins for a proportional share of the underlying collateral ^[1]. The mechanism is designed to protect all participants in the ecosystem, from vault owners to stablecoin holders, ensuring that each receives the net value of assets to which they are entitled.

The system is composed of two primary smart contracts: the Emergency Shutdown Module (ESM), which acts as the trigger mechanism, and the End module, which orchestrates the multi-step settlement process ^[2]. Together, these contracts implement a decentralized "kill switch" that can be activated by a minority of governance token holders without requiring approval from any centralized authority. The ESM operates by collecting governance tokens (originally MKR, now SKY) that are permanently burned upon deposit. Once deposits exceed a configurable threshold, anyone can call the fire() function to initiate shutdown ^[3].

Emergency Shutdown has never been triggered on Ethereum mainnet since the protocol's launch in November 2019. The closest the system came to activation was during the Black Thursday crisis of March 2020, when a 43% collapse in Ethereum's price created millions of dollars in bad debt and forced governance participants to weigh the costs of shutting down the entire protocol ^[4]. The decision to avoid shutdown in favor of debt auctions and parameter changes has shaped the protocol's approach to crisis management ever since. Despite never being used in production, the mechanism remains a foundational element of the protocol's security architecture, and its parameters have been adjusted multiple times through governance votes to reflect evolving threat models.

History and Origins

The concept of Emergency Shutdown predates the current Multi-Collateral system. In the original Single-Collateral Dai (SCD) system launched in December 2017, a simpler global settlement mechanism existed that could freeze the system and allow SAI holders to claim ETH collateral ^[5]. This early design established the principle that a decentralized lending protocol must include a deterministic, trustless method for orderly unwinding in catastrophic scenarios. When the Multi-Collateral Dai (MCD) system launched on November 18, 2019, Emergency Shutdown was reimplemented as a more sophisticated two-contract architecture to handle the complexity of multiple collateral types and interconnected protocol modules ^[2].

The design philosophy behind Emergency Shutdown reflects a deliberate trade-off between protocol permanence and user protection. Rather than allowing the system to operate indefinitely under potentially compromised conditions, the mechanism ensures that governance token holders always retain the ability to halt operations and return collateral to its rightful owners. This approach acknowledges that smart contract systems, despite rigorous auditing, may contain undiscovered vulnerabilities that could be exploited by malicious actors.

Black Thursday and the Shutdown Debate

The most significant real-world test of the Emergency Shutdown decision framework occurred during Black Thursday on March 12-13, 2020. As global markets crashed due to the emerging COVID-19 pandemic, Ethereum's price fell from $194 to $111, a 43% decline in a single day ^[4]. The resulting cascade of liquidations overwhelmed the protocol's auction system. Network congestion drove gas prices to unprecedented levels, preventing keeper bots from bidding on liquidation auctions. Sophisticated actors exploited this failure by winning auctions with zero or near-zero DAI bids, resulting in approximately $8.32 million in collateral being liquidated for essentially nothing and creating $5.67 million in protocol bad debt ^[6].

During an emergency governance call held that day, participants seriously debated triggering Emergency Shutdown. Rich Brown, the MakerDAO Foundation's head of community, described the situation as "a brave new world" ^[4]. However, several factors weighed against activation. An Emergency Shutdown while the protocol carried bad debt would mean DAI holders would receive less than $1 worth of collateral per DAI, effectively imposing losses on stablecoin holders rather than governance token holders. As one stakeholder argued, "an emergency shutdown would cause DAI holders to take a haircut, whereas the social contract of MakerDAO is that MKR tokens take a haircut in the event of system failure" ^[4].

The community ultimately chose an alternative path: conducting debt auctions where freshly minted MKR tokens were sold for DAI, diluting existing MKR holders to recapitalize the system ^[6]. This decision preserved the protocol's operation and maintained the principle that governance token holders bear the cost of system failures. The event also catalyzed significant improvements, including the addition of USDC as emergency collateral, parameter adjustments to auction mechanics, and eventually the complete redesign of the liquidation system in Liquidations 2.0.

Evolution of the Threshold

The ESM trigger threshold has been adjusted multiple times through governance votes to balance accessibility against attack resistance. At MCD launch in November 2019, the threshold was set at 50,000 MKR ^[3]. This was raised to 75,000 MKR following a governance signal request in late 2021 that argued the original threshold was too low relative to the protocol's growing total value locked ^[7]. On February 4, 2022, an executive vote raised the threshold further from 75,000 MKR to 100,000 MKR ^[8]. A subsequent increase to 150,000 MKR occurred as the protocol matured, and on July 25, 2024, the threshold was raised again from 150,000 MKR to 300,000 MKR as part of the LITE-PSM-USDC-A Phase 1 setup executive proposal ^[9]. Each increase reflected a growing recognition that as the protocol secured more value, the cost of triggering shutdown needed to scale proportionally to deter potential governance attacks while still remaining achievable by a committed minority of token holders acting in good faith.

Technical Architecture

The Emergency Shutdown system consists of three primary smart contracts that work in concert: the Emergency Shutdown Module (ESM), the End module, and the Cure module. Each serves a distinct function in the trigger, settlement, and debt accounting processes. The architecture is designed to be fully deterministic, requiring no off-chain computation or trusted intermediaries to execute the complete shutdown sequence ^[2]^[10].

The contracts interact with nearly every other component of the protocol. When shutdown is triggered, the ESM calls into the End module, which in turn interacts with the Vat (core accounting), Vow (system surplus and debt), Cat/Dog (liquidation engines), Spot (price feeds), Pot (savings rate), and individual collateral adapters. This deep integration means that any change to the protocol's architecture must carefully consider its implications for Emergency Shutdown behavior.

Emergency Shutdown Module (ESM)

The ESM contract (MCD_ESM) serves as the trigger mechanism for Emergency Shutdown. Deployed on Ethereum mainnet, it implements a straightforward but irreversible collection mechanism ^[3]. The contract exposes several key functions:

join(uint256 wad) — Allows any governance token holder to deposit tokens into the ESM. Deposited tokens are immediately burned and cannot be recovered under any circumstances. The contract tracks the cumulative total in an internal Sum variable ^[3].
fire() — Can be called by anyone once Sum equals or exceeds the minimum threshold (min). This function calls End.cage() to initiate the shutdown process ^[3].
denyProxy() — Removes governance authority from the pause proxy contract, preventing any further governance actions from taking effect. This is critical for neutralizing a malicious governance attack ^[11].
Sum() — Returns the total amount of governance tokens deposited so far.
min() — Returns the current threshold required to trigger shutdown.
fired() — Returns a boolean indicating whether Emergency Shutdown has been triggered.

The ESM's parameters are set at deployment and cannot be modified without deploying a new ESM contract and updating the protocol's authorization mappings. This immutability prevents governance from unilaterally disarming the shutdown mechanism, though governance can call cage() on the ESM itself (distinct from End.cage()) to permanently disable it ^[3]. As of January 2026, the ESM threshold stands at 300,000 MKR (or the equivalent in SKY tokens following the governance token migration) ^[9].

End Module

The End module (MCD_END) is the orchestration contract that executes the multi-phase settlement process after cage() is called ^[10]. It coordinates with virtually every other contract in the system to freeze operations, establish final collateral prices, process vault positions, and enable stablecoin redemption. The End module maintains several critical state variables:

live — A flag that equals 1 during normal operation and is set to 0 when cage() is called, signaling shutdown to all connected contracts ^[10].
when — The timestamp at which shutdown was triggered, used to calculate the processing period.
wait — The configured duration of the processing period (approximately 73 hours) during which vault positions are settled before stablecoin holders can redeem ^[1].
tag — A mapping that stores the final price for each collateral type at the moment of shutdown.
gap — A mapping that tracks the collateral shortfall per collateral type after processing undercollateralized vaults.
debt — The total outstanding stablecoin supply after accounting for system surplus and deficit.

The End module was upgraded alongside the Liquidations 2.0 rollout to handle the new Dutch auction (Clipper) contracts in addition to the legacy English auction (Flipper) contracts ^[12].

Cure Module (DssCure)

The Cure module (MCD_CURE) is a later addition to the shutdown architecture, introduced to address accounting challenges created by cross-chain extensions such as the DSS-Wormhole (Teleport) system ^[13]. When DAI or USDS exists on Layer 2 networks or other chains through bridge mechanisms, the total protocol debt calculation during shutdown must exclude these amounts to prevent double-counting. The Cure module allows designated contracts to report DAI amounts that should be subtracted from the total debt during the settlement process ^[13].

A ChainSecurity audit of the Cure module noted that while the codebase provides a high level of security, there exists a risk that the shutdown process could be blocked if governance pauses the Cure contract ^[13]. This finding highlights the inherent tension between governance flexibility and shutdown reliability that pervades the system's design. The introduction of the Cure module required deploying a new End contract, with the existing ESM contract updated to point to the new End implementation.

Shutdown Process

The Emergency Shutdown process follows a deterministic, multi-phase sequence designed to ensure fair and orderly settlement for all protocol participants. The process can be divided into three primary phases: system caging, vault processing, and stablecoin redemption. Each phase involves specific smart contract interactions that must be executed in order, though many individual steps within each phase can be performed by any Ethereum address ^[1]^[10].

The entire process is designed to eliminate race conditions. Every stablecoin holder receives the same proportional claim on collateral regardless of when they interact with the settlement contracts. This guarantee is a fundamental design property that distinguishes Emergency Shutdown from a disorderly bank run, where early actors gain advantages at the expense of later participants.

Phase 1: System Caging

When End.cage() is called, either through the ESM's fire() function or through a direct executive vote, the system enters its shutdown state ^[10]. The cage() function performs several immediate actions:

Sets live to 0 — This flag propagates through the system, causing all user-facing functions that check live == 1 to revert. No new vaults can be opened, no new stablecoins can be generated, and no new collateral can be deposited ^[10].
Freezes the DSR — The Sky Savings Rate accumulator stops, preventing further interest accrual.
Cancels flap and flop auctions — Surplus auctions (flap) and debt auctions (flop) are immediately frozen. Bidders can call yank to retrieve their bid amounts ^[10].
Records the shutdown timestamp — The when variable is set, which determines when the processing period ends and stablecoin redemption begins.

Following the initial cage() call, cage(ilk) must be called for each collateral type individually. This function records the final price (tag) for each collateral type based on the last oracle security module (OSM) feed price ^[10]. Using the last known oracle price rather than a real-time market price ensures deterministic settlement without requiring any off-chain data after shutdown is triggered. The use of OSM prices means the system relies on prices that may be slightly delayed (typically one hour) from true market values, but this trade-off is accepted in favor of manipulation resistance.

Phase 2: Vault Processing

After all collateral types have been tagged with their final prices, the system enters the vault processing phase. This phase determines the collateral shortfall across the system and allows vault owners to retrieve excess collateral ^[10].

The skim(ilk, urn) function is called for each vault (identified by its urn address) to settle it at the tagged price. For each vault, skim calculates the minimum of the vault's debt and its collateral value at the tagged price, then cancels the corresponding amount of debt. If a vault is undercollateralized at the tagged price, its entire collateral is seized to partially cover its debt, contributing to the collateral shortfall (gap) for that collateral type ^[10].

After a vault has been skimmed, if it had excess collateral (i.e., it was overcollateralized), the vault owner can call free(ilk) to withdraw the remaining collateral immediately. This prioritization of vault owners is a deliberate design choice: they can recover their excess collateral without waiting for the full processing period to elapse ^[1].

During this phase, vow.heal() must be called to cancel any system surplus against outstanding debt. The End module requires that all surplus has been healed before the final debt calculation can proceed, ensuring accurate accounting of the total stablecoin supply that needs to be redeemed ^[14].

Collateral auctions initiated before shutdown may continue to run. However, cat.bite (or dog.bark in Liquidations 2.0) cannot be called after shutdown since these functions require live == 1, effectively preventing new liquidations ^[10]. Anyone can cancel ongoing collateral auctions by calling yank, returning collateral to the End module for inclusion in the redemption pool.

Phase 3: Stablecoin Redemption

After the processing period (End.wait, approximately 73 hours) has elapsed, the system transitions to the redemption phase ^[1]. This waiting period exists to allow sufficient time for vault processing, auction conclusion, and debt healing.

The thaw() function is called first, which fixes the total outstanding stablecoin supply (debt) by reading the Vat's total debt counter. This function requires that all surplus has been healed (vat.dai(vow) == 0), ensuring accurate final accounting ^[14]. After thaw, the flow(ilk) function is called for each collateral type to calculate the redemption rate: how much of each collateral type each unit of stablecoin can claim, accounting for any shortfall from undercollateralized vaults.

Stablecoin holders then interact with the system in two steps. First, they call pack(wad) to lock their stablecoins into the End contract. Then, for each collateral type, they call cash(ilk, wad) to redeem the proportional amount of that collateral corresponding to their locked stablecoins ^[10]. If the system is fully collateralized, each stablecoin redeems for exactly one dollar's worth of collateral across all types. If undercollateralized vaults created a shortfall, the redemption rate is reduced proportionally, meaning each stablecoin redeems for slightly less than one dollar.

Cage Keeper

The cage-keeper is an automated bot designed to facilitate the Emergency Shutdown process by calling the necessary End module functions in the correct sequence ^[15]. Since the shutdown process requires numerous individual transactions across multiple phases, the cage-keeper automates the processing of undercollateralized vaults (via skim), the healing of surplus (via vow.heal), and the progression through thaw and flow for each collateral type. The cage-keeper is open source and can be run by any participant, ensuring that the shutdown process can complete even without coordination from the protocol's core contributors.

Emergency Shutdown exists within a broader ecosystem of emergency governance tools designed to protect the protocol from various threat scenarios. While Emergency Shutdown is the most drastic option, effectively terminating the protocol entirely, several complementary mechanisms provide graduated response capabilities for less severe situations ^[16].

The relationship between these tools reflects a defense-in-depth philosophy. Less destructive interventions are preferred when possible, with Emergency Shutdown reserved as the absolute last resort. The hierarchy typically proceeds from targeted parameter changes (via emergency spells), to oracle freezing and auction halting, to full protocol shutdown. Each mechanism has distinct authorization requirements and scope of impact.

Emergency Spells (dss-emergency-spells)

The protocol maintains a repository of pre-deployed emergency spell contracts that allow governance to rapidly respond to incidents without waiting for engineers to craft bespoke solutions ^[16]. These pre-deployed spells can perform targeted interventions such as wiping the debt ceiling for a specific collateral type to prevent further debt generation, halting collateral auctions by setting the breaker level to prevent kick(), redo(), and take() operations, disabling Direct Deposit Modules to stop automated lending, and stopping Oracle Security Module instances to freeze price feeds ^[16]. Emergency spells provide a middle ground between normal governance operations (which are subject to the GSM Pause Delay) and full Emergency Shutdown.

Protego

Protego is a defensive tool designed specifically to counter governance attacks where malicious actors might attempt to schedule harmful executive spells ^[17]. Pre-deployed at 0x5C9c3cb0490938c9234ABddeD37a191576ED8624 on Ethereum mainnet, Protego contains a factory that can permissionlessly create "Emergency Drop Spells" capable of canceling specific scheduled plans in the MCD_PAUSE contract ^[17]. In a scenario where an attacker gains temporary control of governance and schedules multiple malicious spells faster than defenders can respond, the Protego contract itself can be given the governance "hat," enabling any user to permissionlessly cancel any scheduled plan. Protego was added to the protocol's Chainlog in May 2025 as part of ongoing governance security improvements ^[17].

MIP15: Dark Spell Mechanism

MIP15, proposed by Wil Barnes and Charles St. Louis on May 21, 2020, and ratified on September 18, 2020, introduced the concept of "dark spells" for handling critical technical vulnerabilities ^[18]. The mechanism allowed the Smart Contracts Domain Team to deploy fixes for critical exploits without publicly disclosing the vulnerability before the fix was active, addressing the tension between the GSM Pause Delay's time-lock requirement and the urgency of patching security flaws. MIP15's status is now Obsolete, having been superseded by the passage of MIP102c2-SP1 and replaced by the current emergency spells framework and Protego system ^[18].

Governance Security Module (GSM) Relationship

The Governance Security Module imposes a configurable time delay (the Pause Delay) between when an executive vote passes and when its effects are applied to the protocol ^[19]. This delay exists specifically to give token holders time to react to potentially malicious governance proposals. Critically, the GSM Pause Delay does not apply to Emergency Shutdown. The ESM can trigger shutdown immediately, bypassing the time-lock entirely ^[19]. This design ensures that if a governance attack involves scheduling malicious spells through the normal GSM process, defenders can trigger Emergency Shutdown before those spells take effect.

Security Considerations

The Emergency Shutdown mechanism introduces its own set of security considerations and potential attack vectors. While the system is designed to be robust against manipulation, several theoretical and practical concerns have been identified, documented, and in some cases addressed through governance action and contract upgrades.

The fundamental security tension in Emergency Shutdown design is between making the mechanism accessible enough that legitimate defenders can trigger it in a crisis, and making it costly enough that attackers cannot weaponize it. Every parameter adjustment to the ESM threshold reflects an ongoing attempt to balance these competing concerns.

Governance Attack Scenarios

The ESM is explicitly designed to protect against malicious governance attacks where an adversary accumulates sufficient voting power to pass harmful executive proposals. In such a scenario, a minority of honest token holders can deposit their tokens into the ESM to trigger shutdown before the malicious proposal takes effect, since the ESM bypasses the GSM Pause Delay ^[19]. However, this defense has limitations. If the attacker controls sufficient tokens to also raise the ESM threshold or de-authorize the ESM before honest actors can coordinate, the defense mechanism itself becomes compromised.

To mitigate this risk, the ESM includes the denyProxy() function, which removes governance authority from the pause proxy upon shutdown ^[11]. This prevents a malicious governance majority from executing further proposals after shutdown has been triggered. The March 2023 emergency spell expanded the ESM's ability to de-authorize governance across additional contracts including MCD_JOIN_CRVV1ETHSTETH_A, MCD_CROPPER, and CHANGELOG that were previously missing this protection ^[11].

The Permission Revocation Bug

In a postmortem published by the Protocol Engineering Core Unit, it was disclosed that from the MCD launch on November 18, 2019, until April 26, 2021, certain protocol contracts lacked proper authorization for the ESM to de-authorize the governance pause proxy after an Emergency Shutdown ^[20]. This meant that during this period, if Emergency Shutdown had been triggered in response to a governance attack, the attacker could have continued executing malicious proposals against certain contracts despite the shutdown. The bug was resolved by extending the pattern of permissionless de-authorization to the affected contracts. This disclosure highlighted the difficulty of maintaining consistent authorization patterns across a growing number of interconnected smart contracts.

Coordination Challenges

An entity wishing to trigger the ESM but possessing insufficient tokens to reach the threshold independently faces a strategic dilemma ^[3]. Simply depositing tokens into the ESM to signal intent is poor strategy, as governance (whether honest or malicious) will observe the deposits and may move to de-authorize the ESM before the threshold is reached. The recommended approach is to coordinate with other holders either through off-chain communication or via a trustless smart contract that aggregates commitments before any tokens are deposited. This coordination requirement means that in practice, Emergency Shutdown requires both sufficient token holdings and effective social coordination among defenders.

Irreversibility and Economic Cost

All tokens deposited into the ESM are permanently burned, regardless of whether shutdown is successfully triggered ^[3]. This irreversibility serves as a Schelling point deterrent against frivolous activation attempts, but it also means that legitimate defenders bear a significant economic cost. While governance theoretically could vote to mint replacement tokens for ESM participants after a redeployment, there is no contractual guarantee of such compensation. This creates a free-rider problem where individual token holders may be reluctant to sacrifice their holdings, hoping others will bear the cost of triggering shutdown.

Criticism and Limitations

Despite its importance as a safety mechanism, Emergency Shutdown has been subject to several criticisms regarding its design, practicality, and evolving relevance as the protocol has grown in complexity.

One recurring criticism concerns the threshold calibration problem. The threshold must be high enough to prevent malicious or accidental triggering, yet low enough that legitimate defenders can reach it during a crisis when rapid coordination is difficult. As of January 2026, the 300,000 MKR threshold (following the July 2024 increase) represents a substantial economic commitment ^[9]. Critics have argued that at current token valuations, assembling this quantity of tokens requires coordination among major holders and may be impractical during a fast-moving crisis where communication channels themselves could be compromised.

The system's handling of undercollateralized positions during shutdown introduces potential fairness concerns. If Emergency Shutdown is triggered while the protocol carries bad debt (as would have been the case during Black Thursday), stablecoin holders bear the loss through reduced redemption rates rather than receiving full dollar-value redemption ^[4]. This outcome contrasts with normal protocol operations where governance token holders absorb losses through debt auctions, creating an asymmetry in how risk is distributed depending on whether the crisis is resolved through shutdown or through continued operation.

The increasing complexity of the protocol presents ongoing challenges for shutdown reliability. As new modules, collateral types, cross-chain bridges, and Layer 2 deployments are added, each must be correctly integrated with the Emergency Shutdown architecture. The Cure module's introduction to handle cross-chain DAI accounting illustrates this growing complexity ^[13]. Each new integration point represents a potential failure mode if authorization configurations are incorrect, as demonstrated by the permission revocation bug that persisted for over a year after launch ^[20].

Finally, some observers have questioned whether Emergency Shutdown remains conceptually appropriate for a protocol that now manages billions of dollars in assets and serves as critical infrastructure for the broader DeFi ecosystem. The binary nature of the mechanism, either the entire protocol operates or it is permanently shut down, does not accommodate partial failures or targeted interventions well. The development of emergency spells and Protego represents an implicit acknowledgment that more granular response capabilities are needed alongside the all-or-nothing shutdown option ^[16]^[17].

Current State

As of January 2026, Emergency Shutdown has never been triggered on Ethereum mainnet. The mechanism remains deployed and functional as part of Sky Protocol's core security architecture, though its relationship with the broader system has evolved significantly through the Sky rebrand and the Endgame transition ^[9].

The ESM threshold stands at 300,000 MKR following the July 2024 executive vote, the highest level in the protocol's history ^[9]. This increase was made alongside the LITE-PSM-USDC-A deployment and addressed attack vectors identified through the protocol's bug bounty program. The threshold adjustment reflects both the protocol's growing total value locked and improved understanding of governance attack scenarios developed over years of security research and community debate.

The September 2024 executive proposal for USDS, sUSDS, and SKY token initialization notably did not authorize the ESM in newly deployed contracts ^[21]. This decision signals an ongoing reassessment of how Emergency Shutdown integrates with the post-Endgame protocol architecture. With the retirement of MKR in favor of SKY as the governance token in 2025, the mechanics of ESM participation are evolving to reflect the new token structure.

The protocol continues to maintain and improve its emergency response capabilities. The emergency spells repository provides pre-deployed intervention options for common failure scenarios ^[16], while Protego offers defense against governance attacks without requiring full shutdown ^[17]. These complementary tools reduce the likelihood that Emergency Shutdown would need to be triggered, reserving it for truly catastrophic scenarios where no targeted intervention is sufficient. The cage-keeper software remains available for any participant to run, ensuring that if shutdown is ever triggered, the settlement process can be automated without relying on any single entity ^[15].

The broader evolution of the protocol toward a multi-chain architecture and the Star (SubDAO) ecosystem introduces new considerations for how Emergency Shutdown would function in practice. Cross-chain stablecoins, delegated governance authority, and interconnected lending markets all add complexity to a mechanism designed for a simpler single-chain system. The Cure module addressed one aspect of this challenge, but the full implications of the protocol's expanding architecture for shutdown mechanics remain an active area of technical development and governance discussion.

Sky Protocol — The decentralized credit protocol that Emergency Shutdown protects
Spells — The smart contract execution mechanism for governance decisions, including emergency spells
Sky Governance Voting — The voting system through which ESM parameters are configured
Sky Vaults — Collateralized debt positions that are settled during Emergency Shutdown
Liquidations — The normal-operation mechanism for handling undercollateralized positions
Oracles — Price feed systems whose last known values are used during shutdown settlement
Black Thursday — The March 2020 crisis that most seriously tested the Emergency Shutdown decision framework