Spells

Introduction

Spells are specialized smart contracts that encode and execute governance-approved changes to Sky Protocol, serving as the definitive bridge between community voting decisions and on-chain protocol modifications ^[1]. In the Sky ecosystem (formerly MakerDAO), every parameter adjustment, collateral onboarding, system upgrade, oracle update, and emergency response flows through the spell mechanism—making spells the critical technical implementation layer for one of decentralized finance's most complex governance systems.

The term "spell" is unique to Sky Protocol and refers to all technical components of an executive vote, encompassing the codebase, code operations, code reviews, and overall code quality ^[1]. Unlike traditional multi-use smart contracts, spells are designed as atomic, one-time executables that perform their defined actions exactly once and cannot be reused. This architectural choice ensures that each governance decision receives a purpose-built, audited implementation rather than relying on generic templated code that might introduce unintended side effects.

The spell system has evolved through nearly a decade of real-world operation, surviving multiple security incidents including the October 2020 flash loan governance attack, Black Thursday's cascade of zero-bid liquidations, and various smart contract vulnerabilities ^{[34][35][37][38]}. Each crisis refined the system's security model, resulting in today's sophisticated infrastructure of time-delayed execution, emergency response mechanisms, cross-organization review processes, and automated monitoring systems.

As of December 2025, Sky Protocol employs a comprehensive spell infrastructure featuring:

• GSM Pause Delay: 30-48 hours of mandatory delay before spell execution ^[6]
• Spell Teams: Two primary organizations (Sidestream and Dewiz) providing crafting and review services ^[3]
• Emergency Mechanisms: Standby spells, Protego cancellation, and pre-deployed circuit breakers ^[7][8]
• Automated Infrastructure: Chief-keeper bots for hat management, extensive test suites, and formal verification ^[12][23]

This article provides a comprehensive examination of spell architecture, lifecycle, security mechanisms, historical incidents, and the operational processes that make spells the backbone of Sky Protocol's governance execution. Understanding spells is essential for anyone participating in Sky governance, developing on the protocol, or studying DeFi governance mechanisms.

History and Evolution

The spell mechanism emerged alongside MakerDAO's pioneering development of decentralized governance infrastructure, evolving from simple parameter changes in 2017 to a sophisticated multi-layered system capable of coordinating complex protocol upgrades across multiple contracts and chains.

Origins and the DappHub Foundation (2017-2018)

MakerDAO's governance module, including the spell system, was designed during the protocol's foundational development period in 2017-2018 ^[15]. The architecture drew heavily from DS-Auth patterns developed by DappHub—a collection of modular smart contract building blocks created by MakerDAO's early developers. This foundation established the critical separation between voting (Chief contract) and execution (Spell contracts) that remains central to Sky governance today.

The original DSChief contract (version 1.0) implemented continuous approval voting, a mechanism where token holders could deposit MKR and approve multiple proposals simultaneously ^[16]. The proposal with the most weighted approvals became the "hat"—the designated address with authority to trigger governance actions. This design avoided the discrete voting periods common in traditional governance systems, instead allowing governance to respond fluidly to changing community preferences.

Early spells were relatively simple Solidity contracts that modified individual parameters—stability fees, debt ceilings, or oracle addresses. However, as Multi-Collateral DAI launched in November 2019, spell complexity grew dramatically with the need to coordinate changes across dozens of interacting contracts ^[15].

The Governance Security Module Activation (December 2019)

The Governance Security Module (GSM) was activated on December 9, 2019, introducing the critical time-delay mechanism that protects against malicious governance actions ^[25][26]. The initial GSM Pause Delay was set at 24 hours, giving token holders time to review approved changes before execution and providing a window to trigger Emergency Shutdown if necessary.

The GSM activation represented a philosophical shift in MakerDAO's governance model. Prior to the GSM, approved spells could execute immediately, creating a theoretical window where a governance attack could drain the protocol before defenders could respond. The 24-hour delay introduced a security buffer but also created new challenges around emergency response capabilities ^[25].

Key technical elements of the original GSM implementation included:

• Pause Contract: Queues scheduled transactions and enforces the delay period ^[17]
• Authority Checks: Only the "hat" address (the winning spell) could schedule new actions
• Emergency Shutdown Override: The ESM module could bypass all governance to trigger shutdown if 50,000 MKR was deposited

Black Thursday and Emergency Governance (March 2020)

March 12, 2020—"Black Thursday"—tested the spell system under extreme duress when a market crash triggered cascading liquidations across the Maker Protocol ^[37][38]. Ethereum network congestion caused keepers (liquidation bots) to fail, and approximately $8.32 million in ETH collateral was liquidated for zero DAI in auctions where the winning bidders were the only participants.

The crisis exposed critical vulnerabilities in the spell system's emergency response capabilities:

The Emergency Response Challenge

With the 24-hour GSM delay in place, the protocol couldn't quickly adjust parameters to stabilize the system. The governance community faced a difficult choice: reduce the GSM delay to enable faster responses (increasing governance attack surface) or accept that emergency parameter changes would always lag behind market crises.

The community chose to temporarily reduce the GSM delay to 4 hours through an emergency spell on March 13, 2020. This decision demonstrated both the flexibility and the risks inherent in the governance system—faster response times came at the cost of reduced security margins ^[31][45].

