Confidence: 88% ·Jan 11, 2026

Executive Votes

Executive Votes represent the binding governance mechanism through which Sky Protocol (formerly MakerDAO) implements changes to its smart contract infrastructure, risk parameters, and operational policies. Unlike Governance Polls which serve as non-binding signal votes to gauge community sentiment, Executive Votes directly modify the protocol's code through the execution of smart contract "spells" that alter system behavior once approved by token holders. [1] These votes constitute the final step in Sky's multi-stage governance process, translating community consensus into concrete protocol modifications that affect billions of dollars in decentralized stablecoin infrastructure.

Since the protocol's inception in December 2017, Executive Votes have served as the primary mechanism for implementing everything from minor parameter adjustments (stability fee changes, debt ceiling modifications) to major protocol upgrades (multi-collateral DAI launch, Sky rebrand, token migrations). [2] The executive voting system operates through continuous approval voting in the DSChief smart contract, where voters maintain their support for executive proposals indefinitely rather than voting within fixed time windows—a design that ensures the protocol always operates under the most recently approved governance mandate while providing security against malicious proposals through sustained community oversight. [3]

As of January 2026, Executive Votes represent one of the most mature on-chain governance systems in decentralized finance, having processed hundreds of governance decisions across nearly eight years of operation without suffering a successful governance attack or unauthorized protocol modification. [4] The system has evolved significantly from its original implementation, incorporating security enhancements like the Governance Security Module (GSM) which imposes a time delay before executive changes take effect, giving the community time to detect and respond to potentially harmful proposals through emergency shutdown mechanisms. [5]

Fundamental Concepts

Definition and Purpose

Executive Votes serve as Sky Protocol's binding governance mechanism for implementing smart contract changes to the protocol infrastructure. When an Executive Vote passes, it executes technical modifications to the Maker Protocol's smart contracts, with each Executive Vote containing a proposed set of changes to be made on the protocol's on-chain infrastructure. [6] This distinguishes Executive Votes from Governance Polls, which measure community sentiment on potential proposals but do not directly alter protocol code.

The fundamental purpose of Executive Votes is to enable decentralized protocol governance while maintaining security and stability. The system must balance competing priorities: enabling token holders to implement changes quickly enough to respond to market conditions, while preventing malicious actors from exploiting the governance mechanism to steal funds or damage the protocol. [7]

Key Characteristics of Executive Votes

  • Binding Nature — Executive Votes directly modify smart contract state when executed, making them fundamentally different from signal votes or off-chain governance
  • Continuous Approval — Unlike time-bound voting systems, Executive Votes remain active indefinitely until superseded by a new executive with greater support
  • Smart Contract Execution — Each executive vote encodes a "spell" smart contract containing the specific technical changes to be implemented
  • Irreversibility — Once executed (after the GSM delay expires), executive changes cannot be undone except through subsequent executive votes implementing counter-changes
  • Weighted Voting — Voting power is proportional to locked governance tokens (SKY/MKR), not one-address-one-vote

Executive Votes vs. Governance Polls

Sky Protocol's governance architecture distinguishes between two primary voting types that serve complementary but distinct functions in the decision-making process.

  • Governance Polls — Measure the sentiment of token voters and are used to gauge opinion on potential Executive Vote proposals and determine which values certain system parameters should be set to before those values are confirmed in an executive vote. [8] These polls establish community consensus on important goals and targets, forming the basis for subsequent binding actions. Governance Polls are essentially signaling votes that inform future decisions rather than directly implementing changes.

  • Executive Votes — Execute technical changes to the Maker Protocol, altering the code of the protocol itself. [9] This includes adding new collateral types, adding or adjusting system modules, and modifying system parameters such as Stability Fees and the Dai Savings Rate (now Sky Savings Rate). Executive Votes represent binding actions that directly modify protocol smart contracts.

Process Flow

  1. Community discussion identifies potential protocol change
  2. Governance Poll measures sentiment on the proposed direction
  3. Poll results inform the specific parameters for implementation
  4. Executive Vote contains the technical implementation of the poll-approved changes
  5. If the Executive Vote passes, changes are implemented after the GSM delay

Example Workflow

  • Poll — "Should the Sky Savings Rate be increased?" (Answer: Yes, to 9.5%)
  • Executive Vote — Implements smart contract spell that sets SSR parameter to 9.5% [10]

This separation enables Sky governance to maintain democratic legitimacy (polls ensure community consensus before implementation) while preserving technical precision (executive votes contain audited smart contract code rather than natural language instructions subject to interpretation).

Continuous Approval Voting Mechanism

Executive Votes operate through continuous approval voting, a distinctive governance mechanism that differentiates Sky from most other blockchain protocols that use time-bound voting windows.

How Continuous Approval Works

In continuous approval voting, each voter selects which candidates (executive proposals) they approve of, with the top "most approved" candidate being elected as the active executive (called the "hat"). [11] Each voter can cast their full voting weight for one proposal at any time, and crucially, can move their approval from one proposal to another without needing to first withdraw support from the candidate being replaced. [12]

Technical Implementation

When users lock their governance tokens (SKY or MKR) into the DSChief governance contract, they receive voting power proportional to their locked tokens. [13] This voting power can be continuously assigned to any executive proposal address. The DSChief contract tracks which proposal has accumulated the most voting weight, designating it as the "hat" (the currently active executive spell).

Advantages of Continuous Approval

  1. No Voting Deadline Pressure — Governance decisions aren't rushed by arbitrary time limits, allowing thorough community evaluation
  2. Protection During Transitions — Voters can move support from one spell to another without creating a power vacuum where a less-approved candidate could temporarily gain control
  3. Always Operational — The protocol always operates under a legitimately approved executive spell rather than defaulting to unclear states between votes
  4. Sustained Legitimacy — Executives must maintain ongoing community support to remain active, not just win an initial vote

Disadvantages and Risks

  1. Participation Burden — Voters must continuously monitor governance to ensure their votes support current priorities rather than outdated proposals
  2. Coordination Challenges — Moving voting weight between proposals requires coordination among dispersed token holders
  3. Whale Influence — Large token holders can more easily maintain or shift the hat given their concentrated voting power
  4. Complexity — The mechanism is less intuitive than simple time-bound voting, potentially reducing participation

The continuous approval model reflects Sky Protocol's design philosophy of prioritizing security and sustained legitimacy over rapid governance execution.

Technical Architecture

DSChief Smart Contract

DSChief serves as the core governance smart contract that implements Sky Protocol's executive voting system through continuous approval voting mechanics. Originally developed as part of the dapphub contract library and later customized for MakerDAO's specific governance needs, DSChief has undergone multiple versions (DSChief 1.0, 1.2, and Chief V3 with the Sky upgrade) to enhance security and functionality. [14]

Core DSChief Functions

  1. lock(uint256 wad) — Locks the specified amount of governance tokens into the Chief contract, granting the user voting weight proportional to their locked amount
  2. free(uint256 wad) — Withdraws locked governance tokens, reducing the user's voting weight accordingly
  3. vote(address[] yays) — Assigns the user's voting weight to the specified executive proposal addresses (in the yays array)
  4. lift(address spell) — Checks whether the specified spell address has more approval weight than the current hat, and if so, promotes it to become the new active hat [15]

The Hat Mechanism

The "hat" represents the currently active executive spell—the proposal with the most accumulated voting weight. [16] When an executive spell becomes the hat, it gains the authority to execute its encoded changes to the protocol. The hat can be any address, whether a single-use contract like ds-spell, a multi-use contract, or theoretically even an individual's wallet address (though this would be highly unusual and risky).

