Sky Governance Voting

Introduction

Sky Governance Voting is the on-chain voting system through which SKY token holders exercise direct control over the Sky Protocol (formerly MakerDAO), making binding decisions about protocol parameters, smart contract upgrades, collateral additions, and strategic direction. ^[1] As of January 2026, the system processes executive votes approximately every two weeks and governance polls weekly, collectively managing a protocol with approximately $6.65 billion in total value locked and over $9.86 billion in USDS supply across the Sky ecosystem. ^[2]^[18]

The governance voting system operates through two primary mechanisms: Executive Votes that enact binding protocol changes through smart contract execution, and Governance Polls that measure community sentiment before changes proceed to executive implementation. ^[3]^[4] This two-stage architecture balances the need for informed deliberation with the technical requirement for on-chain execution of protocol modifications.

Unlike many blockchain governance systems that use simple majority voting with fixed timeframes, Sky Protocol implements a continuous approval voting mechanism for executive votes. ^[8] Under this model, competing executive proposals can be introduced at any time, and the executive with the most voting weight becomes the active "hat" controlling protocol smart contracts. This design creates an ongoing governance equilibrium where current protocol state must be actively defended by voters against competing proposals, ensuring sustained community engagement rather than periodic burst participation.

The system has demonstrated both remarkable resilience and concerning centralization trends throughout its evolution from MakerDAO's 2017 launch to the 2024 Sky rebrand and the May 2025 governance token transition. During the March 2020 "Black Thursday" crisis when ETH crashed 43% in a single day, emergency governance coordination prevented protocol collapse through rapid parameter adjustments and collateral additions. ^[11]^[12] However, governance votes continue to reveal extreme voting power concentration, with just four entities controlling approximately 80% of voting weight in the November 2024 brand decision vote, raising fundamental questions about decentralization in practice versus theory. ^[13]^[14]^[15]^[16]

A major governance milestone occurred on May 19, 2025, when Sky executed a governance spell making SKY the sole decision-making token and disabling MKR's voting power entirely. ^[19] The codebase now routes all governance actions through SKY, including parameter adjustments and treasury allocations, completing the transition from the legacy MKR governance system.

History and Evolution

Sky Governance Voting's development mirrors the broader evolution of decentralized autonomous organization governance, progressing from informal coordination to sophisticated on-chain mechanisms that balance efficiency, security, and decentralization.

Origins in Early MakerDAO (2017-2019)

MakerDAO launched its mainnet protocol in December 2017 with Single-Collateral DAI backed exclusively by ETH, implementing one of blockchain's first on-chain governance systems for a decentralized stablecoin protocol. The initial governance architecture centered on the DSChief smart contract, which enabled MKR holders to lock their tokens and vote on executive proposals that modified protocol parameters. ^[8]

The early system required voters to deposit MKR into the DSChief contract, receiving IOU tokens representing their voting weight. These IOU tokens could then be used to "vote" for executive spell contracts—smart contracts containing encoded protocol changes that would execute if they achieved the most voting weight. This mechanism established the foundational continuous approval voting model that persists today, where executive proposals compete for voting support rather than concluding within fixed timeframes.

Initial governance participation remained concentrated among MakerDAO Foundation members, early investors, and dedicated community members who understood the technical complexity of smart contract parameter adjustments. Voter turnout for early executive votes typically involved only a few dozen unique addresses, though these addresses controlled significant MKR holdings. The low participation reflected both the protocol's nascent ecosystem and the high technical barriers to understanding proposals about liquidation ratios, stability fees, and debt ceiling adjustments.

Formalizing Governance Processes (2019-2020)

The transition from Single-Collateral DAI to Multi-Collateral DAI (MCD) in November 2019 necessitated more sophisticated governance processes as the protocol expanded to support multiple collateral types with distinct risk parameters. The MCD upgrade introduced numerous new smart contracts (VAT, VOW, JUG, SPOT, DOG/CAT, CLIP/FLIP) that required governance oversight, expanding the scope of decisions from simple parameter adjustments to complex risk management across diverse asset types.

This period saw the emergence of regular governance processes including weekly Governance Polls to signal community sentiment and bi-weekly Executive Votes to implement approved changes. ^[8] The Sky Forum (forum.makerdao.com) became the mandatory venue for pre-vote deliberation, establishing the off-chain discussion → signal poll → executive vote pipeline that remains standard today.

The introduction of the Governance Security Module (GSM) in 2020 added a critical security layer to executive votes. ^[7] The GSM implements a time delay between when an executive vote passes and when its changes activate on-chain. This delay provides the community with a window to detect malicious proposals and trigger an emergency shutdown if necessary, protecting against governance attacks where attackers quickly accumulate voting power and push through harmful changes.

Black Thursday Crisis and Emergency Governance (March 2020)

March 12-13, 2020—known as "Black Thursday"—tested MakerDAO's governance system under extreme stress when ETH crashed 43% from $194 to $111 in a single day. ^[11] The price collapse triggered a cascade of liquidations across the system, but network congestion from the broader crypto market panic prevented liquidation auctions from completing properly. Some auctions concluded with zero bids, allowing liquidators to seize collateral for free while leaving the protocol with $4.5 million in unbacked DAI. ^[11]

The crisis prompted emergency governance coordination that played out over two weeks of intense discussion, debate, and multiple governance votes. ^[12] The community faced a critical decision: trigger Emergency Shutdown (permanently halting the protocol and allowing DAI holders to claim proportional collateral shares) or attempt to recapitalize through alternative means.

On an emergency governance call held that Thursday, multiple participants wondered if Emergency Shutdown would be necessary, but the Maker community ultimately vetoed this option in favor of less drastic measures. ^[12] The governance response included several critical votes:

