Governance Security Module (GSM)

The Governance Security Module (GSM) is a smart contract mechanism within Sky Protocol that enforces a mandatory time delay — known as the Pause Delay — between when an executive vote passes and when the approved changes can be applied to the protocol ^[1]. This delay serves as the protocol's primary defense against governance attacks, providing the community with a window to detect malicious proposals, mobilize a counter-vote, or trigger Emergency Shutdown before harmful changes take effect ^[2]. The GSM Pause Delay value is specified in Sky Atlas section A.1.9.3.1.2 and has been adjusted frequently through governance votes to balance security and operational responsiveness ^[3].

The GSM operates through the MCD_PAUSE smart contract (deployed at 0xbE286431454714F511008713973d3b053a2d38f3 on Ethereum mainnet), which implements a delegatecall-based proxy pattern with an enforced delay ^[4]^[5]. Every parameter change approved through Sky's continuous approval voting system must pass through this time-lock before execution. The design draws from traditional governance theory — analogous to how legislative systems impose waiting periods between a bill's passage and its enactment — translated into deterministic smart contract logic ^[6].

The module's importance was underscored by the October 2020 flash loan governance incident, in which B.Protocol borrowed 13,000 MKR tokens via flash loan to pass a governance proposal in a single transaction ^[7]. While B.Protocol was transparent about their actions and the Maker Foundation acknowledged awareness of the vulnerability, this proof-of-concept demonstration catalyzed both the DsChief 1.2 security upgrade and a significant increase to the GSM Pause Delay, demonstrating how the module functions as a critical security layer within Sky's defense-in-depth governance architecture ^[8].

History and Evolution

The Governance Security Module has undergone significant parameter changes since its deployment as part of the Multi-Collateral Dai (MCD) system launch on November 18, 2019, reflecting the protocol's evolving understanding of governance attack vectors and operational needs ^[9]. The GSM's history is inseparable from the broader evolution of MakerDAO's governance infrastructure, as each security incident and operational challenge prompted recalibration of the delay parameter.

The fundamental tension the GSM addresses — the trade-off between governance responsiveness and governance security — has shaped its parameter history. A longer delay provides more time to detect and respond to attacks but slows the protocol's ability to react to market emergencies. A shorter delay enables faster governance action but narrows the window for community intervention against malicious proposals ^[2].

MCD Launch and Early Configuration

When Multi-Collateral Dai launched in November 2019, the DsPause contract was deployed as part of the governance module with an initial Pause Delay configuration ^[9]. The early MCD period established the governance patterns — executive votes, spells, and the hat system — that the GSM would protect for years to come ^[10].

The October 2020 Flash Loan Incident

The most consequential event in the GSM's history occurred on October 26, 2020, when B.Protocol executed a flash loan governance demonstration ^[7]. B.Protocol borrowed approximately 13,000 MKR tokens (valued at roughly $7 million) from dYdX, used the borrowed tokens to vote on a governance proposal to whitelist their protocol, and repaid the loan — all within a single Ethereum transaction ^[7]^[11]. While the Maker Foundation stated the action did not appear malicious and B.Protocol was transparent about their intentions, the incident demonstrated that DsChief V1 allowed tokens to be locked for voting and unlocked within the same block, enabling a borrow-vote-repay cycle with zero capital requirement ^[8].

The community responded with two coordinated security measures. First, the DsChief 1.2 upgrade introduced a cross-block requirement: MKR tokens locked in voting could only be unlocked in a subsequent block, preventing same-transaction flash loan attacks ^[8]. Second, governance increased the GSM Pause Delay to 72 hours through an executive vote on October 30, 2020, providing an extended window for community response to any proposal that might still pass through compromised voting ^[12].

Parameter Adjustment History

The GSM Pause Delay has been adjusted multiple times through governance votes, reflecting changing threat assessments and operational needs:

Date	Change	Delay	Rationale
November 2019	MCD Launch	0 hours	System deployment with no initial delay ^[9]
December 2019	Increase	24 hours	Security hardening after vulnerability disclosure
Pre-Oct 2020	Set	12 hours	Operational balance
October 2020	Increase	72 hours	Flash loan incident response ^[12]
April 2023	Increase	48 hours	Strengthen security post-stabilization ^[13]
April 2024	Decrease	30 hours	Enable faster governance response ^[14]