The lift function is critical to the hat mechanism: even if a spell accumulates more voting weight than the current hat, it doesn't automatically become the new hat until someone calls lift() on it. [17] This design creates an important security property—spells must actively be lifted to the hat rather than automatically taking control when they surpass the current hat's voting weight.

Chief-Keeper System

To address the vulnerability where the hat might not reflect the spell with the most approval, Sky Protocol employs "chief-keeper" bots that continuously monitor which spell has the most approval and automatically call lift() to ensure the most-approved spell is always the hat. [18] This "guards" the hat by maximizing the barrier of entry to lift a spell to the hat, preventing scenarios where voters moving support from one spell to another create a temporary window when only a small amount of voting power is needed to lift a malicious hat.

Failure Modes

A major vulnerability in the continuous approval system occurs when people move votes from one spell to another, opening a gap when only a small amount of governance tokens is needed to lift a random spell to the hat. [19] If chief-keeper systems fail or experience delays, an attacker could potentially exploit this window to temporarily become the hat, though the GSM delay (discussed below) provides additional protection against such attacks causing immediate damage.

Governance Security Module (GSM)

The Governance Security Module implements a mandatory time delay between when an Executive Vote passes (becomes the hat) and when its changes can actually be executed on the protocol. This delay serves as a critical security mechanism that gives the community time to detect and respond to potentially malicious or erroneous executive proposals before they can harm the protocol. [20]

GSM Pause Delay Parameter

The GSM Pause Delay parameter sets the minimum amount of time after an executive vote has passed before changes will come into effect in the Sky Protocol. [21] Once an executive spell becomes the hat, the GSM Pause Delay must elapse before the changes within that executive spell can affect the protocol.

Historical GSM Delay Settings

  • Original Setting (2017-2023) — 16 hours
  • April 2023 Increase — Raised from 16 hours to 48 hours for enhanced security [22]
  • April 2024 Adjustment — Increased from 16 to 30 hours (though this may represent a different parameter given the 2023 48-hour setting)
  • September 2024 Reduction — Decreased from 30 hours to 16 hours during the Sky rebrand [23]
  • Current Setting (January 2026) — 16 hours

Rationale for Delay

The 16-hour delay provides sufficient time for several critical security responses:

  1. Community Detection — Community members and security monitors can identify malicious or buggy executive proposals that passed
  2. Emergency Response Coordination — If a harmful executive is detected, the community can coordinate an emergency response
  3. Emergency Shutdown Trigger — In extreme cases, emergency shutdown mechanisms can be activated before the malicious executive executes
  4. Cancel Spell Execution — Protego, a special contract introduced in the Sky era, allows Sky Governance to cancel the execution of planned governance actions that are awaiting the expiration of the GSM Pause Delay [24]

Exceptions to GSM Delay

The GSM Pause Delay does not apply to "cancel" spells—special executive proposals designed to cancel pending executives that are waiting out their GSM delay. [25] This exception ensures that the security mechanism doesn't prevent the community from protecting itself against detected threats.

Trade-offs

Longer GSM delays provide more security but reduce governance agility. The reduction from 48 hours (or 30 hours) to 16 hours in September 2024 reflected a governance decision to prioritize faster parameter adjustments during the Sky rebrand period, accepting slightly higher risk in exchange for operational flexibility. [26]

Executive Spell Smart Contracts

Executive Spells are specialized smart contracts that encode the specific technical changes to be implemented when an Executive Vote passes. Each spell is a purpose-built contract that, when executed as the hat after the GSM delay, makes precise modifications to Sky Protocol's smart contract infrastructure. [27]

Spell Structure

A typical executive spell contains:

  1. Description — Human-readable explanation of what the spell does
  2. Code Actions — Solidity functions that implement the proposed changes
  3. Target Contracts — References to the specific protocol contracts to be modified
  4. Parameter Values — Exact numerical values for any parameter changes
  5. Authorization Checks — Verification that the spell has proper authority to make changes

Single-Use vs. Multi-Use Spells

  • Single-Use Spells (ds-spell) — Most executive spells are single-use contracts designed to execute once and then become inactive. This prevents replay attacks where the same spell could be maliciously re-executed. [28]
  • Multi-Use Contracts — Some executive proposals use multi-use contracts that can be called multiple times, though this is less common for security reasons

Spell Creation Process

  1. Technical Design — Smart contract developers (currently teams like Sidestream and Dewiz) translate governance poll results into technical specifications [29]
  2. Spell Coding — Developers write Solidity code implementing the desired changes
  3. Internal Review — The spell undergoes review by the development team
  4. Community Review — The spell code is published to GitHub for community technical review
  5. Deployment — The spell is deployed to Ethereum mainnet
  6. Submission — Governance Facilitators submit the spell address to the voting portal

Example Spell Actions

Common spell operations include:

  • Parameter Adjustments — Changing stability fees, debt ceilings, liquidation ratios
  • Collateral Onboarding — Adding new collateral types with associated risk parameters
  • Module Upgrades — Deploying and authorizing new smart contract modules
  • Token Operations — Minting or transferring governance tokens, USDS, or other protocol tokens
  • Payments — Distributing funds to contributors, delegates, or service providers
  • Oracle Updates — Modifying price feed sources or oracle parameters

Security Considerations

Executive spells represent significant attack vectors:

  • Buggy Code — Errors in spell code could break protocol functionality
  • Malicious Logic — A spell could intentionally include harmful operations (fund theft, parameter manipulation)
  • Upgrade Risks — Spells that upgrade critical modules could introduce vulnerabilities
  • Authorization Exploits — Spells that grant inappropriate authorizations could enable future attacks

To mitigate these risks, spell code is published open-source for community review, and the GSM delay provides time to detect issues before execution.

Office Hours Modifier

Executive proposals include an office-hours modifier that restricts when spells can be executed, providing an additional security layer by ensuring that spell execution occurs when development teams and community members are most available to respond to any issues. [30]

Office Hours Window

Executive spells can only be executed between 14:00 and 21:00 UTC, Monday through Friday. [31] This seven-hour window on business days ensures that:

  • Core development teams are available to monitor execution
  • Community members across global time zones can observe and respond
  • Emergency response coordination is feasible if issues arise
  • Weekend execution (when many team members are offline) is prevented

Expiration Mechanism

If an executive proposal does not pass within 30 days, it expires and can no longer have any effect on the Sky Protocol. [32] This expiration mechanism prevents outdated or superseded proposals from lingering indefinitely and potentially being executed out of context.

Rationale

The office hours restriction balances security and operational efficiency. While it means urgent parameter changes cannot be executed on weekends or outside the UTC afternoon window, it significantly reduces the risk that buggy or malicious spells execute when responders are unavailable. Given that most parameter changes are planned in advance rather than emergency responses, this trade-off favors security.

Executive Vote Lifecycle

Proposal Creation and Review

The journey of an Executive Vote begins long before it appears on the governance portal, following a structured process that translates community needs into technically precise smart contract implementations.

Stage 1: Problem Identification

Executive Votes typically originate from:

  • Risk Parameter Analysis — Risk teams identifying needed adjustments to collateral parameters based on market conditions
  • Protocol Upgrades — Core development teams proposing new features or improvements
  • Community Requests — Forum discussions identifying desired protocol changes
  • Emergency Response — Urgent issues requiring rapid parameter changes
  • Routine Operations — Regular monthly operations like delegate compensation, development funding

Stage 2: Governance Poll (Usually)