Auction Parameter Adjustments: Governance increased maximum lot sizes from 50 to 500 ETH and extended auction durations to prevent repeat failures ^[17]
USDC Collateral Addition: Emergency vote to add USDC as collateral enabled users to trade between USDC and DAI, stabilizing the DAI peg ^[12]
Debt Auction Implementation: Governance approved minting new MKR through debt auctions, where MKR was sold to bidders for DAI to recapitalize the protocol and eliminate bad debt ^[11]

This crisis demonstrated both governance's capacity for rapid emergency response and its limitations—the need for extensive discussion and multiple votes created delays during a time-critical situation, prompting later development of emergency spell mechanisms that could bypass normal governance timelines for urgent security responses.

MIPs Framework and Governance Standardization (2020-2022)

The April 2020 introduction of the Maker Improvement Proposals (MIPs) framework marked a watershed moment in formalizing governance processes. MIP0 through MIP13 established standardized templates, submission procedures, review timelines, and ratification requirements for protocol changes. ^[9]

The MIPs framework created explicit governance cycles with predictable timing: the Operational Weekly Cycle handled routine parameter adjustments and operational decisions through weekly polls and bi-weekly executive votes, while the Monthly Governance Cycle addressed longer-term structural changes through Atlas Edit Proposals with extended review periods and ratification polls. ^[5]

This standardization brought both benefits and drawbacks. Benefits included increased predictability for community members planning their governance participation, clearer accountability through documented review processes, and reduced ambiguity about what changes required which approval mechanisms. Drawbacks included increased bureaucracy that could slow urgent decisions, higher barriers to entry for new community members navigating complex procedures, and potential for process to override substance when proposals were rejected for procedural violations despite strong substantive merit.

The period also saw the rise of the Recognized Delegate system, where community members could accept delegated voting power from token holders who lacked time or expertise for direct participation. ^[10] Delegates committed to regular voting, public explanation of their rationales, and adherence to communication standards in exchange for protocol compensation. This professionalization of governance participation increased consistent voter turnout but raised concerns about centralizing influence among a small delegate cohort.

The Endgame Transition (2022-2024)

Founder Rune Christensen's Endgame Plan, first proposed in 2022 and refined through extensive 2023-2024 governance discussions, envisioned restructuring MakerDAO into a constellation of semi-independent SubDAOs (later called Stars) including Spark, Grove, Keel, and others. The plan required numerous governance votes to implement, testing the system's capacity to coordinate complex multi-stage transitions.

Endgame implementation votes revealed growing participation inequality—while total voting power increased as SKY replaced MKR at a 24,000:1 ratio, the number of unique voting addresses declined, suggesting consolidation among large holders or increasing reliance on delegation. Forum discussions showed significant community divisions about Endgame's direction, with supporters viewing it as necessary evolution and critics worrying about fragmentation and governance overhead.

The Sky Rebrand Governance Controversy (September-November 2024)

The September 18, 2024 rebrand from MakerDAO to Sky triggered one of the most contentious governance periods in protocol history. The rebrand, implemented through executive vote, introduced new branding, USDS and SKY tokens alongside legacy DAI and MKR, and comprehensive Sky Atlas governance documentation.

Community reaction was mixed, with forum discussions expressing confusion about strategic rationale, concerns about brand dilution for the well-established MakerDAO name, and frustration with rapid change pace. ^[14] In November 2024, a governance poll asked: "Should Sky maintain the Sky brand as the backend protocol brand?" ^[13]

The vote outcome revealed extreme centralization: 79.3% of votes supported maintaining the Sky brand, but only approximately 20 unique addresses participated, with four entities controlling roughly 80% of vote share. ^[13]^[14]^[15] Specifically:

Largest entity: 16,856,655 MKR (51.3% of total votes cast)
Second entity: 5,495,126 MKR (16.7%)
Third entity: 2,355,000 MKR (7.2%)
Fourth entity: 1,603,704 MKR (4.9%)

Venture capitalist Mike Dudas raised concerns about these dynamics, highlighting how concentrated voting power among a few entities exposes DAOs to centralization issues. ^[13]^[14] The controversy sparked broader discussions about whether token-weighted governance can meaningfully implement decentralized decision-making when token holdings concentrate among a small number of large entities.

MKR to SKY Governance Transition (May 2025)

A pivotal governance transition occurred on May 19, 2025, when Sky executed a governance spell that made SKY the sole governance token of the protocol, permanently disabling MKR's voting power. ^[19] This represented the completion of the governance token migration that began with the September 2024 rebrand.

The transition introduced a time-based penalty mechanism for users who delayed upgrading their MKR to SKY. Starting September 18, 2025, a 1% penalty applied, increasing by 1% every three months. As of December 2025, the penalty had risen to 2%, with further increases scheduled unless governance intervenes. ^[20] This penalty mechanism incentivizes holders to complete the migration while providing a gradual timeline rather than a hard deadline.

By September 2025, over 618 million MKR (63.25% of the total supply) had been upgraded to SKY, indicating strong but incomplete adoption of the new governance token among existing holders. ^[19]

Technical Architecture

Sky Governance Voting operates through sophisticated smart contract infrastructure that has evolved over seven years of mainnet operation, balancing security, flexibility, and decentralization while managing billions of dollars in protocol value.

DSChief and Continuous Approval Voting

The DSChief smart contract serves as Sky Protocol's core governance execution layer, implementing the continuous approval voting model that distinguishes Sky governance from most blockchain voting systems. ^[8]

Continuous Approval Voting Mechanics:

Unlike traditional voting where proposals conclude after fixed timeframes (e.g., 7-day voting period), continuous approval voting means that executive proposals remain active indefinitely and compete for voting support at all times. ^[8] The executive proposal with the most voting weight becomes the "hat"—the active spell controlling protocol smart contracts and parameters.

Key characteristics include:

No Time Limits: Executive votes do not conclude within set periods—if a proposal lacks sufficient votes initially, it may gain support later if the proposal becomes more popular ^[8]
Active Defense Requirement: Voters must continuously stake their voting weight on preferred proposals to defend current protocol state against competing alternatives ^[8]
Voting Weight Barrier: New proposals must surpass the voting weight of the currently leading proposal to become the new hat, creating a security threshold that increases with participation ^[8]
Permanent Staking: By design, votes remain in the system continuously to prevent bad proposals from passing easily through temporary lapses in attention ^[8]

This design creates several governance dynamics:

Security Through Participation — The more votes committed to the current protocol state, the more secure the system is from "rogue" proposals that could harm the protocol. ^[8] An attacker would need to accumulate sufficient voting power to exceed all defender votes, making attacks more expensive as participation increases.

Coordination Challenges — Because votes remain staked on proposals rather than concluding and releasing voting power, voters must actively monitor governance to shift support between competing proposals. This creates friction compared to simple majority voting where voters can participate periodically.

Inertia Bias — The continuous approval model creates bias toward the status quo—dislodging a currently active executive requires not just majority support but sufficient support to overcome the barrier created by defenders of current state. This conservatism can be beneficial (preventing rash changes) or harmful (blocking necessary upgrades).

Chief Contract Version 3 and IOU Token Removal

The May 2025 governance transition introduced Chief V3, deployed at address 0x929d9A1435662357F54AdcF64DcEE4d6b867a6f9, which implements significant technical improvements over previous versions. ^[21]

IOU Token Elimination:

One of the most substantial changes in Chief V3 is the complete removal of IOU tokens from the governance process. ^[21] In previous versions:

Chief V1: IOU tokens were returned to users' wallets when they deposited MKR, requiring users to approve IOU token transfers before withdrawing their MKR—a two-transaction process that created friction and confusion.
Chief V2: IOU tokens were held within Vote Delegate contracts, eliminating the need for user approval, but the tokens still existed within the system architecture.
Chief V3: IOU tokens have been entirely removed. The lock function no longer mints IOU tokens when governance tokens are deposited, and the free function no longer burns IOU tokens during withdrawals. ^[21]

This simplification provides several benefits:

Reduced Transaction Complexity: Users can now withdraw SKY from Chief with a single transaction, eliminating the previous two-step approval and withdrawal process.
Improved User Experience: Governance participants no longer need to understand or manage IOU tokens, lowering technical barriers to participation.
Delegate Simplification: Vote Delegate contracts operate more straightforwardly without IOU token management logic.

Flash Loan Protection:

Chief V3 maintains flash loan protections but implements them through a new mechanism that prevents manipulation of the voting process with flash-loaned tokens. ^[21] This protection ensures that attackers cannot temporarily borrow large amounts of SKY to pass malicious proposals, as the voting weight calculation incorporates time-based restrictions.

Vote Delegate Changes:

The hatch trigger and cooldown mechanisms have been removed from Vote Delegate contracts in V3. ^[21] Previously, these mechanisms could restrict user actions based on other participants' behavior. Their removal eliminates previous interaction limitations, making delegation more flexible and predictable for all participants.

Function Signature Updates:

For backward compatibility, the Chief contract's GOV() getter function remains available, but the primary function has been renamed to gov() to follow updated Solidity conventions. ^[21] Integrators using the old function signature will still function correctly.

Spell Contracts and Executive Vote Execution

Executive votes execute through "spell" contracts—smart contracts containing encoded instructions for protocol changes that activate when they achieve the most voting weight and pass through the Governance Security Module delay.

Spell Construction:

Core Spell Teams (formerly called Governance Security Engineering Team) construct spell contracts following standardized patterns. ^[3] A typical spell includes:

Parameter Changes: Updates to liquidation ratios, stability fees, debt ceilings, savings rates, etc.
Smart Contract Upgrades: Deployment of new contract versions or replacement of existing contracts
Collateral Actions: Adding new collateral types or offboarding existing ones
Treasury Operations: Payments to contributors, transfer of funds between contracts, etc.
Multiple Actions: Spells can bundle numerous changes into a single atomic transaction that either fully succeeds or fully reverts

Execution Flow:

When a spell achieves the most voting weight:

Becomes Hat: The spell contract is recognized as the current "hat" by DSChief
GSM Delay: The Governance Security Module imposes a delay before the spell can execute (currently 48 hours) ^[7]
Public Review: During the delay, the community can review the spell code to verify it matches the proposed changes
Execution: After the delay expires, anyone can trigger the spell execution by calling the spell contract
Protocol Update: The spell executes its encoded changes, which typically include calls to multiple Sky Protocol contracts updating parameters or replacing contract addresses

Security Considerations:

The spell system provides security through several mechanisms:

Deterministic Code: Spells execute exactly the code in the spell contract, eliminating ambiguity about what changes will occur
Public Auditability: Anyone can review spell source code on Etherscan before execution
Delay Window: The GSM delay provides time to detect malicious spells and coordinate emergency response
Atomic Execution: All changes succeed or fail together, preventing partial application of proposal bundles

However, the system also faces risks:

Code Complexity: Spell contracts can be hundreds of lines of Solidity code, creating review difficulty for non-technical community members
Verification Challenges: Matching spell code to proposal descriptions requires technical expertise
Malicious Spell Risk: If attackers accumulate sufficient voting power and pass a malicious spell, the GSM delay may provide insufficient time to coordinate emergency shutdown