Lessons Learned

Black Thursday catalyzed several improvements to the spell infrastructure:

1. Emergency Shutdown Threshold Review: Confirmed the 50,000 MKR threshold was appropriate for nuclear option
2. GSM Delay Flexibility: Established precedent for adjusting delay based on threat environment
3. Circuit Breaker Development: Accelerated work on automatic protection mechanisms
4. Liquidation System Redesign: Led to development of Liquidations 2.0 (auction mechanism improvements)

The GSM delay was gradually increased back to 72 hours by October 2020 as the immediate crisis subsided and the need for strong governance security reasserted itself.

The Flash Loan Governance Attack (October 2020)

On October 26, 2020, a pivotal incident demonstrated both the sophistication of DeFi composability and a critical vulnerability in the spell system's voting mechanism ^[34][35][36].

The Attack Mechanics

B.Protocol, a DeFi project seeking oracle whitelisting, executed a flash loan governance manipulation:

1. Flash Loan Acquisition: Borrowed $20 million (approximately 50,000 ETH) from dYdX and Aave
2. Token Swap: Used Uniswap to acquire approximately 13,000 MKR (worth ~$7 million at the time)
3. Vote Casting: Deposited MKR in the Chief contract and voted for their oracle whitelisting proposal
4. Immediate Withdrawal: Withdrew MKR, swapped back to ETH, and repaid the flash loan
5. Net Result: Gained temporary voting power sufficient to influence governance at minimal cost

The entire operation occurred within a single Ethereum transaction, costing only gas fees (~$1,000) rather than the millions of dollars that permanent token acquisition would require.

Transparency and Intent

B.Protocol acted transparently, publishing their intentions and noting that the proposal itself was legitimate—they genuinely wanted oracle access. The demonstration was partly educational, showing the community that flash loan governance attacks were practical, not just theoretical ^[34].

However, the attack exposed a critical vulnerability: the DSChief 1.0/1.1 contracts allowed voting and withdrawal within the same block, enabling zero-cost temporary governance power acquisition ^[30].

Emergency Response (October 30, 2020)

The MakerDAO community responded with an emergency executive vote within four days ^[28]:

1. GSM Delay Increase: Raised from 12 hours to 72 hours, providing maximum response window ^[30]
2. Module Deauthorization: Removed instant-access modules (Oracle Freeze, Liquidations Circuit Breaker) that could be exploited with temporary governance control
3. DsChief 1.2 Planning: Began development of flash-loan-resistant voting mechanism

DSChief 1.2: The Definitive Fix

DSChief 1.2, deployed on May 3, 2021, implemented cross-block voting requirements to prevent same-block flash loan manipulation ^[27][18]. The key changes:

• Lock Delay: MKR must be locked for at least one block before votes count
• Free Delay: Cannot withdraw MKR in the same block as locking
• Snapshot Voting: Vote weights calculated based on prior block state

The new Chief contract was deployed at address 0x9ef05f7f6deb616fd37ac3c959a2ddd25a54e4f5 ^[47]. All MKR holders were required to migrate their locked tokens from the old Chief to the new one—a governance upgrade requiring coordination across thousands of token holders.

The Dark Spell Mechanism (MIP15)

Concurrent with flash loan attack responses, the governance community formalized the dark spell mechanism through MIP15, approved in September 2020 ^[29]. Dark spells addressed a different security challenge: how to patch critical vulnerabilities without exposing details to potential attackers.

The Responsible Disclosure Problem

Traditional responsible disclosure requires sharing vulnerability details with the affected party before public announcement. In decentralized governance, the "affected party" is thousands of anonymous token holders who vote on fixes. Publishing vulnerability details to enable informed voting also publishes them to attackers.

CREATE2 Pre-Commitment Solution

Dark spells use Ethereum's CREATE2 opcode to pre-commit to a spell address before revealing the actual bytecode ^[24]:

1. Deploy Factory: Deploy a factory contract with known bytecode
2. Compute Address: Calculate the deterministic address where the fix spell will deploy
3. Vote on Address: Governance votes on the computed address without seeing the fix code
4. Reveal and Deploy: After vote passes, reveal bytecode and deploy to the pre-committed address
5. Execute: Spell executes through normal GSM delay process

MIP15 established strict criteria for dark spell usage:

• Critical bugs affecting 10% or more of collateral value
• Vulnerabilities that could cause significant protocol damage
• Situations where disclosure would enable exploitation before fix deployment

Subsequent Evolution

The dark spell mechanism was later superseded by MIP102c2-SP1 as the Atlas governance framework evolved, but the underlying pattern remains available for critical vulnerability response ^[32].

WBTC Spells Bug Incident (March 2021)

In March 2021, a bug in spell code for WBTC-B parameters highlighted the importance of rigorous spell testing ^[39]. The spell incorrectly configured parameters, potentially exposing the protocol to risk. The incident was caught during review, the spell was not executed, and the discovery led to enhanced testing procedures including:

• Expanded integration test coverage
• Additional code review checklists
• Improved parameter validation in dss-exec-lib

March 2023 Governance Crisis

March 2023 brought a governance crisis when competing factions created conflicting spells, temporarily fragmenting the community's focus and raising concerns about governance capture ^[33]. While details remain sensitive, the incident reinforced the importance of:

• Clear governance procedures documented in the Atlas
• Spell team neutrality and professionalism
• Emergency response coordination capabilities
• The role of Protego in canceling contentious proposals

Transition to Sky Protocol (2024-2025)

The August-September 2024 rebrand from MakerDAO to Sky Protocol brought comprehensive updates to the spell system while maintaining core functionality ^[51]. Key transition elements:

Token Upgrade Spells

The MKR-to-SKY governance token upgrade (Phase One executed May 15, 2025) required careful spell choreography to transition voting power ^[51]:

• Migration contract deployment and configuration
• Chief contract updates for SKY compatibility
• Delegate proxy modifications
• Vote weight recalculation (1 MKR = 24,000 SKY)

GSM Delay Adjustments

The transition period saw multiple GSM delay adjustments reflecting changing security requirements:

Protego Deployment

The Protego cancellation contract was formally added to the chainlog in the May 15, 2025 executive, establishing the definitive mechanism for stopping malicious or erroneous spells before execution ^[51][49].

Technical Architecture

Spells operate within Sky Protocol's governance module, interacting with the Chief voting contract, the Pause delay mechanism, and the protocol's core smart contracts to implement authorized changes atomically. Understanding this architecture is essential for anyone participating in governance validation or spell development.

Governance Module Overview

The governance module consists of several interconnected smart contract components that together enable secure, decentralized protocol control ^[15]:

┌─────────────────────────────────────────────────────────────────┐
│                     SKY TOKEN HOLDERS                            │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ lock/free/vote
┌─────────────────────────────────────────────────────────────────┐
│                    DSCHIEF 1.2 (Voting)                          │
│  Contract: 0x9ef05f7f6deb616fd37ac3c959a2ddd25a54e4f5           │
│  - Continuous approval voting                                    │
│  - Hat mechanism (highest approval = authority)                  │
│  - Cross-block lock requirements                                 │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ schedule (only hat)
┌─────────────────────────────────────────────────────────────────┐
│                    PAUSE (GSM Delay)                             │
│  - Queues scheduled transactions                                 │
│  - Enforces time delay (currently 30-48h)                       │
│  - Contains plan() and exec() functions                         │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ cast() after delay
┌─────────────────────────────────────────────────────────────────┐
│                    SPELL CONTRACT                                │
│  - One-time executable                                           │
│  - Contains SpellAction with protocol changes                   │
│  - Uses delegatecall for atomic execution                       │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ modify
┌─────────────────────────────────────────────────────────────────┐
│               SKY PROTOCOL CORE CONTRACTS                        │
│  Vat, Jug, Spot, Cat, Vow, Flapper, Flopper, etc.              │
└─────────────────────────────────────────────────────────────────┘

DSChief: The Voting Contract

The DSChief contract implements continuous approval voting, a mechanism fundamentally different from discrete voting periods ^[16][47]:

Core Functions

The Hat Mechanism

The "hat" is the proposal with the highest weighted approval at any given time. Only the hat has authority to schedule new governance actions in the Pause contract. When a new spell accumulates more approvals than the current hat, anyone can call lift() to transfer hat status.

Cross-Block Protection (DSChief 1.2)

The 1.2 upgrade introduced critical flash loan protection ^[27]:

// Simplified illustration of cross-block requirement
function lock(uint wad) public {
    GOV.transferFrom(msg.sender, address(this), wad);
    deposits[msg.sender] = add(deposits[msg.sender], wad);
    // Vote weight doesn't count until next block
    lastBlock[msg.sender] = block.number;
}

function vote(address[] memory yays) public {
    // Require lock occurred in previous block
    require(lastBlock[msg.sender] < block.number, "same-block-lock");
    // Record vote...
}

This prevents atomic flash loan voting by ensuring tokens must be held across at least one block boundary before their voting weight applies.

Pause Contract: The GSM Delay Mechanism

The Pause contract enforces the GSM delay—the mandatory waiting period between spell approval and execution ^[17]:

Core Functions

Parameters Explained

• usr: The spell contract address
• tag: Hash of spell contract's bytecode
• fax: Encoded function call data (typically the execute() function)
• eta: Timestamp when spell becomes executable (current time + GSM delay)

Delegatecall Execution

When exec() is called, the Pause contract uses delegatecall to execute the spell's code in the Pause contract's storage context. This is why spell action contracts must be carefully written—they execute with the Pause contract's authority ^[11]:

The cast() function triggers the complete execution flow ^[10]:

// The cast() function on a spell triggers this flow:
// 1. Spell.cast() calls pause.exec()
// 2. Pause.exec() verifies eta has passed
// 3. Pause uses delegatecall to SpellAction.execute()
// 4. SpellAction modifies protocol with Pause's authority

DS-Spell Contract Structure

Individual spells follow a standardized structure ^[14]:

contract DssSpell is DssExec {
    constructor() DssExec(block.timestamp + 30 days, address(new DssSpellAction())) {
    }
}

contract DssSpellAction is DssAction {
    function officeHours() public pure override returns (bool) {
        return true;  // Restrict execution to business hours
    }

    function actions() public override {
        // Protocol modifications here
        DssExecLib.setIlkStabilityFee("ETH-A", FOUR_PCT_RATE);
        DssExecLib.setIlkDebtCeiling("ETH-A", 1_000_000_000);
        // ... additional actions
    }
}