For most non-emergency changes, the proposal first goes through a Governance Poll to measure community sentiment. [33] The poll establishes:

  • Whether the community supports the change direction
  • Specific parameter values to implement (if multiple options exist)
  • Priority and timing for implementation

Polls typically run for one week and require simple majority support to guide subsequent executive action.

Stage 3: Technical Specification

Once poll results validate community support, technical teams translate the poll outcomes into precise specifications:

  • Exact parameter values to be changed
  • Specific smart contract functions to be called
  • Target contract addresses
  • Execution order for multiple operations
  • Edge case handling

Stage 4: Spell Development

Smart contract developers (Governance Facilitators Sidestream and Dewiz for Sky Protocol) write the executable spell code. [34] This involves:

  • Writing Solidity code implementing the approved changes
  • Including safety checks and validation logic
  • Adding descriptive comments explaining each operation
  • Structuring the spell for single-use execution
  • Ensuring proper authorization mechanisms

Stage 5: Internal Review and Testing

Before public deployment, spells undergo:

  • Internal code review by development team members
  • Testing on local development networks
  • Testing on Ethereum testnets (Goerli, Sepolia)
  • Simulation of execution against mainnet state
  • Verification that spell achieves intended outcomes

Stage 6: Public Review Period

Spell code is published to GitHub repositories for community technical review. [35] Community members, particularly technical delegates and security researchers, examine:

  • Whether the spell accurately implements poll results
  • Potential bugs or unintended consequences
  • Security vulnerabilities
  • Gas efficiency concerns

This review period typically lasts several days before the spell is submitted to the voting portal.

Stage 7: Submission to Governance Portal

Governance Facilitators deploy the spell contract to Ethereum mainnet and submit it to the governance portal at vote.sky.money. [36] The submission includes:

  • Spell smart contract address
  • Human-readable description of changes
  • Links to relevant governance polls and forum discussions
  • Technical documentation and code review links
  • Expected execution timeline

Voting Process

Once an Executive Vote appears on the governance portal, SKY token holders can participate in the voting process through several methods, with their voting power proportional to their locked governance tokens.

Voting Mechanisms

  1. Direct Voting via Governance Portal

    • Users connect Web3 wallets (MetaMask, WalletConnect, etc.) to vote.sky.money
    • Lock SKY tokens into the Chief V3 governance contract
    • Select the executive proposal to support
    • Submit voting transaction (gas cost: ~150,000-300,000 gas depending on prior voting state)
    • Voting weight immediately applies to the selected proposal

  2. Voting Through LockStake Engine

    • Users who stake SKY in the LockStake Engine automatically receive voting power through LSSKY tokens [37]
    • Can vote directly with their staked positions
    • Alternatively, can delegate voting power to Aligned Delegates who vote on their behalf [38]
    • Voting power remains active while tokens earn staking rewards

  3. Delegate Voting

    • Users assign voting power to recognized Aligned Delegates
    • Delegates cast votes based on their announced voting policies
    • Users retain token custody while delegates exercise voting rights
    • Delegation can be changed at any time without unstaking

Voting Weight Calculation

Voting power is directly proportional to locked governance tokens:

  • 10,000 SKY locked = 10,000 units of voting power
  • 1,000,000 SKY locked = 1,000,000 units of voting power

For users who stake SKY in the LockStake Engine, their voting power is calculated from their LSSKY balance (internal accounting token representing staked SKY). [39]

Vote Tracking

The DSChief smart contract continuously tracks:

  • Total voting weight assigned to each executive proposal
  • Which proposal currently has the most support (the "hat")
  • Each voter's current vote allocation
  • Historical vote changes (viewable on Etherscan)

Changing Votes

Voters can change their support from one executive to another at any time:

  • No withdrawal or cooldown period required
  • New vote allocation takes effect immediately upon transaction confirmation
  • Previous vote weight is automatically removed from old proposal and assigned to new proposal
  • This enables voters to shift support as circumstances change without creating power vacuums

Vote Privacy

All votes are completely transparent and publicly viewable on-chain. [40] Any observer can see:

  • Which addresses voted for which proposals
  • How much voting weight each voter assigned
  • When votes were cast or changed
  • Delegate voting patterns

This transparency enables community accountability but provides no vote privacy.

Passing Threshold and Hat Mechanism

Unlike many governance systems that require a fixed percentage of total voting power or a minimum quorum, Sky's Executive Votes operate on a continuous approval model where the proposal with the most accumulated voting weight becomes the active executive (the "hat").

How a Spell Becomes the Hat

  1. Vote Accumulation — An executive spell accumulates voting weight as token holders assign their locked tokens to support it
  2. Surpassing Current Hat — The spell must accumulate more voting weight than the currently active hat
  3. Lift Function Call — Someone must call the lift() function on the DSChief contract, specifying the spell's address [41]
  4. Hat Transfer — If the spell indeed has more voting weight than the current hat, the lift() function promotes it to become the new hat

No Minimum Threshold

Critically, there is no absolute minimum voting weight required for a spell to become the hat—it only needs to have MORE weight than any competing proposal. [42] This means:

  • In a scenario where multiple proposals split the vote, a spell could become hat with minority support
  • If most voters are inactive, a spell could become hat with very little absolute voting weight
  • The continuous approval model assumes sustained active participation

Chief-Keeper Protection

To prevent malicious spells from exploiting vote-shifting windows, automated "chief-keeper" bots monitor voting weights and automatically call lift() on the most-approved spell. [43] These keepers:

  • Continuously monitor all active executive proposals
  • Detect when a spell accumulates more weight than the current hat
  • Call lift() to ensure the most-approved spell is always the hat
  • Maximize the barrier of entry for malicious spells

Without chief-keepers, an attack scenario could occur where voters moving support from spell A to spell B create a temporary window when a malicious spell C (with very little voting weight) could be lifted to the hat during the transition.

Hat Authority

Once a spell becomes the hat, it gains authority to:

  • Wait out the GSM delay period
  • Execute its encoded changes after the delay expires (within office hours)
  • Remain active until superseded by a new hat with greater support

The hat doesn't execute immediately—it must wait the GSM delay period, providing time for community review and potential emergency response.

GSM Delay Period

After an executive spell becomes the hat, it enters the Governance Security Module delay period before it can execute its changes. This mandatory waiting period serves as the protocol's primary defense against malicious or buggy governance proposals.

16-Hour Waiting Period

As of January 2026, the GSM Pause Delay is set to 16 hours. [44] During this period:

  • The spell has been approved and is the active hat
  • No changes have yet been made to the protocol
  • The community can review the spell code and detect issues
  • Emergency response mechanisms can be triggered if needed

Timeline Example

  • T+0 hours — Executive spell becomes the hat (most voting weight)
  • T+0 to T+16 — GSM delay period - spell cannot execute
  • T+16 hours — Spell becomes eligible for execution (within office hours)
  • T+16 to T+30 — If not executed within 30 days, spell expires

What Can Happen During GSM Delay

  1. Normal Path — Community reviews spell, finds no issues, spell executes after delay
  2. Issue Detection — Community identifies bug or malicious code, coordinates response
  3. Vote Shift — Token holders move votes to a different spell, removing hat status from problematic proposal
  4. Cancel Spell — A special "cancel" spell (not subject to GSM delay) is voted in to cancel the pending executive [45]
  5. Emergency Shutdown — In extreme cases, Emergency Shutdown can be triggered to freeze the protocol

Protego Contract