Governance Security Module (GSM)

The Governance Security Module implements a time delay between when an executive vote passes and when its changes activate, providing a critical security window for community response to malicious or erroneous proposals. ^[7]

GSM Parameter History:

The GSM delay has evolved through multiple governance decisions: ^[22]

72 Hours (December 2020): The initial governance delay was set to 72 hours, providing extensive review time but slowing protocol responsiveness.
16 Hours (Later Reduction): Governance subsequently reduced the delay to 16 hours to improve agility for time-sensitive decisions.
30 Hours (April 2024): A March 2024 governance poll and April 2024 executive vote increased the delay from 16 to 30 hours, adding 14 hours of additional security buffer.
48 Hours (Current - as of May 2025): The delay was further increased to the current 48-hour period, reflecting governance's judgment that enhanced security outweighs responsiveness costs.

Why the Delay Matters:

The 48-hour delay addresses several security scenarios:

Malicious Governance Attack: If attackers accumulate voting power through market purchases, flash loans, or borrowing and pass a harmful spell, the delay provides time for community to detect the attack and trigger emergency shutdown before the spell executes
Implementation Errors: If spell teams accidentally introduce bugs in spell code that would harm the protocol, the delay allows review and replacement with corrected spells before execution
Coordination Time: The delay enables delegates and large voters to coordinate responses to unexpected proposals, allowing the community to reverse decisions by moving voting weight to alternative spells

Emergency Mechanisms:

Several mechanisms allow faster action when the full 48-hour delay would be harmful:

Dark Spell Mechanism: For critical technical vulnerabilities that have been responsibly disclosed, dark spells can be employed to fix exploits while minimizing exposure risk during the delay period. ^[22]
Protego Contract: This contract allows Sky Governance to cancel the execution of planned governance actions that are awaiting GSM delay expiration, providing a defensive tool against malicious proposals that slip through. ^[22]
Emergency Shutdown Module: The GSM delay does not apply to the Emergency Shutdown Module, allowing immediate protocol halt if catastrophic circumstances require it. ^[22]

Tradeoffs:

The GSM delay creates a fundamental tradeoff between security and responsiveness:

Security Benefit: Longer delays provide more time to detect and respond to problems
Responsiveness Cost: Urgent protocol changes face mandatory delays even when immediate action would benefit the protocol

The current 48-hour delay reflects governance's judgment that security concerns outweigh the cost of delayed implementation for most proposals. However, certain emergency situations (like the USDC depegging in March 2023) revealed limitations when rapid response is required, prompting development of emergency spell mechanisms with shorter delays for crisis situations.

Polling System Architecture

Governance Polls provide non-binding signal requests that measure community sentiment before proposals proceed to binding executive votes. ^[4] The polling system operates through separate smart contracts from executive voting, enabling different voting mechanics and participation models.

Poll Types:

Weekly Polls: Standard governance polls that determine bi-weekly executive vote contents, typically running 3-day voting periods ^[4]
Monthly Ratification Polls: Longer-duration polls (14 days) for Atlas Edit Proposals requiring more deliberation ^[5]
Non-Standard Weekly Polls: Urgent signal requests for time-sensitive decisions that need faster resolution than monthly cycles allow ^[4]

Poll Voting Formats:

Polls support multiple voting mechanisms depending on the decision type:

Binary Voting: Simple yes/no/abstain for straightforward decisions
Instant Run-Off Voting: Ranked-choice voting for selecting among multiple options
Approval Voting: Voters can approve multiple options, useful for selecting multiple items

Quorum Requirements:

Ratification Polls under the Atlas Edit Monthly Governance Cycle require minimum positive participation thresholds: ^[5]

Minimum Positive Participation: 240,000,000 SKY must vote "yes" for the poll to succeed
Majority Requirement: Yes vote-weight must exceed No vote-weight
Both Conditions: Both the participation threshold and majority requirement must be met

These quorum requirements prevent low-turnout polls from passing significant protocol changes, though critics argue the thresholds enable large holders to block proposals through abstention rather than active opposition.

Voting Weight Calculation

Voting power in Sky governance derives from token holdings and staking positions, with the LockStake Engine (Staking Engine) enabling users to maintain voting rights while earning staking rewards.

Voting Weight Sources:

Direct Token Holdings: Users can lock SKY tokens directly in DSChief to receive voting weight proportional to locked tokens (1 token = 1 vote) ^[6]
Staked SKY: Users who stake SKY in the LockStake Engine automatically receive the ability to delegate voting power while simultaneously borrowing USDS against their position and earning staking rewards ^[6]^[23]
Delegated Voting: Token holders can delegate their voting power to Recognized Delegates who vote on their behalf while token holders retain custody and reward earnings ^[10]

LockStake Engine Capabilities:

The LockStake Engine allows users to deposit SKY and open a vault position for multiple purposes simultaneously: ^[23]

Borrow USDS using deposited SKY as collateral
Stake the entire SKY deposit to earn rewards from available options
Delegate voting power to a governance delegate

Users can open multiple vaults from a single address for greater flexibility in managing borrowing, staking, and delegation strategies with their SKY holdings.

Delegation Mechanics:

The delegation system enables token holders to assign voting rights to expert delegates:

Custody Retention: Delegators maintain full token custody and can undelegate at any time
Instant Changes: Delegation changes take effect immediately for new votes
Split Delegation: Users can create multiple LockStake Engine urns with different delegations, splitting voting power across multiple delegates

Voting Power Concentration:

Recent governance votes reveal significant voting power concentration:

November 2024 Brand Vote: Just 4 entities controlled ~80% of voting power, with the largest single entity holding 51.3% ^[13]^[14]
December 2025 Governance Votes: ~6.8 billion SKY participating, with top delegates controlling substantial portions of total weight ^[24]

This concentration creates governance dynamics where a small number of large holders or delegates effectively determine outcomes, raising questions about whether such systems implement meaningful decentralization or merely formalize oligarchic control.

Governance Voting Processes

Sky Protocol implements distinct governance processes for different decision types, balancing the need for rapid routine adjustments against the importance of extensive deliberation for significant structural changes.

Operational Weekly Cycle

The Operational Weekly Cycle handles routine protocol parameter adjustments and operational decisions through weekly polls followed by bi-weekly executive votes. ^[3]

Weekly Poll Timeline:

Monday (Week 1):

Core Facilitator publishes governance polls to the community GitHub and voting portal
Polls run for three days, closing Wednesday

Wednesday (Week 1):

Polls conclude and results are tallied
Core Facilitator determines which items will proceed to executive vote based on poll outcomes

Friday (Week 2):

Executive vote is posted to the governance portal approximately two weeks after the poll
The executive remains active under continuous approval voting until it achieves the most voting weight

Governance Security Module Delay:

After executive achieves hat status, 48-hour delay begins before execution
Community can review spell code during this window

Execution:

After GSM delay expires, spell activates and changes go live on-chain

Typical Weekly Poll Content:

Weekly polls typically address:

Stability fee adjustments for existing collateral types
Debt ceiling modifications to manage protocol exposure
Savings rate changes to balance supply and demand for USDS/DAI
Minor risk parameter tweaks based on market conditions
Operational payments and contributor compensation

Recent Example - December 2025:

The December 12, 2025 executive vote included numerous bundled actions typical of the weekly cycle: ^[24]

Initializing and funding the SubProxy and StarGuard for Core Council Executor Agent 1
Normalizing the USDS-SKY farm vesting stream
Increasing the Delayed Upgrade Penalty to 2%
Decreasing the stUSDS Liquidation Ratio and Capped Oracle price
Distributing November Ranked Delegate and December Atlas Core Development compensation
Whitelisting proxy spells for Spark and Grove in their respective StarGuard modules

This vote passed with 6,849,013,915 SKY supporting the leading option and was executed on December 15, 2025.

Exceptions to Poll Requirements:

Some decisions can proceed directly to executive vote without preceding polls if explicitly authorized by the Sky Atlas. These typically include:

Emergency parameter changes for urgent risk mitigation
Technical deployments that implement previously ratified plans
Routine operational payments specified in approved budgets

Atlas Edit Monthly Cycle

The Atlas Edit Monthly Governance Cycle provides a structured process for significant protocol changes that modify the Sky Atlas—the comprehensive governance documentation defining protocol operations. ^[5]

Monthly Cycle Timeline:

Submission Window (1st-3rd of Month):

Authors submit Atlas Edit Proposals (AEPs) to the Sky Forum
Proposals must follow standardized templates and formatting
Seven-day "frozen period" requirement: proposals cannot be modified in the seven days before formal submission

Formal Submission Review (4th-5th):

Core Facilitator reviews submitted AEPs for completeness and compliance
Incomplete or non-compliant proposals are rejected with feedback
Authors can fix issues and resubmit in the following month's cycle

Feedback Period (5th-End of Month):

Community discusses proposals on the Sky Forum
Authors may respond to feedback but cannot modify formal submissions
Domain experts provide technical review and risk assessment

Ratification Poll (1st-14th of Following Month):

Core Facilitator publishes ratification polls for approved AEPs
14-day voting period provides extended time for community deliberation
Minimum participation requirement: 240,000,000 SKY must vote yes ^[5]
Majority requirement: Yes votes must exceed No votes

Executive Vote Implementation (Following Bi-Weekly Cycle):

Approved AEPs are implemented through standard executive vote process
Executive vote typically occurs 2-4 weeks after ratification poll concludes
GSM delay applies before changes activate

Atlas Update:

After successful executive vote and GSM delay, changes are formally incorporated into the Sky Atlas
Documentation is updated on atlas.sky.money

Recent Example - December 2025 Atlas Edits:

The December 2025 governance cycle included several Atlas edits: ^[24]

Updating the Grove Artifact with new deployments and contracts
Updating the Keel Artifact with the Solana ALM Controller's USDC TokenAccount address
Updating the Core Council Buffer multisig to a 5-of-6 signing requirement
Adding Ecosystem Accord 6 for Launch Agent 6 with 10 million USDS Genesis Capital Allocation
Updating the Risk Framework to include offchain lending via Anchorage Digital

Reconciliation Process:

If multiple AEPs editing the same Atlas component pass in the same Monthly Governance Cycle, a reconciliation process determines priority and integration. This typically involves Core Facilitator coordination with proposal authors to create combined implementations that incorporate all approved changes where possible.

Emergency Voting and Response

Sky Protocol maintains emergency governance procedures for urgent situations requiring faster response than standard governance cycles allow. ^[7]

Emergency Situations:

Emergency procedures apply to scenarios including:

Critical smart contract vulnerabilities requiring immediate patches
Oracle failures threatening collateral valuations
Market conditions creating systemic risk to protocol solvency
External threats like regulatory actions or infrastructure failures

Emergency Spell Types:

Protego Spells: Pre-prepared emergency spells that implement specific defensive actions, requiring Governance Facilitator validation before deployment ^[7]
Standby Spells: Pre-vetted spell code maintained in standby status that can be activated quickly during emergencies ^[7]
Custom Emergency Spells: Newly constructed spells for unanticipated emergencies, requiring accelerated review and voting