The Atlas specifies that adjusting the GSM Pause Delay is a manual process requiring an executive vote, and changes to the delay are themselves subject to the pre-change delay ^[2]. This recursive property ensures that an attacker who compromises governance cannot immediately reduce the delay to zero — the existing delay must expire first, providing time for counter-measures ^[2].

Technical Architecture

The GSM's technical implementation centers on the DsPause contract system, a delegatecall-based proxy with an enforced time-lock that mediates all governance parameter changes in Sky Protocol. The architecture separates scheduling, verification, and execution into distinct operations, providing multiple checkpoints where malicious actions can be detected and blocked ^[4].

Understanding the GSM requires familiarity with several interconnected contracts: MCD_PAUSE (the time-lock itself), DSPauseProxy (the execution context), DsChief (the voting system that feeds proposals into the GSM), and the various MOM contracts that provide authorized exceptions to the delay ^[4]^[5].

DsPause Contract Mechanics

The MCD_PAUSE contract exposes three primary functions ^[4]:

plot(usr, tag, fax, eta) — Schedules a governance action (a "plan") for future execution. The usr parameter specifies the target contract address, tag contains the expected code hash for verification, fax holds the encoded function calldata, and eta sets the earliest execution timestamp. The function enforces that eta must be greater than block.timestamp + delay, ensuring the Pause Delay is respected ^[4].
exec(usr, tag, fax, eta) — Executes a previously scheduled plan once the delay period has elapsed. The function verifies that the current block timestamp exceeds the plan's eta before executing via delegatecall through the DSPauseProxy ^[4].
drop(usr, tag, fax, eta) — Cancels a scheduled plan that has not yet been executed. This is the mechanism behind the Executive Drop Exception, allowing a new governance proposal to cancel a pending one ^[5]^[15].

DSPauseProxy and Storage Isolation

The DsPause contract uses a separate DSPauseProxy with isolated storage context to prevent malicious storage modifications during plan execution ^[4]. Each delegatecall operation executes with the proxy's identity rather than the pause contract's identity, ensuring that even a carefully crafted spell cannot modify the pause contract's internal state (such as the delay parameter or the authority reference) ^[4]. The pause contract retains permanent ownership of its proxy, and this ownership cannot be transferred or revoked ^[4].

The Hat System and Proposal Flow

The DsChief governance contract uses a continuous approval voting mechanism where SKY (formerly MKR) token holders lock tokens to support specific proposals ^[10]. The proposal with the most locked token support becomes the "hat" — the active governance proposal authorized to make protocol changes ^[10]. The complete lifecycle of a governance change flows through:

Token holders lock SKY in DsChief to support a proposal (spell)
The proposal accumulates enough support to become the hat via lift()
The spell calls plot() on MCD_PAUSE to schedule its actions
The GSM Pause Delay period elapses
Anyone can call exec() to execute the scheduled actions (subject to the office hours modifier)
The DSPauseProxy executes the spell's actions via delegatecall

The office hours modifier restricts execution to Monday through Friday, 14:00–21:00 UTC, ensuring operational teams and keepers are actively monitoring when protocol changes take effect ^[16].

Smart Contract Addresses

Contract	Address	Function
MCD_PAUSE	`0xbE286431454714F511008713973d3b053a2d38f3`	Main time-lock contract ^[5]
MCD_PAUSE_PROXY	`0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB`	Execution proxy ^[17]
DSChief	`0x9ef05f7F6deB616fd37AC3c959a2ddd25A54E4F5`	Governance voting ^[18]

Exceptions to the Pause Delay

While the GSM Pause Delay applies to all standard governance parameter changes, Sky Protocol defines a structured set of exceptions where specific emergency actions can bypass the delay ^[19]. These exceptions exist because certain threats — such as oracle manipulation or cascading liquidations — require response times faster than the Pause Delay permits. Each exception is implemented through a dedicated "MOM" (Module Oversight Manager) contract that provides governance with the ability to execute whitelisted emergency actions immediately ^[19].

The exception framework represents a carefully calibrated trade-off. Each bypass mechanism introduces its own attack surface — an attacker who compromises governance could use the same MOM contracts to cause harm without the delay window. The Sky Atlas documents the specific risks each exception opens alongside its defensive purpose ^[19].

Executive Drop Exception (MCD_PAUSE)

The MCD_PAUSE contract contains a built-in exception: a successful governance proposal can cancel a previous proposal that has not yet passed the GSM Pause Delay and been executed ^[15]. The cancelling proposal must become the hat (accumulate more SKY support than any other proposal). This allows governance to block a malicious proposal before it executes, provided defenders can mobilize sufficient token weight within the delay window ^[15].