Protego is a contract that allows Sky Governance to cancel the execution of planned governance actions that are awaiting the expiration of the Governance Security Module Pause Delay. [46] This provides an additional safety mechanism beyond simply shifting votes to a different hat.

Security Trade-offs

The 16-hour delay balances:

  • Security — Time to detect and respond to threats
  • Agility — Ability to implement urgent parameter changes quickly

Sky governance has adjusted this parameter multiple times, reflecting ongoing evaluation of the appropriate balance. The September 2024 reduction from 30 hours (or 48 hours) to 16 hours prioritized faster governance execution during the rebrand period. [47]

Execution and Implementation

Once the GSM delay expires, the executive spell can be executed to implement its encoded changes to the protocol. Execution is the final step where the spell's smart contract code runs and modifies the protocol's on-chain state.

Execution Requirements

For a spell to successfully execute:

  1. Must be the current hat (have the most voting weight)
  2. GSM delay period must have fully elapsed (16+ hours since becoming hat)
  3. Current time must fall within office hours (14:00-21:00 UTC, Monday-Friday) [48]
  4. Spell must not have expired (more than 30 days since submission) [49]
  5. All prerequisite conditions in the spell code must be satisfied

Who Can Execute

Technically, anyone can call the execution function on an eligible executive spell. [50] In practice:

  • Governance Facilitator teams typically execute spells shortly after they become eligible
  • Automated keeper bots may execute spells
  • Community members can execute if facilitators are unavailable
  • The spell contract address itself doesn't execute automatically—it requires an external call

Execution Process

  1. Eligibility Check — Verify spell meets all execution requirements
  2. Transaction Submission — Someone submits an Ethereum transaction calling the spell's execute() function
  3. Gas Payment — The transaction sender pays gas fees (typically 200,000-500,000+ gas depending on spell complexity)
  4. Spell Execution — The spell's code runs, making specified changes to protocol contracts
  5. State Changes — Protocol parameters, authorizations, or configurations are modified
  6. Event Emission — Execution events are emitted for transparency and monitoring
  7. Completion — Spell completes and protocol operates under new parameters

Example Spell Execution Actions

A typical executive spell might:

// Pseudo-code example of spell actions
function execute() external {
    // Change Sky Savings Rate to 9.5%
    vat.file("jug", "duty", 1000000002928425427456671891); // 9.5% APY

    // Increase debt ceiling for ETH-A vault
    vat.file("ETH-A", "line", 1000000000 * RAD); // 1 billion USDS ceiling

    // Pay delegate compensation
    treasury.transfer(delegate1_address, 50000 * USDS);
    treasury.transfer(delegate2_address, 75000 * USDS);

    // Update oracle addresses
    oracle.setSource("ETH-USD", new_oracle_address);
}

Monitoring and Verification

After execution:

  • Community members verify that changes were correctly implemented
  • Protocol monitoring tools check for unexpected behavior
  • Risk teams confirm new parameters are functioning as intended
  • If issues are discovered, a new executive spell can be proposed to correct problems

Irreversibility

Once executed, spell changes cannot be directly undone—they can only be reversed through subsequent executive votes that implement counter-changes. [51] This irreversibility emphasizes the importance of the review period and GSM delay.

Governance Participation

Voting Requirements

Participating in Executive Votes requires SKY token holders to lock their tokens in the governance contract, creating voting power proportional to their locked balance while forfeiting liquidity during the voting period.

Technical Requirements

  1. SKY Token Ownership — Users must hold SKY tokens (or legacy MKR tokens that can be upgraded) on Ethereum mainnet
  2. Token Locking — Tokens must be locked in the Chief V3 governance contract to activate voting power [52]
  3. Web3 Wallet — Compatible wallet (MetaMask, WalletConnect, Ledger, Trezor, etc.) to interact with governance contracts
  4. ETH for Gas — Sufficient ETH to pay transaction fees for locking tokens and casting votes (typical cost: $5-50 depending on network congestion)
  5. Network Access — Connection to Ethereum mainnet through an RPC provider

No Minimum Stake

Sky governance imposes no minimum SKY balance requirement to participate in voting. [53] However, practical considerations mean:

  • Very small holdings (< 100 SKY) have negligible impact on vote outcomes
  • Gas costs may exceed the governance value of voting for small holders
  • Rational participation typically requires holdings sufficient to justify transaction costs

Voting Power Calculation

Voting power is exactly proportional to locked SKY:

  • 1,000 SKY locked = 1,000 voting weight
  • 1,000,000 SKY locked = 1,000,000 voting weight
  • No quadratic or other non-linear weighting

Lock Duration

Tokens can be locked indefinitely or unlocked at any time. [54] There is:

  • No minimum lock period
  • No penalty for early withdrawal
  • Immediate voting power loss upon unlocking
  • No cooldown period to re-lock tokens

Staking Integration

Users who stake SKY in the LockStake Engine automatically receive voting power through LSSKY tokens without needing to separately lock tokens in the governance contract. [55] This integration enables:

  • Simultaneous earning of staking rewards and governance participation
  • More capital-efficient governance participation
  • Delegation of voting power while maintaining token custody and rewards

Delegation Options

Sky Protocol's delegation system enables token holders to assign their voting power to recognized Aligned Delegates who vote on their behalf, addressing the challenge that most token holders lack the time or expertise to evaluate every governance proposal.

How Delegation Works

When a user delegates their voting power:

  1. They maintain full custody of their SKY tokens (tokens remain in their wallet or staking position)
  2. Voting rights transfer to the delegate's address
  3. The delegate can vote with the combined voting power of all delegators plus their own holdings
  4. Delegators continue earning staking rewards if tokens are staked [56]
  5. Delegation can be changed or revoked at any time without penalty

Delegation Methods

Through LockStake Engine:

  • Users who stake SKY can call selectVoteDelegate() function on their urn (staking position)
  • Specify the Aligned Delegate contract address to receive voting power
  • Delegation persists until changed or position is unstaked [57]

Through Chief V3 Directly:

  • Users can deploy a personal vote delegate contract
  • Lock tokens and delegate to their contract
  • Configure the contract to follow a specific Aligned Delegate's votes

Aligned Delegate Program

The Sky Atlas maintains an official list of Recognized Aligned Delegates who meet operational security standards and communication requirements. [58] Aligned Delegates:

  • Receive compensation from the protocol treasury for their governance work
  • Must publicly explain their voting rationale in forum posts
  • Meet minimum operational security requirements (multisig wallets, key management)
  • Can be offboarded through governance vote if they violate community standards
  • Undergo periodic performance evaluation

Current Delegate Compensation (January 2026)

Aligned Delegates receive monthly compensation based on their tier:

  • Tier 1 Delegates — Higher compensation for larger voting weight and more active participation
  • Tier 2 Delegates — Moderate compensation for mid-tier participation
  • Tier 3 Delegates — Base compensation for meeting minimum requirements

Exact amounts are adjusted through monthly executive votes. [59]

Split Delegation

Users with multiple staking positions (urns) can split voting power across different delegates:

  • Urn 1 delegates to Aligned Delegate A
  • Urn 2 delegates to Aligned Delegate B
  • Urn 3 retains voting power for direct voting

This enables sophisticated portfolio governance strategies. [60]

Revocation

Delegators can instantly revoke delegation by:

  • Calling selectVoteDelegate() with a different delegate address
  • Calling selectVoteDelegate() with null address (0x0) to undelegate
  • Unstaking tokens (which automatically removes delegation)

No notice period or cooldown applies to delegation changes.

Participation Statistics

Governance participation in Sky Protocol demonstrates concerning concentration and relatively low overall engagement, raising questions about the decentralization and legitimacy of governance outcomes.