Key Characteristics

1. Immutability: Parameters are set at deployment and cannot change
2. Single-Use: The done flag prevents re-execution
3. Atomic: All actions succeed or all revert
4. Time-Bounded: 30-day expiration prevents stale spells from executing
5. Office Hours: Optional restriction to specific execution windows

dss-exec-lib: The Spell Crafting Library

The dss-exec-lib library (deployed at 0x8de6ddbcd5053d32292aaa0d2105a32d108484a6) provides standardized functions for protocol modifications ^[20][48]:

Core Parameter Functions

System-Wide Functions

Permission Functions

Helper Utilities

Using these standardized functions reduces spell complexity and error potential compared to raw Solidity interactions with protocol contracts.

DssAction Base Contract

All SpellAction contracts inherit from DssAction, which provides the execution framework ^[20]:

abstract contract DssAction {
    // To be overridden by implementing contract
    function actions() public virtual;

    // Office hours check (override to disable)
    function officeHours() public virtual returns (bool);

    // Description for governance
    function description() external virtual view returns (string memory);

    // Execute the spell actions
    function execute() external {
        require(!done, "spell-already-cast");
        if (officeHours()) {
            require(block.timestamp % 1 weeks >= 14 hours, "not-office-hours");
            require(block.timestamp % 1 weeks < 21 hours, "not-office-hours");
        }
        actions();
        done = true;
    }
}

Office Hours Restriction

The office hours modifier restricts spell execution to 14:00-21:00 UTC, Monday through Friday ^[44]. This constraint ensures execution occurs when maximum community members and developers are available to respond to issues. The restriction can be disabled for time-sensitive operations by overriding officeHours() to return false.

Chief Keeper: Automated Hat Management

The chief-keeper bot monitors the DSChief contract and automatically lifts spells to hat status when they accumulate sufficient approvals ^[12][23]:

Operational Parameters

• Monitors DSChief for approval changes every block
• Compares spell approvals against current hat
• Calls lift() when a new spell exceeds hat threshold
• Runs continuously via dedicated infrastructure

Technical Implementation

while True:
    current_hat = chief.hat()
    current_approvals = chief.approvals(current_hat)

    for spell in pending_spells:
        spell_approvals = chief.approvals(spell)
        if spell_approvals > current_approvals:
            # Lift this spell to become the new hat
            chief.lift(spell)
            break

    wait_for_next_block()

Contract Addresses (Mainnet)

Spell Types

Sky Protocol employs several categories of spells with distinct purposes, security characteristics, and execution requirements. Understanding these categories is essential for governance participants evaluating proposals.

Regular Executive Spells

Standard executive spells follow a weekly cadence and implement routine governance decisions ^[1]:

Common Operations

• Parameter Adjustments: Stability fees, debt ceilings, liquidation ratios, dust limits
• Collateral Management: Onboarding new collateral types, offboarding deprecated ones
• Oracle Updates: Adding/removing oracle sources, updating price feed configurations
• Treasury Operations: Budget disbursements, delegate compensation, service provider payments
• Technical Upgrades: Contract migrations, permission updates, integration changes

Execution Characteristics

• Subject to full GSM Pause Delay (30-48 hours)
• Complete review process by Spell Teams
• Office hours restriction applies
• 30-day expiration window
• Visible on governance portal throughout lifecycle

Out-of-Schedule Spells

Some situations require spell execution outside the standard weekly schedule ^[1]:

Triggers for Out-of-Schedule Spells

• Urgent parameter changes responding to market conditions
• Critical security patches
• Time-sensitive governance decisions
• External integration requirements

Process Differences

• Expedited review process (same security standards, compressed timeline)
• Service-level agreements (SLAs) determined case-by-case
• May require emergency coordination across time zones
• Often accompanied by forum announcements explaining urgency

Emergency Spells

Emergency spells provide rapid response capabilities for crisis situations, with some mechanisms bypassing the standard GSM delay ^[2][13].

Standby Spells

Standby spells are pre-deployed contracts that allow Sky Governance to bypass the GSM Pause Delay for critical emergency actions ^[7]. Unlike regular spells, standby spells are reusable and can be executed multiple times.

Standby Spell Categories

Critical Emergency Actions Enabled

• Oracle Stop: Freeze a compromised price feed (OsmStopSpell)
• Debt Ceiling Wipe: Set collateral debt ceiling to zero (LineWipeSpell)
• D3M Disable: Disable Direct Deposit Module integrations (DdmDisableSpell)
• Liquidation Halt: Stop liquidations for specific collateral (ClipBreakerSpell)
• Splitter Stop: Halt the surplus splitter mechanism
• Beam Halt: Stop SP-BEAM allocator operations

MOM Contracts

"MOM" contracts (OsmMom, ClipperMom, FlipperMom, LineMom) provide the actual bypass mechanism, allowing authorized actors to execute specific emergency functions without GSM delay ^[7]:

// Example: OsmMom allows stopping an oracle immediately
contract OsmMom {
    function stop(bytes32 ilk) external auth {
        // No GSM delay - executes immediately
        OsmAbstract(osms[ilk]).stop();
    }
}