The risk this introduces is that an attacker could use the drop functionality to delay or permanently block legitimate governance proposals by continuously submitting competing proposals ^[15].

MOM Contract Exceptions

The following MOM contracts provide specific GSM bypass capabilities:

MOM Contract	Exception	Function
OSM_MOM	Oracle Freeze	Immediately freezes oracle prices for any or all vault types; unfreezing requires the full GSM delay ^[20]
LINE_MOM	Debt Ceiling Breaker	Sets debt ceilings of whitelisted vault types to zero; reversal requires GSM delay ^[21]
CLIPPER_MOM	Liquidations Circuit Breaker	Imposes four levels of liquidation restrictions (L0–L3); includes permissionless activation on extreme price drops ^[22]
DIRECT_MOM	D3M Breaker	Disables Direct Deposit Modules by zeroing the `bar` parameter ^[23]
FREEZER_MOM	SparkLend Freezer	Freezes or pauses any SparkLend markets; can also undo such actions ^[24]
SPLITTER_MOM	Smart Burn Engine Breaker	Disables the Smart Burn Engine and associated USDS staking reward distribution ^[25]

The CLIPPER_MOM contract is notable for including a permissionless activation mechanism: if a collateral's price decreases by more than a preset percentage between oracle price updates, anyone can trigger the circuit breaker at Level 2 (disabling new liquidations and resets) without a governance vote ^[22]. This prevents the protocol from executing liquidations at manipulated prices during an oracle attack.

Bounded External Access Modules (BEAMs)

BEAMs represent a newer class of GSM exception. These contracts allow whitelisted operators to manage specific parameters without using the standard executive vote process, meaning changes are not subject to the Pause Delay ^[26]. BEAM actions are bounded by risk parameters (minimum, maximum, step size, and cooldown period) set by governance through executive votes that are themselves subject to the GSM delay ^[26]. This architecture enables operational agility — such as frequent rate adjustments — while maintaining governance-defined safety boundaries.

Emergency Spells and Protego

Standby Spells are pre-deployed emergency contracts that can bypass the GSM Pause Delay to perform critical actions such as freezing oracles, zeroing debt ceilings, disabling D3Ms, or halting liquidations ^[27]. Unlike standard spells, Standby Spells and their factory contracts are reusable, meaning they can be executed multiple times or re-voted for repeated use ^[27].

Protego is a complementary mechanism that allows governance to cancel planned governance actions that are awaiting the expiration of the GSM Pause Delay ^[28]. While the Executive Drop Exception cancels pending proposals by becoming the new hat, Protego provides an additional cancellation pathway for scheduled actions already plotted in MCD_PAUSE ^[28].

Security Model and Attack Vectors

The GSM forms the cornerstone of Sky Protocol's defense-in-depth governance security model, working in conjunction with DsChief voting restrictions, Emergency Shutdown, MOM contracts, and community monitoring to protect against a spectrum of governance attack vectors ^[1]^[6]. The module's effectiveness depends not only on its technical implementation but also on the community's ability to detect and respond to threats within the delay window.

The fundamental security guarantee the GSM provides is temporal: even if an attacker successfully passes a malicious executive vote, the protocol's state remains unchanged for the duration of the Pause Delay ^[1]. During this window, token holders can exit their positions (close vaults, sell USDS), governance can organize a counter-vote to cancel the pending proposal, or participants can trigger Emergency Shutdown as a last resort ^[6].

Flash Loan Attack Defense

The GSM's role as a flash loan defense operates on a fundamental economic principle: the delay transforms a governance exploit from a zero-capital attack into a capital-intensive operation ^[7]^[8]. Before the DsChief 1.2 upgrade, a bad actor could borrow governance tokens, vote, and repay within one block — requiring only transaction fees. After the upgrade, any party attempting to manipulate governance must actually acquire and hold governance tokens across blocks, making the capital cost proportional to the token's market capitalization ^[8]. The GSM then provides additional protection: even if someone purchases sufficient tokens, the delay prevents immediate execution ^[1].

Emergency Shutdown Relationship

The GSM and Emergency Shutdown Module (ESM) form a complementary security hierarchy. The ESM can trigger a full protocol shutdown immediately, bypassing the GSM Pause Delay entirely ^[29]. This ensures that if a malicious proposal passes governance and the delay window is insufficient for organizing a counter-vote, participants can deposit MKR into the ESM (currently requiring 300,000 MKR as of July 2024) to halt the protocol before damage occurs ^[29]. The asymmetry is deliberate: normal governance changes are slowed by the GSM for safety, while the emergency escape hatch remains instant ^[29].