Voting Power Distribution (January 2026)

Based on recent governance votes, approximately:

  • Active Voting Participation — ~26% of circulating SKY supply participates in governance [61]
  • Staked Percentage — ~46-50% of supply is staked in the LockStake Engine [62]
  • Staked but Not Voting — ~20-24% of supply is staked for rewards but not used for governance

The November 2025 governance vote approving the transition to SKY rewards saw approximately 6 billion SKY participate out of 23 billion circulating supply (26% turnout). [63]

Delegate Concentration

Voting power exhibits significant concentration among top delegates:

  • In November 2024 brand vote, just 4 entities controlled ~80% of voting power (largest: 51.3%, second: 16.7%, third: 7.2%, fourth: 4.9%) [64]
  • Top 5 Aligned Delegates likely control 40-50% of delegated voting power
  • Top 10 Aligned Delegates likely control 60-70% of delegated voting power
  • Remaining delegates and direct voters split the balance

Executive Vote Passage Times

Recent executive votes typically pass within:

  • Routine Operations — 1-3 days (monthly compensation, standard parameter changes)
  • Significant Changes — 3-7 days (major protocol upgrades, controversial proposals)
  • Emergency Votes — < 24 hours (urgent security or market response)

Historical Comparison

Participation has evolved over time:

  • 2018-2019 (MKR era) — Lower absolute participation but higher percentage of circulating supply
  • 2020-2021 (Multi-Collateral DAI) — Increased participation during protocol expansion
  • 2022-2023 (Pre-rebrand) — Stable participation with delegate system maturation
  • 2024-2025 (Sky rebrand) — Increased absolute participation as staking launched, but still only ~26% of supply

Barriers to Participation

Several factors limit broader governance engagement:

  • Complexity — The Sky Atlas exceeds 3,000 pages, creating insurmountable barriers for casual participants [65]
  • Time Requirements — Evaluating technical proposals requires hours of research per vote
  • Gas Costs — Voting transactions cost $5-20 in gas fees, economically excluding small holders
  • Technical Barriers — Understanding smart contract code requires programming expertise
  • Coordination Difficulty — Individual small holders struggle to coordinate voting against large entities

These statistics suggest that while Sky governance operates as designed, effective decision-making power is concentrated among a relatively small group of large token holders and active delegates.

Historical Executive Votes

Notable Examples

Throughout Sky Protocol's eight-year history (including its MakerDAO era), several executive votes stand out as particularly significant for their impact on the protocol or the broader DeFi ecosystem.

Black Thursday Response (March 2020)

On March 12, 2020, ETH's price fell 43% from $194 to $111 in a single day, triggering a cascade of liquidations in the MakerDAO system. [66] A shortage of auction keepers allowed one actor to purchase approximately $6 million worth of ETH for just 1 DAI, leaving $4.5 million worth of DAI unbacked by collateral. [67]

The emergency response involved multiple executive votes over a two-week period:

  • Increased maximum auction lot size from 50 to 500 ETH [68]
  • Extended auction duration to allow more participation
  • Adjusted debt auction parameters
  • Later, a compensation vote (65% of voters selected "0% compensation" for affected vault owners) [69]

The community vetoed an Emergency Shutdown in favor of these less drastic measures. [70] This crisis demonstrated both the protocol's resilience and its governance system's ability to coordinate rapid responses under extreme stress.

Multi-Collateral DAI Launch (November 2019)

The executive vote enabling Multi-Collateral DAI (MCD) represented one of the largest protocol upgrades in DeFi history, transforming MakerDAO from a single-collateral system (ETH only) to supporting multiple collateral types. [71] This upgrade:

  • Deployed entirely new smart contract infrastructure
  • Migrated existing single-collateral DAI positions to the new system
  • Enabled the protocol to scale to support dozens of collateral types
  • Established the foundation for RWA integration and protocol expansion

Sky Rebrand and Token Launch (September 2024)

The September 13, 2024 executive vote initialized USDS, sUSDS, and SKY tokens, launching the Sky Protocol rebrand and transforming the protocol's tokenomics. [72] This vote:

  • Deployed new token contracts for USDS (rebranded DAI), sUSDS (savings token), and SKY (24,000:1 upgraded MKR)
  • Initialized the Smart Burn Engine (SBE) upgrade
  • Set up SKY staking rewards systems
  • Established USDS-SKY farming mechanisms

The vote passed and executed, marking MakerDAO's transformation into Sky Protocol.

MKR-to-SKY Governance Transition (May 2025)

The May 15, 2025 executive vote executed Phase One of the MKR-to-SKY governance upgrade, fundamentally changing the protocol's governance token. [73] After this spell passed on May 19, 2025:

  • SKY became the sole decision-making token
  • MKR voting power was disabled
  • All governance actions routed through SKY token
  • DSChief and Delegate V2 contracts stopped accruing voting weight for MKR [74]

This represented one of the most significant governance transitions in DeFi history—changing the core governance token of a multi-billion dollar protocol while maintaining continuous operation.

SKY Staking Rewards Transition (November 2025)

The November 3, 2025 executive vote restructured staking economics by transitioning from USDS to SKY-denominated rewards. [75] The vote:

  • Directed 500 million SKY from Sky Frontier Foundation to the treasury for reward distribution
  • Tripled daily SKY buybacks from 100,000 to 300,000 USDS
  • Established a 90-day transition period for users to migrate reward positions
  • Passed with 5,970,568,963 SKY voting power (26% of circulating supply) [76]

This dramatically altered the protocol's tokenomics by redirecting 200,000 USDS per day from staking rewards to buyback operations, accelerating deflationary pressure.

Emergency Responses

Sky Protocol's governance system has faced several emergency scenarios requiring rapid executive vote responses to address immediate threats or market dislocations.

Black Thursday Liquidation Crisis (March 12-13, 2020)

The most dramatic emergency response in protocol history occurred during the March 2020 crypto market crash. On an open emergency governance call held that Thursday, the community debated whether Emergency Shutdown would be necessary. [77]

The emergency response strategy involved:

  • Immediate parameter adjustments through executive votes
  • Coordination across global community members during crisis conditions
  • Multiple governance votes executed within days rather than weeks
  • Risk-based prioritization of which changes were most urgent

The community deployed a strategy that played out over two weeks involving multiple governance token votes to stabilize the system without triggering Emergency Shutdown. [78]

Out-of-Schedule Risk Parameter Vote (February 18, 2025)

This accelerated proposal prepared the protocol for potential excessive DAI demand shock caused by bullish market sentiment and volatility. [79] The out-of-schedule executive vote:

  • Adjusted risk parameters outside the normal monthly schedule
  • Responded to rapid market movements requiring immediate parameter changes
  • Demonstrated the protocol's ability to execute governance quickly when circumstances demand
  • Confirmed that the protocol was working as expected and maintaining stability [80]

Governance Security Module Adjustments

Several executive votes have emergency-adjusted the GSM delay parameter itself:

  • April 2023: Increased from 16 to 48 hours in response to governance security concerns [81]
  • September 2024: Reduced to 16 hours to enable faster execution during rebrand period [82]

These adjustments reflect the protocol's ongoing calibration of security versus agility based on current threat landscapes.

Emergency Spell Cancellation (Protego)

While not yet extensively tested in practice, the Protego contract provides a mechanism for emergency cancellation of pending executives that are in their GSM delay period. [83] This capability enables:

  • Rapid response to discovered bugs in pending executives
  • Cancellation of potentially malicious spells before they execute
  • Community protection without requiring Emergency Shutdown