Protego: The Cancellation System

Protego is a contract that allows Sky Governance to cancel the execution of planned governance actions awaiting GSM Pause Delay expiration ^[8][49].

Core Features

Technical Parameters

• usr: Authorized user (typically a multi-sig or governance address)
• tag: Target spell identification
• fax: Encoded calldata of the planned action
• eta: Scheduled execution timestamp
• plans: Queue of pending actions

Use Cases

1. Malicious Spell Detection: Community identifies harmful code after approval but before execution
2. Parameter Errors: Spell contains incorrect values that would destabilize protocol
3. Market Condition Changes: Approved changes no longer appropriate for current environment
4. Governance Dispute Resolution: Contested proposal requires reconsideration

Dark Spells (MIP15 Legacy)

Dark spells use CREATE2 deployment to enable voting on vulnerability fixes without disclosing details ^[29][24][32]:

Process Flow

1. Security team identifies critical vulnerability
2. Fix code is written but not disclosed
3. CREATE2 factory computes deterministic deployment address
4. Governance votes on the address (without seeing code)
5. After approval, code is revealed and deployed
6. Spell executes through normal GSM process

Current Status

While MIP15 was superseded by MIP102c2-SP1, the underlying technical capability remains available. The pattern was used during actual vulnerability disclosures and remains a template for responsible disclosure in decentralized systems.

Prime Spells

Prime Spells execute governance actions for Sky Stars (Prime Agents) such as Spark, Grove, Keel, and Obex ^[9]:

Execution Methods

1. Direct Execution through Sky Core Spell: Standard approach where Star actions are included in main executive
2. Execution through StarGuard: Preferred method using isolated execution environment (preferred method)

StarGuard Architecture

StarGuard provides a sandbox for Star operations, limiting potential damage from compromised or buggy Star spells:

• Isolated permission set
• Limited scope of accessible contracts
• Audit requirements specific to Star operations
• Separate review process from core protocol spells

Security Requirements

Prime Spells are subject to comprehensive security guidelines communicated through official channels. Violations constitute misalignment with potential escalated penalties under Atlas framework ^[9].

Spellcrafting Process

The spell development and review process involves multiple specialized roles working within a structured workflow to ensure security and correctness. This section details the complete lifecycle from governance decision to execution.

Spell Team Structure

Each executive vote requires a dedicated Spell Team with defined roles and responsibilities ^[3]:

Required Composition

Cross-Organization Requirements

• At least one reviewer must be from a different Ecosystem Actor than the Crafter
• The Crafter cannot serve as Reviewer for the same spell
• Rotation requirements prevent consecutive crafting by same person

Current Spell Roster

The Spell Roster as of December 2025 consists of two primary teams ^[3]:

Spell Crafter Responsibilities

The Spell Crafter bears primary responsibility for translating governance decisions into executable code ^[4]:

Core Duties

1. Parse written instruction set from Executive Sheet into Solidity code
2. Develop the spell implementation
3. Responsible for ALL code additions, modifications, or removals
4. Run comprehensive test suite before submitting for review
5. Address all reviewer feedback
6. Deploy final approved spell to mainnet

Rotation Requirement

The same person cannot craft spells for two consecutive Executive Votes. This rotation ensures knowledge distribution and prevents single points of failure ^[4].

Workflow Adherence

Crafters follow detailed checklists from the pe-checklists repository ^[22]:

## Pre-Development
- [ ] Review Executive Sheet for completeness
- [ ] Verify all required parameters are specified
- [ ] Confirm no conflicts with pending spells

## Development
- [ ] Clone spells-mainnet template
- [ ] Implement all required actions
- [ ] Add comprehensive test cases
- [ ] Run full test suite (forge test)

## Pre-Review Submission
- [ ] All tests passing
- [ ] Code formatted (forge fmt)
- [ ] Self-review completed
- [ ] PR created with proper description

Spell Reviewer Responsibilities

Spell Reviewers provide independent verification of spell correctness and security ^[5]:

Core Duties

1. Review draft spells as parsed by the Spell Crafter
2. Verify spell quality, find issues, catch bugs and mistakes
3. Confirm alignment between governance decisions and implementation
4. Sign off on final approval

Explicit Restrictions

• Cannot perform any addition, modification, or removal of code
• May only suggest changes to the Crafter
• Final approval authority rests with reviewers collectively

Review Checklist

Reviewers follow standardized checklists verifying ^[22]:

## Technical Correctness
- [ ] All parameters match Executive Sheet exactly
- [ ] Correct contracts being modified
- [ ] Proper rate/RAY/WAD conversions
- [ ] No unintended side effects

## Security Review
- [ ] No unauthorized permission changes
- [ ] No unexpected contract calls
- [ ] delegatecall usage is correct
- [ ] No storage collisions possible

## Operational Review
- [ ] Office hours appropriate
- [ ] Expiration timestamp reasonable
- [ ] Gas usage within limits
- [ ] No blocklist/allowlist conflicts

Development Workflow Timeline

The spell development process follows a structured timeline aligned with weekly governance cycles ^[22]:

Week 1: Preparation

Week 2: Development and Review

Deployment Process (Step by Step)

1. Pre-deployment Setup

   • Verify all tests pass on fork
   • Confirm gas estimates within acceptable range
   • Final review of deployment parameters