Recursive Delay Protection

A critical design property of the GSM is that changes to the Pause Delay parameter are themselves subject to the current delay ^[2]. If an attacker passes a proposal to reduce the delay to zero, the reduction itself must wait for the current delay to expire before execution. During that window, defenders can organize a counter-proposal or trigger emergency measures. This recursive property prevents an attacker from instantly circumventing the time-lock by modifying it ^[2].

Criticism and Risks

The Governance Security Module, while essential to Sky Protocol's security architecture, introduces trade-offs that have generated ongoing debate within the governance community. Critics have raised concerns about the delay's impact on governance responsiveness, the centralization implications of MOM bypass mechanisms, and the module's effectiveness against well-resourced attackers.

Responsiveness Trade-Off

The core criticism of the GSM is that the Pause Delay slows governance's ability to respond to time-critical situations ^[2]. During periods of extreme market volatility — such as the March 2020 crash that caused Black Thursday — governance may need to adjust parameters (stability fees, liquidation ratios, debt ceilings) faster than the delay permits. The GSM delay has fluctuated between 12 and 72 hours over the protocol's history as governance has repeatedly recalibrated this trade-off, illustrating the irreducible tension between responsiveness and protection.

MOM Centralization Concerns

The MOM bypass contracts concentrate significant power in governance proposals that can be executed immediately. If an attacker gains sufficient voting power — even temporarily — they could use MOM contracts to freeze oracles, halt liquidations, zero debt ceilings, or disable the Smart Burn Engine without waiting for the Pause Delay ^[20]^[21]^[22]^[25]. The Atlas documents each MOM's specific attack surface: OSM_MOM could be used to freeze oracles and prevent expensive liquidations or mint unbacked USDS; CLIPPER_MOM could halt liquidations to prevent collateral seizure; LINE_MOM could zero debt ceilings, disrupting protocol operations ^[20]^[21]^[22].

Governance Concentration

The GSM's effectiveness as a defense mechanism relies on the assumption that the community can mobilize a counter-vote within the delay window. As documented across Sky governance analyses, voting power concentration remains significant — a November 2024 vote showed four entities controlling approximately 80% of voting power ^[30]. If large token holders collude or are compromised, the GSM delay may prove insufficient if defenders cannot assemble comparable voting weight ^[30].

Operational Complexity

The proliferation of MOM contracts and exception types adds complexity to the governance security model. Each exception represents both a defensive tool and an attack surface. Governance participants must understand not only the Pause Delay itself but also the full catalog of bypass mechanisms, their whitelists, and their risk profiles — a cognitive burden that may exceed the capacity of casual governance participants ^[19].

Current State and Outlook

As of January 2026, the GSM Pause Delay continues to be adjusted through governance votes as the protocol balances security and operational needs; the current value is specified in Sky Atlas section A.1.9.3.1.2 ^[3]. The module continues to function as the primary time-lock for all standard governance parameter changes, with the established catalog of MOM-based exceptions providing emergency bypass capabilities ^[19].

The ongoing transition toward BEAM-based governance represents the most significant architectural evolution affecting the GSM's role. As more routine parameter adjustments (rate changes, risk parameter tuning) move to BEAM operators who bypass the Pause Delay within bounded ranges, the GSM increasingly focuses on protecting structural protocol changes — new collateral types, contract upgrades, debt ceiling modifications, and governance architecture changes ^[26]. This narrowing of scope reflects the protocol's maturation: routine operations are delegated to bounded autonomous systems, while the GSM guards the higher-stakes governance actions that warrant community review.

The Protego contract, added to the chainlog in the May 15, 2025 executive vote alongside the MKR-to-SKY upgrade Phase One, provides an additional cancellation mechanism for scheduled governance actions, further strengthening the GSM's defensive capabilities ^[31].

Executive Votes — The governance mechanism that feeds proposals into the GSM
Spells — The smart contract format for governance proposals subject to GSM delay
Sky Governance Voting — Overview of the voting system including DsChief
Emergency Shutdown — The failsafe mechanism that bypasses the GSM
BEAM Payload Safety — Bounded exception modules for operational governance
Sky Atlas — The constitutional document defining GSM parameters
Black Thursday — The crisis that highlighted governance response timing
Oracles — Protected by the OSM_MOM exception mechanism