The presence of this emergency mechanism, even if rarely used, provides important guardrails for the governance system.

Challenges and Criticisms

Voter Apathy and Low Participation

Despite managing billions of dollars in protocol value, Sky Protocol governance suffers from persistently low participation rates that raise concerns about democratic legitimacy and capture risks.

Quantitative Evidence

Only 26% of circulating SKY supply actively participates in governance as of January 2026. [84] This means governance decisions affecting all token holders—including major protocol changes, risk parameters, and treasury allocations—are made by roughly one-quarter of the token supply.

Even more concerning, approximately 46-50% of SKY is staked in the LockStake Engine (primarily for yield generation), but only about half of staked SKY is actively used for voting. [85] This suggests many stakers view SKY purely as a yield-generating asset rather than a governance responsibility, participating in staking rewards without exercising voting rights.

Root Causes

  1. Complexity Barrier — The Sky Atlas exceeds 3,000 pages of technical documentation. [86] Understanding governance proposals requires:

    • Deep technical knowledge of smart contract architecture
    • Familiarity with DeFi risk management principles
    • Time to read lengthy forum discussions and technical specifications
    • Ability to evaluate Solidity code (for technical proposals)

  2. Rational Ignorance — For most small holders, the cost of becoming informed exceeds the expected benefit of their marginal voting power. A holder with 10,000 SKY (< 0.05% of supply) has essentially zero probability of affecting governance outcomes, making time investment irrational from a personal cost-benefit perspective.

  3. Gas Cost Economics — Voting transactions cost $5-20 in gas fees during normal network conditions, and significantly more during congestion. For holders with < $1,000 in SKY, voting costs can exceed 1-2% of portfolio value, economically excluding smaller participants.

  4. Free Rider Problem — Governance is a public good—all token holders benefit from good governance regardless of whether they participate. This creates incentives to free-ride on others' governance efforts rather than investing personal time and gas costs.

  5. Coordination Difficulty — Small holders face collective action problems: even if they agree on desired outcomes, coordinating voting is difficult without formal organization, allowing concentrated interests to dominate.

Consequences

  • Reduced Legitimacy — Governance decisions made by 26% of supply have weaker claim to representing "community consensus"
  • Capture Risk — Low participation enables small groups of coordinated actors to control outcomes
  • Suboptimal Decisions — Limited participation means less diverse perspectives informing governance
  • Emergency Vulnerability — Low participation in routine votes could mean insufficient voting power mobilizes for emergency responses

Potential Mitigations

  • Gasless Voting — Implementing off-chain signature-based voting (like Snapshot) for signal votes, reserving gas-intensive on-chain voting only for final executive spells
  • Simplified Summaries — Professional synthesis of complex proposals into accessible summaries
  • Participation Incentives — Small rewards for voting participation (though this creates new complexities)
  • Improved UI/UX — Better interfaces that reduce friction and increase accessibility
  • Education Programs — Resources to help token holders understand governance

However, each solution carries trade-offs and implementation challenges, and none have been adopted as of January 2026.

Whale Dominance

The concentration of voting power among large token holders (whales) creates governance dynamics that diverge from the democratic ideal of broad community participation, raising concerns about whose interests Sky Protocol truly serves.

Concentration Evidence

Recent governance votes reveal extreme concentration:

  • November 2024 brand vote: 4 entities controlled ~80% of voting power, with the single largest controlling 51.3% [87]
  • Top 5 Aligned Delegates likely control 40-50% of delegated voting power
  • Top 10 Aligned Delegates likely control 60-70% of delegated voting power

This concentration means a small number of actors—potentially fewer than 10—effectively control governance outcomes for a protocol managing billions of dollars.

Mechanisms of Concentration

  1. Initial Distribution — The original MKR token distribution concentrated holdings among early investors and the founding team, which persists through the MKR-to-SKY upgrade (though diluted by 24,000:1 conversion)

  2. Delegation Aggregation — The Aligned Delegate system, while improving participation by enabling specialization, concentrates power among professional delegates who control not only their own holdings but thousands of delegators' voting power

  3. Staking Economics — Wealthier holders can more easily stake large amounts, earning rewards and voting power simultaneously, while smaller holders may need to sell tokens for liquidity

  4. Exchange Custody — Centralized exchanges holding customer SKY in custody wallets could exercise massive voting power without customer consent if they offered custody staking services (though major exchanges have generally avoided this in MakerDAO/Sky)

Problematic Outcomes

  1. Minority Control — Decisions affecting all token holders are made by entities holding or controlling a small fraction of supply
  2. Divergent Interests — Large holders' interests may diverge from smaller holders (e.g., preferring protocol complexity that raises barriers to competition vs. simplicity that enables broader participation)
  3. Capture Risk — External entities could potentially purchase or borrow enough SKY to control governance, especially during periods of low participation
  4. Reduced Credible Neutrality — Governance decisions that benefit large holders at smaller holders' expense undermine the protocol's neutrality claims

Defenses

Sky Protocol implements several mechanisms that partially mitigate whale dominance:

  • Transparent Voting — All votes are on-chain and public, enabling community oversight [88]
  • Delegation Revocability — Delegators can instantly change delegates if they disagree with voting behavior
  • Forum Communication — Aligned Delegates must publicly explain voting rationale, creating accountability
  • Multiple Delegates — Competition among delegates prevents single-point control (though top delegates still dominate)

Comparison to Traditional Governance

Plutocratic voting (power proportional to stake) is arguably more appropriate for protocols where voters have "skin in the game" than for public democracies. Large SKY holders have more to lose from bad governance decisions than small holders, potentially aligning incentives for sound decision-making.

However, this argument weakens when considering:

  • Delegates controlling others' tokens don't bear the same financial risk as the underlying token owners
  • Large holders may benefit from governance decisions (like high complexity) that harm the protocol's long-term competitiveness but entrench their position
  • Short-term large holders (who plan to exit) may support extractive governance that harms long-term value

The tension between plutocracy (power to those with most stake) and democracy (power to broad communities) remains unresolved in Sky Protocol governance.

Complexity and Accessibility

The technical complexity of Sky Protocol governance creates formidable barriers to participation that effectively exclude the vast majority of token holders from meaningful engagement in decision-making processes.

Dimensions of Complexity

  1. Documentation Volume:

    • The Sky Atlas exceeds 3,000 pages of technical specifications [89]
    • Understanding a single executive vote may require reading dozens of forum posts, technical specifications, and prior governance decisions
    • Governance polls and their discussions can span hundreds of forum comments
    • Smart contract code for executive spells requires Solidity expertise to evaluate

  2. Technical Prerequisites:

    • Understanding risk parameters requires knowledge of DeFi mechanics, collateralization ratios, liquidation dynamics
    • Evaluating collateral onboarding requires expertise in asset analysis, oracle security, smart contract risks
    • Assessing protocol upgrades requires understanding of Ethereum smart contract architecture
    • Economic proposals require grasp of tokenomics, market dynamics, and protocol revenue models

  3. Interdependencies:

    • Executive votes often bundle multiple changes together
    • Understanding one proposal may require knowledge of prior governance decisions
    • Changes interact with complex existing systems (MCD vaults, oracles, liquidation mechanisms)
    • Unintended consequences require systems-thinking to anticipate

  4. Jargon and Acronyms:

    • Governance discussions use protocol-specific terminology (VAT, JUG, SPOT, DOG, flap, flop, etc.)
    • Acronyms are rarely defined in governance posts (assuming reader familiarity)
    • Technical specifications use smart contract naming conventions that differ from natural language