2. Mainnet Deployment

   • Spell Crafter deploys spell contract
   • Record deployment transaction and contract address
   • Verify contract on Etherscan

3. Post-Deployment Verification

   • Cast spell on Tenderly fork simulation
   • Verify all actions execute correctly
   • Confirm no unexpected state changes

4. Archive and Documentation

   • Archive spell in repository
   • Update changelog
   • Create Pull Request

5. Final Review and Merge

   • Reviewers verify deployed code matches reviewed code
   • Confirm Etherscan verification
   • Squash and merge PR

6. Handover to Governance

   • Submit spell to governance portal
   • Announce availability for voting
   • Begin GSM countdown upon hat acquisition

Ecosystem Spell Validation

After deployment, spells undergo Ecosystem Spell Validation—a community verification process ^[44]:

Validation Window

• Starts: When spell becomes visible on the Voting Portal
• Ends: Before spell's actions become executable (when GSM Pause Delay elapses)

Validation Activities

Community validators perform independent verification:

1. Download deployed bytecode from Etherscan
2. Compile spell from source code
3. Compare bytecode hashes
4. Review source code for unexpected operations
5. Simulate execution on local fork
6. Report any discrepancies

Who Validates

• Aligned Delegates (governance participants)
• Independent community members
• External security researchers
• Protocol team members (non-Spell Team)

Test Suite Architecture

Modern spell development relies on comprehensive testing ^[43]:

Test Categories

Testing Infrastructure

# Run full test suite
forge test --fork-url $ETH_RPC_URL -vvv

# Run specific spell test
forge test --match-contract DssSpellTest --fork-url $ETH_RPC_URL

# Gas profiling
forge test --gas-report

Typical Gas Costs

Executive spells typically consume 3.8 million to 13.3 million gas depending on complexity ^[50]:

Security Model

The spell system incorporates multiple security layers designed to prevent malicious governance actions while enabling legitimate protocol evolution. This defense-in-depth approach has been refined through multiple real-world incidents.

GSM Pause Delay

The Governance Security Module (GSM) Pause Delay is the primary defense mechanism against governance attacks ^[6][45].

Current Configuration (December 2025)

Security Functions

1. Review Window: Provides time for token holders to analyze approved changes
2. Counter-Organization: Allows minority holders to rally support against malicious proposals
3. Emergency Response: Enables Protego cancellation or Emergency Shutdown trigger
4. Attack Economics: Requires attackers to maintain governance capture for extended periods

Historical GSM Delay Evolution ^[31]

Flash Loan Prevention Architecture

DSChief 1.2 implemented comprehensive flash loan protection ^[27][18]:

Cross-Block Requirements

// Voting power only counts if locked in prior block
mapping(address => uint256) public lastLockBlock;

function lock(uint wad) public {
    lastLockBlock[msg.sender] = block.number;
    // ... token transfer
}

function vote(address[] calldata yays) public {
    require(lastLockBlock[msg.sender] < block.number, "locked-same-block");
    // ... record vote
}

Economic Implications

• Cannot borrow, vote, and repay within single transaction
• Attackers must hold tokens across multiple blocks
• Holding costs (opportunity cost, price risk) scale with token value
• Makes governance attacks economically expensive rather than free

Emergency Shutdown Protection

The Emergency Shutdown mechanism (ESM) requires 50,000 MKR minimum threshold:

• Cannot be triggered with flash loaned tokens
• Must be permanently deposited (burned)
• Creates significant economic barrier to malicious shutdown

Defense in Depth Layers

The spell system employs multiple redundant security mechanisms ^[21]:

Layer 1: Social Layer

• Forum discussions before formal proposals
• Community review of governance intentions
• Delegate analysis and recommendations
• Public deliberation period

Layer 2: Technical Review

• Spell Team crafting and review
• Cross-organization verification
• pe-checklist compliance
• Automated test suite

Layer 3: Ecosystem Validation

• Community bytecode verification
• Independent security researcher review
• Aligned Delegate validation
• Fork simulation testing

Layer 4: Time Lock (GSM)

• 30-48 hour delay before execution
• Continuous monitoring for anomalies
• Window for cancellation or Emergency Shutdown

Layer 5: Emergency Response

• Protego cancellation capability
• Pre-deployed standby spells
• MOM contract immediate actions
• Emergency Shutdown nuclear option

Audit and Verification Infrastructure

Professional Security Audits

Sky Protocol maintains relationships with leading security firms ^[40][41]:

Bug Bounty Program

The Immunefi bug bounty provides economic incentives for responsible disclosure ^[42]:

Formal Verification

Critical protocol components undergo formal verification:

• Mathematical proofs of correctness
• Invariant checking across state transitions
• K Framework symbolic execution
• Act specification language

Spell Validation Checklist

Validators perform extensive checks before approving spells ^[44]:

Bytecode Verification

# Verify deployed bytecode matches source
forge verify-contract $SPELL_ADDRESS \
  --chain mainnet \
  --compiler-version $SOLC_VERSION \
  --constructor-args $ENCODED_ARGS

Source Code Analysis

• All imports from trusted sources
• No unexpected external calls
• Parameter values match governance decisions
• No storage manipulation outside delegatecall context
• Compiler version and optimizations match documented configuration