Emergency Process:

Detection and Coordination:

Community members detect emergency situation through monitoring
Emergency contact mechanisms (dedicated channels for Aligned Delegates) are activated
Emergency governance call convenes to assess situation

Response Options:

Expedited Executive Vote: Known and uncontentious remedies can proceed to expedited executive vote with compressed timeline, though still requiring sufficient voting weight ^[7]
Emergency Shutdown: Most severe response, permanently halting protocol operations and allowing token holders to claim proportional collateral shares—reserved for catastrophic governance attacks or existential protocol threats

Governance Facilitator Authority:

Governance Facilitators have special authority during emergencies including:

Ability to expedite proposal timelines with consensus
Coordination of emergency response across participants
Validation of emergency spell authenticity to prevent social engineering attacks

Historical Emergency Responses:

The most significant emergency governance event was Black Thursday (March 12-13, 2020), when ETH crashed 43% and triggered protocol-wide liquidations. ^[11]^[12] The community considered Emergency Shutdown but ultimately coordinated multi-week response through:

Emergency auction parameter changes
Expedited USDC collateral addition to stabilize DAI peg
Debt auction implementation to recapitalize the protocol

More recent emergencies like the March 2023 USDC depeg (when USDC temporarily lost its peg following Silicon Valley Bank collapse) saw faster governance response with parameter changes implemented within days rather than weeks, demonstrating governance's evolution in crisis management capabilities.

Delegation and Proxy Voting

The Recognized Delegate system enables token holders to assign voting responsibilities to active governance participants while retaining token custody and economic rights.

How Delegation Works:

Delegate Recognition: Community members apply to become Recognized Delegates through the Sky Forum, providing information about their governance philosophy, expertise, and commitment ^[10]
Voting Weight Assignment: Token holders use the governance portal or LockStake Engine to assign their voting power to chosen delegates
Active Participation: Delegates vote on executive proposals and polls using aggregated voting power from their delegators
Communication Requirements: Delegates must publicly explain their voting rationales on the Sky Forum, typically through weekly or monthly updates
Compensation: Aligned Delegates receive protocol compensation for their governance work, with amounts tied to voting participation and communication quality

Delegation Benefits:

Increased Turnout: Delegation increases effective governance participation by enabling passive holders to contribute voting power through active delegates
Expertise Leverage: Token holders benefit from delegates' specialized knowledge without needing to develop governance expertise themselves
Capital Efficiency: LockStake Engine integration allows delegation while maintaining staking rewards and borrowing capacity

Delegation Risks:

Principal-Agent Problem: Delegates may vote in ways that benefit themselves rather than their delegators, with limited accountability mechanisms beyond re-delegation
Centralization: Voting power concentrates among a small number of top delegates, potentially enabling coordination for governance capture
Plutocracy Amplification: Large holders can offer delegates lucrative compensation for voting aligned with their interests, amplifying existing wealth-based power inequalities

Delegate Accountability:

Several mechanisms attempt to ensure delegate accountability:

Public Voting History: All delegate votes are recorded on-chain and visible through the governance portal
Forum Communication: Delegates must post voting rationales, enabling delegators to evaluate decision quality
Re-delegation: Delegators can instantly switch delegates if dissatisfied with performance
Compensation Contingencies: Delegate compensation can be reduced or eliminated through governance vote for non-performance

However, in practice accountability remains limited—most delegators do not actively monitor delegate performance, re-delegation is rare, and the effort required to coordinate dissatisfied delegators makes collective action difficult.

Current State and Adoption

As of January 2026, Sky Governance Voting demonstrates significant participation inequality and centralization concerns despite managing one of DeFi's largest protocols by total value locked.

Voting Participation Metrics

Recent Vote Statistics (December 2025 - January 2026):

Active Voting SKY: ~6.8 billion SKY participating in recent executive votes out of approximately 23 billion circulating supply (~30% turnout) ^[24]
Total Delegates: 28 delegates (10 aligned delegates and 18 shadow delegates) ^[25]
Total SKY Delegated: 5,764,610,710 SKY across 879 delegators ^[25]
Unique Voting Addresses: Approximately 15-30 unique addresses in most executive votes
Top 4 Voters Combined: ~80% of voting weight in major decisions ^[13]^[14]

Historical Comparison:

Participation has evolved significantly since MakerDAO's 2017 launch:

2017-2019: 20-50 unique voters per executive, mostly foundation members and early investors
2020-2021: 50-100 unique voters as community expanded and delegate system launched
2022-2023: 30-60 unique voters as professionalization concentrated activity among delegates
2024-2025: 15-30 unique voters despite 10x token supply increase from MKR→SKY conversion

The declining unique voter count despite massive supply increase suggests increasing concentration among large holders and growing reliance on delegation rather than direct participation.

Delegate Ecosystem

The Recognized Delegate system has become the dominant governance participation model for most token holders.

Delegate Statistics (January 2026):

Total Recognized Delegates: 28 total (10 Aligned Delegates receiving compensation, 18 Shadow Delegates) ^[25]
Delegated Voting Power: Over 5.7 billion SKY delegated from 879 unique delegators ^[25]
Delegate Participation: DAOs implementing delegated voting report 30-50% higher efficiency in governance outcomes compared to direct-only voting systems ^[18]
Compensation Distribution: Delegate compensation distributed monthly through executive votes, with November 2025 compensation distributed in the December 12, 2025 executive ^[24]

Major Delegate Categories:

Individual Community Delegates: Long-standing community members with deep protocol knowledge
Institutional Delegates: Crypto funds and DeFi-focused organizations
Anonymous/Pseudonymous Delegates: Contributors maintaining privacy through pseudonyms
Protocol-Affiliated Delegates: Contributors with employment or service relationships to Sky ecosystem

The delegate ecosystem provides governance expertise and consistent participation, but concentration among a small cohort raises concerns about groupthink, coordination risks, and whether delegate interests align with broader token holder preferences.

Recent Significant Votes

December 15, 2025: Atlas Edits and Operational Updates

This executive vote passed on December 12, 2025 and was executed on December 15, 2025: ^[24]

Voting Power: 6,849,013,915 SKY supporting the winning option
Key Changes: Updated Grove and Keel Artifacts, initialized Core Council Executor Agent 1 SubProxy and StarGuard, distributed 20 million USDS to CCEA1 SubProxy, increased Delayed Upgrade Penalty to 2%
Additional Actions: Distributed November delegate compensation and December Atlas Core Development payments, whitelisted proxy spells for Spark and Grove

November 3, 2025: SKY Staking Rewards Transition

This executive vote transitioned staking rewards from USDS to SKY tokens, fundamentally restructuring protocol tokenomics:

Voting Power: 5,970,568,963 SKY supporting the winning option
Participation: ~26% of circulating supply
Key Changes: Tripled daily buybacks from 100K to 300K USDS, allocated 500M SKY for staking rewards, established 90-day transition period

November 28, 2025: Monthly Settlement and Operations

This routine operational vote included multiple bundled items:

Voting Power: 5,970,568,963 SKY winning option
Leading Alternative: 3,166,942,388 SKY
Content: Launched Starguard for multiple SubDAOs, executed Treasury Management Function, paid delegate compensation
Execution: Passed and executed December 1, 2025

November 2024: "Should Sky maintain the Sky brand?"

This controversial vote revealed extreme voting power concentration:

Outcome: 79.3% voted to maintain Sky brand ^[13]^[14]
Participation: ~20 unique addresses
Concentration: 4 entities controlled ~80% of voting power ^[13]^[14]^[15]
Criticism: Vote sparked intense debates about governance centralization and plutocracy

The consistency of ~6-7 billion SKY participating across multiple recent votes (roughly the same addresses) suggests a stable core of active governance participants, with the vast majority of token holders remaining passive despite having voting rights.

Protocol Growth and Ecosystem Expansion

2025 Annual Metrics:

The Sky Frontier Foundation's Annual State of Sky Ecosystem report for 2025 revealed substantial protocol growth: ^[18]

USDS Supply Growth: 86% increase from $5.3 billion to $9.86 billion
Sky Savings Rate TVL: Reached new all-time high of $4 billion in December 2025, representing 63% monthly growth ^[18]
Operational Efficiency: 61.5% reduction in annualized operational expenses
Profit Growth: 24.4% increase in annualized operational profits to $168 million
SKY Buybacks: $102.2 million in annualized buybacks

2026 Roadmap:

Plans announced for 2026 include:

Four new Sky Agents to be introduced
Grove expected to launch its token in the first half of 2026
Continued expansion of the Star (SubDAO) ecosystem

Criticism and Controversies

Sky Governance Voting faces substantial criticism regarding centralization, participation inequality, and whether token-weighted voting can meaningfully implement decentralized decision-making.

Extreme Voting Power Concentration

The November 2024 brand vote exposed the most dramatic voting power concentration in the protocol's history, with four entities controlling ~80% of voting weight. ^[13]^[14]^[15]^[16]

Concentration Details:

Breaking down the four dominant voters:

Entity 1: 16,856,655 MKR (51.3% of total votes cast)
Entity 2: 5,495,126 MKR (16.7%)
Entity 3: 2,355,000 MKR (7.2%)
Entity 4: 1,603,704 MKR (4.9%)

Combined, these four entities represented 26,310,485 MKR out of approximately 32.8 million MKR total votes, leaving only ~6.5 million MKR (~20%) distributed among remaining voters.

Broader DAO Concentration Patterns:

Research indicates that around 78% of DAO tokens are held by the top 20% of stakeholders across the industry, suggesting Sky's concentration issues reflect broader structural challenges in token-weighted governance rather than protocol-specific failures. ^[18]

Implications:

This concentration creates several concerning dynamics:

Oligarchic Control: A small group of 4-5 entities can determine protocol direction regardless of broader community sentiment
Coordination Risk: Fewer actors needed to coordinate for governance capture, reducing security through decentralization
Perception Problem: External observers question whether "decentralized governance" is meaningful when so few control outcomes
Regulatory Risk: Concentrated control could support regulatory arguments that the protocol has identifiable controlling parties

Community Response:

The concentration sparked extensive forum discussions and critical media coverage. ^[13]^[14]^[15] Venture capitalist Mike Dudas specifically highlighted how "five large entities accounted for 80% of the MakerDAO vote," exposing DAOs to centralization vulnerabilities.

However, defenders argue that:

Large holders have significant capital at stake and thus strong incentives to vote in protocol's best interest
Token-weighted voting was always the explicit design—concentration is feature not bug
Alternative voting mechanisms (quadratic, one-person-one-vote) face their own manipulation risks
Any holder could theoretically accumulate large positions and participate

Low Voter Participation

Only approximately 30% of circulating SKY supply actively participates in governance despite holding voting rights, suggesting the vast majority of holders view SKY as speculative asset rather than governance responsibility. Industry data shows voter participation in DAOs averages 17%, with leading DAOs reaching up to 28% for major proposals—placing Sky's participation above average but still leaving significant governance power dormant. ^[18]

Barriers to Participation:

Complexity: The Sky Atlas exceeds 3,000 pages; evaluating proposals requires extensive technical knowledge
Time Requirements: Active governance participation demands hours per week monitoring forums, reviewing proposals, and analyzing risks
Gas Costs: On-chain voting transactions cost $5-20 in gas fees, economically excluding small holders
Language Barriers: Governance occurs primarily in English, limiting international participation
Social Capital: New participants struggle to gain influence in an ecosystem dominated by established relationships

Delegation as Partial Solution:

Research indicates that DAOs implementing delegated voting mechanisms report 30-50% higher efficiency in governance outcomes. ^[18] Sky's delegate system has successfully increased consistent participation, but this efficiency comes at the cost of further concentrating decision-making among professional governance participants rather than broadening the base of active voices.

Historical Trends:

The declining unique voter count despite massive token supply increase (24,000 SKY per 1 MKR conversion) suggests participation concentration is intensifying rather than improving—more tokens, fewer voters.

Discord Between Forum Sentiment and Voting Outcomes

Multiple instances demonstrate disconnects between Sky Forum deliberation and on-chain vote results, questioning whether off-chain governance discussion meaningfully influences outcomes.

Brand Vote Discord:

The November 2024 brand vote exemplified this pattern most dramatically. ^[13]^[14] Forum discussions suggested substantial community preference for reverting to MakerDAO brand, with numerous posts criticizing Sky branding confusion and strategic missteps. However, the binding on-chain vote maintained Sky with 79.3% support driven entirely by four large entities.

Academic Research Findings:

Recent academic studies on DAO governance caution that participation remains uneven, often dominated by coalition blocs. ^[18] Empirical research suggests that in some DAOs, delegation monopolies lead to highly concentrated governance where a small number of delegates control the majority of delegated voting power, effectively replicating centralized governance structures.

Why Discord Occurs:

Several factors contribute to forum-vote misalignment:

Sampling Bias: Forum participants are not representative of token holder population; most large holders don't actively post
Token Weighting: Forum operates on one-person-one-voice while voting weighs by tokens held
Delegate Autonomy: Delegates with significant voting power may vote contrary to forum consensus based on their own judgment
Large Holder Apathy: Whales with majority voting power may not bother participating in forum discussions they view as non-binding

Legitimacy Questions:

This discord raises fundamental questions: If forum deliberation consistently differs from voting outcomes, does the forum serve a meaningful governance function or merely create appearance of democratic process while actual power resides with silent large holders?

MKR to SKY Upgrade Penalty Controversy

The time-based penalty mechanism for MKR to SKY upgrades has generated criticism regarding fairness and potential for governance manipulation. ^[20]

Penalty Structure:

Starting September 18, 2025, a 1% penalty applies to MKR upgrades, reducing the amount of SKY received per MKR. The penalty increases by 1% every three months, reaching 2% as of December 2025, with scheduled increases continuing until it reaches 100% in 25 years unless governance intervenes. ^[20]

Criticisms:

Punitive Design: Critics argue the penalty unfairly punishes holders who may be unable to upgrade due to technical barriers, custody arrangements, or simple unawareness
Governance Voting Implications: Holders who delay upgrading lose voting power proportionally, potentially concentrating governance influence among early upgraders
Irreversibility Concerns: The penalty mechanism is hardcoded into contracts, requiring governance intervention to modify—but holders losing voting power through penalties have diminished ability to influence such changes

Defenders' Response:

Supporters argue the penalty provides clear incentives for timely migration, reduces governance fragmentation between MKR and SKY holders, and was implemented through legitimate governance processes with extensive community discussion.

Continuous Approval Voting Criticisms

The continuous approval voting mechanism, while providing unique security properties, faces criticisms about accessibility and efficiency.

Status Quo Bias:

Continuous approval's requirement that new proposals exceed current proposal's voting weight creates strong bias toward existing protocol state. This conservatism can prevent:

Needed upgrades from passing when defenders of status quo simply refuse to move votes
Course corrections when protocol direction proves misguided
Experimental innovations that could benefit the protocol but face resistance from risk-averse voters

Voter Fatigue:

Because votes remain staked on proposals rather than concluding and releasing voting power, voters must constantly monitor governance to shift support between competing proposals. This creates participation friction and fatigue, particularly for:

Small holders who lack time for continuous monitoring
International participants in incompatible timezones for live coordination
Community members with day jobs and limited governance availability

Coordination Difficulty:

Overcoming continuous approval's voting weight barrier requires coordinating many voters to simultaneously shift voting power to a competing proposal. This coordination challenge:

Favors organized groups (delegates, large holders) over dispersed individuals
Enables entrenched proposals to persist even with declining support if challengers fragment votes across alternatives
Creates complexity that discourages new participant entry

Alternative Mechanisms:

Critics suggest alternatives including:

Fixed Voting Periods: Proposals conclude after set duration, releasing voting power for reallocation
Ranked Preference: Allow voters to specify first, second, third choices to aggregate preference information
Quorum Requirements: Require minimum participation thresholds for executive votes to pass

However, each alternative faces its own tradeoffs regarding security, manipulation resistance, and implementation complexity.

Sky Protocol - The decentralized finance protocol governed through the voting system
SKY Token - The governance token that conveys voting rights
Sky Staking - Staking mechanism enabling voting rights retention while earning rewards
Sky Forum - Off-chain governance discussion platform preceding votes
Endgame Plan - Strategic restructuring extensively deliberated through governance voting

Data Freshness

Temporal Category: Semi-static (governance processes change infrequently, but participation metrics and vote outcomes are dynamic)
Data As Of: January 10, 2026
Next Review: April 2026 (or sooner if significant governance changes occur)

Sources

No full article found