Impact on Participation

This complexity creates several exclusionary effects:

  1. Time Barriers — Becoming sufficiently informed to vote responsibly requires hours or days of research per vote, which only professional delegates or deeply committed community members can afford

  2. Knowledge Barriers — Evaluating technical proposals requires specialized expertise that most token holders lack, even if they invest the time

  3. Intimidation — New participants may feel overwhelmed and avoid engagement rather than risk voting incorrectly or asking "stupid questions"

  4. Delegation Necessity — Complexity makes delegation essentially mandatory for most holders, concentrating power among delegates rather than distributing it broadly

Consequences

  • Most token holders rely entirely on delegates without understanding what they're voting for
  • Governance decisions lack broad legitimacy when most holders can't meaningfully evaluate proposals
  • Technical complexity serves as a moat protecting incumbent delegates and large holders from competition
  • Protocol evolution toward simplicity and accessibility faces resistance from those who benefit from complexity

Partial Mitigations

Some community efforts attempt to improve accessibility:

  • Governance Facilitators provide executive vote summaries
  • Aligned Delegates post explanations of their voting rationale
  • Community members create educational content explaining governance
  • Governance calls allow community Q&A

However, these mitigations only marginally reduce the fundamental accessibility challenge.

Design Tension

Complexity serves both legitimate and problematic purposes:

  • Legitimate — Managing a multi-billion dollar protocol requires sophisticated risk management, which inherently involves complexity
  • Problematic — Complexity can be used to obscure questionable decisions or exclude competitors from governance influence

Distinguishing necessary from artificial complexity remains an ongoing governance challenge.

Relationship to Other Governance Mechanisms

Integration with Governance Polls

Executive Votes and Governance Polls function as complementary components of Sky Protocol's two-stage governance process, with polls establishing community consensus before executives implement technical changes.

Typical Governance Flow

  1. Forum Discussion Phase

    • Community members identify potential protocol improvement
    • Informal discussion establishes rough consensus on problem and potential solutions
    • Technical experts evaluate feasibility and risks
    • Governance Facilitators determine if formal governance is appropriate

  2. Governance Poll Phase

    • Formal poll is created measuring sentiment on proposed change
    • Poll presents specific options (e.g., "Increase SSR to: 8%, 9%, 9.5%, 10%, No change")
    • Voting occurs over one week typically
    • Simple majority determines outcome [90]
    • Poll results provide mandate for subsequent executive vote

  3. Technical Implementation Phase

    • Smart contract developers translate poll results into executable code
    • Spell is drafted implementing the poll-approved parameters
    • Technical review ensures spell matches poll intent

  4. Executive Vote Phase

    • Executive spell is submitted to governance portal
    • Token holders vote to approve the technical implementation
    • If passed, changes execute after GSM delay

Why Two Stages?

The poll-then-executive structure serves several purposes:

  1. Democratic Legitimacy — Polls ensure community consensus exists before committing development resources to technical implementation
  2. Technical Precision — Separating policy decisions (polls) from implementation (executives) allows smart contract developers to focus on correct code rather than debating policy
  3. Flexibility — Polls can explore multiple options, while executives implement the winning option
  4. Error Reduction — Two-stage process provides multiple points for catching errors or reconsidering decisions

Executive Votes Without Prior Polls

Some executives proceed without prior polls:

  • Emergency Votes — Urgent responses to market conditions or security threats can't wait for one-week poll periods [91]
  • Routine Operations — Monthly delegate compensation and standard operational items follow established procedures without new polls
  • Technical Implementations — Pure technical changes without policy implications (bug fixes, optimizations) may skip polls

Potential for Disconnect

Occasionally, executive votes deviate from poll mandates:

  • Technical constraints may prevent exact implementation of poll results
  • Bundled executives may include changes not explicitly polled
  • Emergency situations may require deviating from normal processes

The community generally accepts small deviations when justified by technical necessity, but large divergences between polls and executives generate controversy and may fail to pass.

Interaction with Emergency Shutdown

Emergency Shutdown represents Sky Protocol's ultimate governance override mechanism—a way to freeze the protocol and allow orderly unwinding if catastrophic failure occurs or governance is irreparably compromised. Executive Votes interact with this emergency mechanism in critical ways.

Emergency Shutdown Module (ESM)

The ESM is a smart contract that can trigger protocol-wide shutdown if a threshold amount of governance tokens is deposited into it. [92] As of January 2026:

  • Threshold: 150,000 MKR or equivalent SKY (adjusted for 24,000:1 conversion)
  • Irreversible: Once triggered, shutdown cannot be cancelled
  • Purpose: Provides last-resort protection against governance attacks or catastrophic failures

How Emergency Shutdown Relates to Executive Votes

  1. Override Mechanism — Emergency Shutdown can halt a malicious executive vote before it executes if detected during the GSM delay period
  2. Governance Failure Response — If governance becomes irreparably compromised (captured by malicious actors), shutdown allows orderly exit rather than leaving users trapped in a hostile protocol
  3. Black Thursday Decision Point — During the March 2020 crisis, the community debated triggering shutdown but ultimately chose to address issues through executive votes instead [93]

Trigger Process

If community members detect an existential threat:

  1. Forum discussion coordinates response
  2. Token holders deposit SKY/MKR into ESM contract
  3. Once threshold is reached, shutdown triggers automatically
  4. All vaults freeze, allowing users to withdraw collateral proportional to outstanding debt
  5. No new executives can execute
  6. Protocol enters permanent wind-down mode

Trade-offs

Emergency Shutdown is a double-edged sword:

  • Protection — Prevents catastrophic losses from governance attacks
  • Risk — False alarms could shut down a functioning protocol unnecessarily
  • Finality — Shutdown is permanent—the protocol cannot be "restarted"
  • Coordination — Reaching threshold requires coordination among large holders willing to lock tokens permanently

Historical Near-Misses

Sky Protocol has faced scenarios where Emergency Shutdown was seriously considered:

  • Black Thursday (March 2020) — Community debated shutdown but chose executive votes instead [94]
  • Governance attacks (hypothetical) — Various theoretical attack scenarios could justify shutdown
  • Critical bugs — Discovery of fundamental protocol vulnerabilities might warrant shutdown

The fact that shutdown has never been triggered despite eight years of operation demonstrates either the protocol's robustness or the community's high threshold for invoking this nuclear option.

SubDAO and Stars Governance

Sky Protocol's evolution toward the Endgame architecture introduces "Stars" (rebranded from "SubDAOs")—semi-autonomous protocol divisions with their own governance systems that interact with the core Sky governance layer through executive votes. [95]

Stars Structure

As of January 2026, active Stars include:

  • Spark — Lending protocol offering decentralized borrowing and lending
  • Grove — Real-world asset (RWA) focused initiatives
  • Keel — Stablecoin primitives and allocation systems

Each Star has:

  • Its own governance token (SPK for Spark, Grove for Grove, etc.)
  • Operational autonomy for decisions within its scope
  • Dependency on core Sky governance for critical parameters and funding