Simulation Testing

# Execute spell on mainnet fork
cast send $SPELL_ADDRESS "cast()" \
  --rpc-url $FORK_RPC \
  --from $SIMULATOR_ADDRESS

Emergency Response Playbook

When incidents occur, the protocol follows established response procedures ^[13][21]:

Severity Classification

Response Options by Severity

Critical Response:

1. Trigger Emergency Shutdown (if warranted)
2. Execute pre-deployed standby spells
3. Use MOM contracts for immediate actions
4. Activate Protego to cancel pending threats

High Response:

1. Draft out-of-schedule emergency spell
2. Coordinate expedited review
3. Deploy and seek governance approval
4. Monitor during GSM delay

Medium/Low Response:

1. Include fix in next regular executive
2. Standard review process
3. Normal GSM delay execution

Historical Incidents and Lessons

The spell system has been tested through multiple real-world incidents, each contributing lessons that shaped current security architecture.

Black Thursday (March 12, 2020)

Event Summary

A global market crash triggered cascading liquidations when ETH price dropped over 50% in 24 hours ^[37][38]:

• $8.32 million in ETH collateral liquidated for $0 DAI
• Network congestion prevented keeper bots from bidding
• Some liquidators won auctions as sole participants
• Protocol absorbed ~$6.65 million in bad debt

Spell System Implications

1. GSM Delay Conflict: 24-hour delay prevented rapid parameter adjustment
2. Emergency Authority Gap: No mechanism for immediate collateral freezing
3. Coordination Challenge: Global event during off-hours complicated response

Changes Implemented

Flash Loan Governance Attack (October 26, 2020)

Event Summary

B.Protocol demonstrated governance manipulation using flash loans ^[34][35][36]:

• Borrowed ~$20M via flash loans (dYdX + Aave)
• Acquired 13,000 MKR ($7M)
• Voted on oracle whitelisting proposal
• Immediately repaid loan
• Total cost: ~$1,000 in gas

Technical Analysis

The attack exploited DSChief 1.0/1.1's same-block voting:

Block N:
  1. Borrow 50,000 ETH via flash loan
  2. Swap ETH → MKR on Uniswap
  3. Deposit MKR in Chief
  4. Vote on target proposal
  5. Withdraw MKR from Chief
  6. Swap MKR → ETH on Uniswap
  7. Repay flash loan

Changes Implemented

WBTC Parameter Bug (March 2021)

Event Summary

A spell for WBTC-B parameters contained incorrect values that could have destabilized collateral ratios ^[39]:

• Bug caught during review process
• Spell was not executed
• No funds at risk due to detection

Changes Implemented

March 2023 Governance Crisis

Event Summary

Competing governance factions created conflicting spells, fragmenting community attention ^[33]:

• Multiple active proposals with conflicting goals
• Concerns about governance capture
• Community coordination challenges

Changes Implemented

Summary: Lessons Integrated

Each incident contributed specific improvements to the current system:

Criticism and Controversies

The spell system, while battle-tested, faces legitimate criticisms and ongoing debates within the community.

Centralization Concerns

The Critique

The reliance on a small roster of specialized teams (Sidestream and Dewiz) for spell crafting creates potential centralization risks ^[3]:

• Limited teams create single points of failure
• Specialized knowledge concentrates power
• New teams face high barriers to entry
• Geographic and jurisdictional concentration

Counter-Arguments

• Rotation requirements distribute knowledge over time
• Cross-team review prevents unilateral action
• Open-source code enables external verification
• Bug bounty incentivizes independent security research

Protocol Mitigations

Complexity and Accessibility

The Critique

Spell development requires deep Solidity expertise and protocol knowledge, making meaningful community validation difficult:

• Most token holders cannot independently verify spell correctness
• Technical barrier creates reliance on professional reviewers
• Complex interactions may hide subtle bugs or backdoors
• Verification tools require developer expertise

Counter-Arguments

• dss-exec-lib abstracts complexity for common operations
• Comprehensive documentation available
• Test suites provide automated verification
• Multiple independent review layers

Ongoing Improvements

GSM Delay Trade-offs

The Critique

The 30-48 hour GSM delay represents a fundamental trade-off between security and operational flexibility ^[45]:

• Extended delays slow legitimate emergency responses
• Market conditions can change rapidly during delay periods
• Competitors without delays can move faster
• Some time-sensitive opportunities may be missed

Counter-Arguments

• Standby spells provide instant emergency response
• Security breaches could cost far more than delayed operations
• Predictable execution timing aids planning
• Delay has prevented multiple attack attempts

Community Position

The current 30-hour delay represents community consensus balancing:

• Sufficient time for review and response
• Not so long as to impair operations
• Adjustable through governance if needed
• Supplemented by emergency mechanisms

Governance Attack Surface

The Critique

Despite improvements, the spell system retains theoretical attack vectors:

• Wealthy actors could still acquire temporary voting control
• Cross-block requirements add friction but don't eliminate risk
• Social engineering could compromise Spell Teams
• Validator fatigue might reduce scrutiny quality

Counter-Arguments

• Attack costs now scale properly with token value
• Multi-layer defense provides redundancy
• Professional teams have accountability
• Incident response capabilities exist

Risk Assessment