Governance Interaction Model

  1. Star-Level Decisions: Stars can make autonomous governance decisions about:

    • Internal operational parameters
    • Risk parameters within delegated authority
    • Team hiring and resource allocation
    • Product development priorities

    These decisions use Star-specific governance mechanisms (SPK token voting for Spark, etc.).

  2. Core Sky Executive Votes for Stars: Certain Star activities require core Sky executive votes:

    • Initial Star deployment and authorization
    • Major parameter changes affecting Sky Protocol risk
    • Treasury allocations from Sky to Stars
    • Integration of Star products into core protocol

  3. Proxy Spells: Many executive votes include "proxy spells" that implement changes in Star protocols:

    • Sky executive votes often bundle "Spark Proxy Spell" or "Grove Proxy Spell" components
    • These proxy spells grant one-time authority to execute specific changes in Star contracts
    • Enables coordination between core protocol and Star governance [96]

Example: Recent Executive Including Star Actions

The December 2025 executive vote included:

  • Core protocol changes (stUSDS risk parameters, delegate compensation)
  • Spark proxy spell (implementing Spark governance decisions)
  • Grove StarGuard initialization (security module for Grove)
  • Whitelisting proxy spells for future Star actions [97]

Governance Complexity

The multi-layered governance introduces complexity:

  • Sky token holders may not follow Star governance closely
  • Star governance participants may not engage with core Sky governance
  • Bundled executives combining core and Star changes reduce transparency
  • Coordination failures could create friction between layers

Evolution Toward Decentralization

The Star architecture aims to balance:

  • Autonomy — Stars can innovate and move quickly without requiring core protocol votes for every decision
  • Coordination — Core protocol maintains oversight and veto power over changes affecting system-wide risk
  • Scalability — Multiple Stars can operate in parallel without creating governance bottlenecks

This represents an evolution from monolithic governance toward federated governance, though the optimal balance remains actively debated in the Sky community.

  • Spells - Smart contract implementations executed by Executive Votes
  • Sky Governance Voting - Comprehensive overview of Sky's governance system
  • Sky Atlas - The canonical source for governance processes and procedures
  • Aligned Delegates - Professional delegates who vote on behalf of token holders
  • SKY Staking - Staking mechanism providing voting power through LSSKY tokens
  • Governance Polls - Signal votes that inform Executive Vote proposals
  • Emergency Shutdown - Protocol freeze mechanism as alternative to Executive Votes
  • Sky Protocol - The broader protocol governed through Executive Votes

Sources

  1. How Voting Works - Sky Ecosystem Community
  2. Maker Protocol White Paper - February 2020
  3. Chief - Detailed Documentation - Maker Protocol Technical Docs
  4. Sky Governance Portal
  5. Governance Security Module (GSM) - MakerDAO Blog
  6. How Voting Works - Sky Community GitHub
  7. Sky Governance Portal - Executive Proposals
  8. How Voting Works - Governance Polls
  9. Sky Governance Mechanics
  10. Sky Executive Vote - SSR Increase - X/Twitter
  11. DSChief - GitHub Repository
  12. Chief Detailed Documentation - Continuous Approval
  13. Protocol Participants - Sky Governance Upgrade
  14. MakerDAO DsChief 1.2 Governance Security Update
  15. Chief - Detailed Documentation - Lift Function
  16. Chief-Keeper - GitHub Repository
  17. DSChief README - Hat Mechanism
  18. Chief-Keeper - Hat Guard
  19. DSChief - Failure Modes
  20. GSM Pause Delay Parameter Documentation
  21. GSM Pause Delay - Governance Manual
  22. Executive Vote - Raising GSM Pause Delay - April 5, 2023
  23. Executive Vote - Out-of-schedule - September 13, 2024
  24. MKR-to-SKY Upgrade Phase One - May 15, 2025
  25. GSM Pause Delay - Cancel Spells Exception
  26. Executive Vote - September 2024 GSM Adjustment
  27. Sky Protocol Executive Spell Implementation
  28. DSChief - Single-Use Spells
  29. Sky Protocol Governance Facilitators
  30. Executive Vote - Office Hours Modifier
  31. Executive Vote Details - Office Hours
  32. Executive Proposal Expiration - 30 Days
  33. Governance Polls - Signal Votes
  34. Sky Governance Facilitators - Sidestream and Dewiz
  35. Sky Ecosystem Community GitHub - Governance Votes
  36. Sky Governance Portal - Vote Submission
  37. SKY Staking - LSSKY Voting Power
  38. Aligned Delegates - Delegation Mechanism
  39. LSSKY Token - Voting Weight Calculation
  40. On-Chain Voting Transparency
  41. Chief - Lift Function
  42. Continuous Approval Voting - No Minimum Threshold
  43. Chief-Keeper - Automated Lift Calls
  44. GSM Pause Delay - Current 16 Hours
  45. Cancel Spells - GSM Exception
  46. Protego Contract - Cancel Mechanism
  47. GSM Reduction - September 2024
  48. Office Hours Window - 14:00-21:00 UTC
  49. Executive Expiration - 30 Day Limit
  50. Executive Spell Execution - Public Function
  51. Executive Changes - Irreversibility
  52. Chief V3 - Token Locking Requirement
  53. Sky Governance - No Minimum Stake
  54. Token Locking - No Duration Requirement
  55. LockStake Engine - Voting Integration
  56. Delegation - Token Custody Retention
  57. SelectVoteDelegate Function - LockStake
  58. Aligned Delegates - Official List
  59. Delegate Compensation - Monthly Executive Votes
  60. Multi-Urn Split Delegation
  61. Governance Participation - 26% Turnout
  62. SKY Staking - 46-50% Staked
  63. November 2025 Governance Vote - 6 Billion SKY
  64. November 2024 Brand Vote - Concentration Analysis
  65. Sky Atlas - 3000+ Pages
  66. Black Thursday - March 12, 2020
  67. Black Thursday - $8.32 Million Liquidated for 0 DAI
  68. Black Thursday Emergency Response
  69. Black Thursday Compensation Vote - 0% Compensation Won
  70. Black Thursday - Emergency Shutdown Debate
  71. Multi-Collateral DAI Launch - November 2019
  72. Sky Token Launch - September 13, 2024
  73. MKR-to-SKY Governance Transition - May 15, 2025
  74. SKY Sole Governance Token - May 2025
  75. SKY Staking Rewards Transition - November 3, 2025
  76. November 2025 Vote - 5.97 Billion SKY
  77. Black Thursday Emergency Call
  78. Black Thursday - Two Week Response Strategy
  79. Out-of-Schedule Risk Parameter Vote - February 18, 2025
  80. February 2025 Accelerated Proposal - Market Volatility
  81. GSM Increase - April 2023
  82. GSM Reduction - September 2024
  83. Protego - Emergency Cancellation
  84. Sky Participation - 26% of Supply
  85. Staking vs Voting Participation
  86. Sky Atlas Documentation - 3000+ Pages
  87. November 2024 Vote - 51.3% Single Entity
  88. Transparent On-Chain Voting
  89. Sky Atlas - Technical Complexity
  90. Governance Poll Process
  91. Emergency Executive Votes
  92. Emergency Shutdown Module
  93. Black Thursday Shutdown Debate
  94. Black Thursday - Community Vetoed Shutdown
  95. Stars Architecture - Endgame
  96. Proxy Spells for Stars
  97. December 2025 Executive - Star Actions

Data Freshness

  • Temporal Category: Semi-static

  • Last Updated: January 11, 2026

  • Data Currency:

  • GSM Pause Delay: 16 hours (as of September 2024)

  • Governance participation: ~26% of circulating supply (January 2026)

  • Office hours window: 14:00-21:00 UTC, Monday-Friday

  • Executive expiration: 30 days

  • Recent executives: December 2025 votes detailed

  • For real-time governance activity, consult Sky Governance Portal

  • Next Review Recommended: April 2026 (to capture governance evolution, participation trends, and any parameter changes)