Historical Vulnerabilities

The Critique

Past incidents (flash loan attack, Black Thursday) demonstrated that sophisticated actors could exploit governance mechanisms ^[34][37]:

• Attacks were preventable with better design
• Reactive security rather than proactive
• Learning came at cost of actual incidents

Counter-Arguments

• Each incident strengthened the system
• Current architecture addresses known vectors
• Bug bounty incentivizes pre-emptive discovery
• No system is perfect; resilience matters

Current State and Metrics

As of December 2025, the spell system operates with mature infrastructure and established processes.

Operational Parameters

Voting Statistics

Based on recent governance activity ^[50]:

Infrastructure Repositories

Active repositories supporting spell operations ^{[19][20][21][23]}:

Contract Addresses

Governance Portal

Executive spells are accessible through vote.sky.money/executive ^[46], providing:

• Current active proposals with voting status
• Historical spell archive (searchable)
• Voting interface for SKY holders
• Execution status tracking
• Spell source code links
• GSM countdown timers

Related Topics

• Sky Governance Voting - The continuous approval voting system that determines which spells become the "hat"
• Sky Protocol - The foundational protocol that spells modify and govern
• SKY Token - The governance token used to vote on spell execution
• Sky Staking - The LockStake Engine that enables governance participation
• Sky Stars - Prime Agents whose operations are governed through Prime Spells
• Emergency Shutdown - The nuclear option backstop for critical failures

Glossary

Data Freshness

This article was generated on December 9, 2025 using sources accessed on that date.

Permanent Information (unchanged unless governance votes modify):

• Spell architecture and execution flow
• DSChief contract mechanics
• dss-exec-lib function signatures
• Security model principles
• Historical incident details

Semi-Static Information (updated periodically):

• GSM delay duration (currently 30-48h)
• Spell Team roster (Sidestream, Dewiz)
• Contract addresses
• Operational procedures

Dynamic Information (changes frequently):

• Current active proposals
• Voting statistics
• Recent spell execution details
• Gas costs

For current information, consult:

• Sky Governance Portal
• GitHub - spells-mainnet
• Sky Forum - Governance Discussions
• Sky Atlas

Sources

1. Sky Atlas A.1.9.2.1.7 - Spell Definition
2. Sky Atlas A.1.9.5 - Emergency Spells
3. Sky Atlas A.1.9.2.1.10 - Spell Team
4. Sky Atlas A.1.9.2.1.11 - Spell Crafter
5. Sky Atlas A.1.9.2.1.12 - Spell Reviewer
6. Sky Atlas A.1.9.3.1 - GSM Pause Delay
7. Sky Atlas A.1.9.5.2 - Standby Spells
8. Sky Atlas A.1.9.5.3 - Protego
9. Sky Atlas A.1.9.2.3.2.2 - Prime Spells
10. Sky Atlas A.1.9.2.4.13.4.1 - Casting of Spell
11. Sky Atlas A.1.9.2.4.13.4.2 - Execution of Spell
12. Sky Atlas A.1.9.2.4.13.2.1 - Chief Keeper
13. Sky Atlas A.1.9.5.1 - Emergency Spells Definition
14. Spell - Detailed Documentation
15. Governance Module Documentation
16. Chief - Detailed Documentation
17. Pause - Detailed Documentation
18. DSChief 1.2 - Technical Documentation
19. GitHub - spells-mainnet Repository
20. GitHub - dss-exec-lib Library
21. GitHub - dss-emergency-spells
22. GitHub - PE Checklists (Spell Crafter Workflow)
23. GitHub - chief-keeper
24. GitHub - dss-darkspell
25. The Governance Security Module (GSM) - MakerDAO Blog
26. Executive Vote: Activate the Governance Security Module
27. Maker DsChief 1.2 Governance Security Update
28. Executive Vote: Mitigating Flash Loan Risk - MakerDAO Blog
29. MIP15: Dark Spell Mechanism
30. Flash Loans and Securing the Maker Protocol - Forum Discussion
31. Governance Security Module (GSM) Adjustment - Forum
32. Dark Fix Mechanism Proposal - Forum
33. MakerDAO March 2023 Governance Crisis - Forum
34. MakerDAO Members Voting on Safeguard Against Flash Loan Attack - CoinDesk
35. Flash Loans Have Made Their Way to Manipulating Protocol Elections - CoinDesk
36. MakerDAO Issues Warning After Flash Loan Used to Pass Governance Vote - The Block
37. MakerDAO Zero-Bid Liquidations Report - CoinDesk
38. Black Thursday for MakerDAO - Decrypt
39. WBTC Spells Bug - March 2021 Incident
40. ChainSecurity MakerDAO Audits
41. Trail of Bits MakerDAO Security Reviews
42. MakerDAO Bug Bounty - Immunefi
43. Deep Dive into MakerDAO Spell Tests - dewiz
44. MakerDAO Auditing Executive Spells Guide
45. Parameter - Pause Delay Documentation
46. Sky Governance Portal - Executive Votes
47. Etherscan - DSChief 1.2 Contract
48. Etherscan - dss-exec-lib Contract
49. Etherscan - Protego Contract
50. Dune Analytics - MakerDAO Governance
51. MKR-to-SKY Upgrade Phase One - May 2025