Solana Governance: A Comprehensive Analysis

Actionable Insights

• Governance votes on Solana are nonbinding and advisory, serving as signals of community sentiment. Allowing validators to signal their stance before full implementation helps guide development and minimize contention. The final decision occurs when validators choose which software to run. Proposals can change even after a vote, and ultimately, governance reflects consensus, not enforcement.
• SOL token holders participate indirectly by delegating their staked SOL to validators whose voting choices align with their values or preferences. This is a proportional representation system in which validators can be considered elected representatives. Solana stakers delegate their stake to validators, with each validator's voting power based on their delegated stake.
• Solana’s governance voting is conducted using SPL tokens. Validators are allocated tokens proportional to active stake and send these tokens to designated addresses representing different voting options. Validators are free to split their votes across multiple options. Once submitted, votes are final and cannot be changed.
• All consensus-breaking protocol updates are activated through feature gates, which are non-backward compatible hard forks. Unlike Bitcoin or Ethereum, where a hard fork can result in a permanent chain split if disagreement, Solana’s approach ensures feature gates are activated cluster-wide at a specific slot. Validators upgrade beforehand, preventing chain splits.
• Several economic changes in Solana’s early development—notably the introduction of priority fees with a 50% burn—were implemented without formal governance votes, as the governance system remained immature at this time.
• The current governance voting model—validator-only voting—was established following an advisory vote in October 2023. Over 170 validators participated, representing 14.3% of total stake, with over 70% of that stake favoring validator-only voting as the most practical and efficient starting point.
• The recent vote on SIMD-228 reached a record participation rate of 74.3%, making it the largest blockchain governance event in history by participant count and market cap, with 281 million SOL (~$35B) and over 900 validators casting more than 1,000 votes. It marked the first active participation from major exchange validators like Coinbase, Kraken, and Bybit, highlighting Solana’s growing institutional engagement.
• A recurring concern in Solana’s governance process is the limited role of delegators in decision-making. There is no formal mechanism today for delegators to express their preferences or override validator decisions, leading to situations where validator votes can conflict with the preferences of their delegators.
• The role of a defined quorum in Solana governance votes has also raised concerns. In practice, quorums can create perverse incentives, where participants strategically withhold their votes to prevent a proposal from reaching the required threshold. This was observed in the voting patterns for SIMD-228.
• Solana Foundation Delegation Program delegates 10% of total staked SOL (41.01 million) across 897 validators, amplifying these validators' voting power. Analysis of the recent SIMD-288 vote indicates that SFDP stake was primarily used to vote against the proposal. If this stake had instead voted YES, the proposal would have passed. If SFDP delegated stake had abstained, the proposal would have still failed, but by a narrower margin—64.77% versus the actual 61.39%.
• There is still uncertainty about what qualifies for a governance vote. In March 2025, a planned vote on SIMD-218 (IVC) was withdrawn after consensus emerged that it didn’t require governance approval. Similarly, SIMD-123, while passed, was not clearly an economic change and arguably may not have warranted a formal vote.

Introduction

Governance is a critical component of decentralization, influencing everything from protocol upgrades and economic policies to validator behavior and community standards. A well-functioning governance system improves transparency, fairness, and trust, while poor governance can lead to confusion, stagnation, or centralization of power.

Solana’s governance is still in its early developmental stage. Like many blockchain networks, it did not launch with a fully mature or formalized governance framework. Instead, it has evolved gradually, shaped by community practices, technical constraints, and lessons learned. Refining Solana's governance is an ongoing and iterative process.

Solana’s ecosystem comprises diverse, overlapping stakeholder groups: token holders, stakers, users, validators, RPC operators, application developers, and core protocol engineers. Each group brings different perspectives, incentives, and goals to the table. While these incentives may align in some areas, they often diverge, particularly around resource distribution, protocol control, and economic policy.

In decentralized systems, governance is as much about social consensus as it is about code. While blockchains are often described as “code is law,” history has shown that when community consensus demands it, the code can—and does—change. This makes the design of governance mechanisms and the ability to evolve them over time just as important as the initial technical architecture.

This report aims to clarify the structure, evolution, and current state of governance on Solana. It offers a comprehensive view of how decisions are made within the network and how its governance compares to other blockchain ecosystems. The work is structured into four main sections:

• Elements of Solana’s Governance – Examines the core components of Solana’s governance process, including SIMDs, feature gate activations, and formal on-chain votes.
• Governance Voting Analysis – A detailed overview of all formal governance votes to date, including outcomes, voter behavior, and participation metrics.
• Challenges and Recommendations – An exploration of key issues facing Solana’s current governance model, accompanied by actionable recommendations where appropriate.
• Comparison with Alternative Networks – A look at how governance works in the peer ecosystems of Cosmos and Ethereum, highlighting practices that could inform improvements on Solana.

While the report flows best when read in order, each section is designed to stand alone and can be read independently.

Elements of Solana’s Governance

The table below provides an overview of Solana’s governance system, structured using an analytical framework adapted from the paper Analyzing Decision-Making in Blockchain Governance by Schädler, Lustenberger, and Spychiger (2023). We have tailored this framework to reflect the specific mechanisms and dynamics within the Solana ecosystem.

Modifications to the Solana protocol follow a multi-stage process that varies depending on the change's nature and impact. Key factors include whether the change is consensus-breaking, its impact on stakeholders, and the level of contention or complexity involved. A consensus-breaking change refers to any protocol update that causes nodes running different software versions to disagree on the blockchain's state. 

The following table outlines the typical steps involved in changes across different levels of magnitude. ‘Large changes’ are considered those that have a potential economic impact.

Below, we will describe the detailed processes of feature gate activations, SIMDs, and governance votes.

Feature Gate Activations

The core developer teams of Anza and Firedancer frequently ship new features, including syscalls, native programs, and economic changes that are consensus-breaking changes. These features are created, included in new client software releases, and deactivated by default behind a feature flag. The Feature Gate Program, which recently migrated to a Core BPF program, tracks each new feature as an account. A private key unique to each feature gate is owned by the core contributor associated with that feature gate. Once sufficient staked validators upgrade to the new release and it is considered stable, the runtime feature switch is activated manually with an instruction, and the feature goes live across all nodes in the network at the start of the next epoch. The exact order and timing of activations can be tracked through the feature gate schedule. Feature activation is cluster agnostic, with activations happening first on Testnet, then Devnet, and finally Mainnet, allowing confidence to be built in the new versions before final activation on Mainnet.

The ‘version floor’ is a cluster's current minimum supported software version. As new feature gates are activated, the version floor is raised to match the software release in which the feature was included. New feature activations on Solana follow a regular cadence, typically at epoch boundaries that fall within weekday business hours. Activations are paused during version transitions and resume roughly two epochs after 95% of stake has upgraded to a new minor release (e.g., from version 2.2 to 2.3).

Feature gate activations are non-backward compatible hard forks that require universal adoption to take effect. If a validator doesn't upgrade to a version that recognizes an activated feature gate, it cannot continue validating the global state and will diverge from the network.

Unlike Bitcoin or Ethereum, where a hard fork can result in a permanent chain split if disagreement, Solana’s approach ensures feature gates are activated cluster-wide at a specific slot. Validators must upgrade beforehand, preventing chain splits. So, while feature gates are hard forks in that they change consensus rules, they cannot lead to competing chains.

New client versions will also include many non-consensus-breaking changes, such as code refactorings and efficiency optimizations, which do not require feature-gating.

Solana Improvement Documents (SIMDs)

Solana Improvement Document (SIMD) proposals are the formal documentation necessary for any substantial change to Solana’s core components. "Substantial" changes are defined as those that typically alter the network protocol, transaction validity, or interoperability. Non-substantial changes, such as minor code refactoring or objective performance improvements, do not require proposals. Proposals should document the rationale for the feature and enough documentation to understand the implementation. 

While submitting SIMDs is permissionless, most are submitted by client team developers working full-time on core protocol improvements.

There are two types of proposals: 

• Standard Proposals: affect core Solana features (e.g., consensus, networking, and API interfaces)
• Meta Proposals: address processes or guidelines outside the codebase

SIMDs typically progress through idea vetting, drafting, review, and acceptance stages. A formal review occurs publicly on GitHub, with the proposal author being responsible for gathering feedback from relevant core contributors from both Agave and Firedancer client teams, who determine if it is accepted, revised, or withdrawn, considering security, trade-offs, and backward compatibility.

Authors are not obligated to implement their proposals, but it is generally suggested they do so as the best way to ensure successful completion. If accepted, proposals often include an associated tracking issue for feature implementation and will typically require activation through Solana’s feature-gate mechanism. 

While not all feature gate activations require a SIMD, the majority are accompanied by one to provide context, justification, and a standardized record of the proposed change.

Governance Votes

Significant protocol-altering SIMDs, particularly those impacting economic parameters, require governance votes. Solana’s governance process, led by experienced members of the validator community, focuses only on critical issues to maintain engagement and prevent governance fatigue. As a result, only a few votes occur each year.  

Governance votes primarily serve as a mechanism for gauging sentiment toward proposed changes. Allowing validators to signal their stance before full implementation helps guide development and minimize contention. Implementing a change without broad consensus could lead to friction, especially if more than one-third of the network resists adoption.

Voting is conducted using SPL tokens. Each active validator’s identity account is allocated tokens proportional to its active stake measured in lamports. The validator may then send these tokens to designated addresses representing different voting options, including an option to abstain. Validators are free to split their votes across multiple options—for example, allocating 80% to YES and 20% to NO—allowing them the flexibility to reflect the diverse preferences of their stakers. Once submitted, votes are final and cannot be changed.

In this structure, SOL token holders participate indirectly by delegating their staked SOL to validators whose voting choices align with their values or preferences. This is a proportional representation system in which validators can be considered elected representatives. Solana stakers delegate their stake to validators, and each validator's voting power is based on their active stake.

The Limits of On-Chain Governance

toly 🇺🇸

@aeyakovenko

·Follow

Replying to @garious14

There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

3:56 PM · Mar 17, 2025

7

Reply

Copy link

Read 1 reply

Governance on Solana is ultimately nonbinding and advisory. In practice, the actual vote occurs when validators choose which version of the software to run. While governance votes can indicate broad community support or opposition, they do not compel validators to adopt any specific code. Proposals may even change after the vote, and validators retain full control over what runs on their infrastructure. This dynamic means that governance is more about signaling consensus than enforcing outcomes.

Core contributors like Anza, Jump, and Jito and infrastructure providers like Helius and Triton wield significant informal influence in this context. Because validators are unlikely to oppose these groups and risk losing stake or falling out of sync with the network, these entities can effectively shape upgrade outcomes—whether or not they hold formal decision-making authority.

A fork could occur in an extreme scenario where validators refuse an upgrade. Ethereum’s DAO Fork in 2016, which led to the creation of Ethereum Classic, remains a cautionary example. As Solana’s governance process evolves, clarifying the relationship between signaling votes, software releases, and actual validator adoption will ensure transparency and avoid the tail risks of chain splits.

Governance Voting Analysis

Solana’s Early Governance: 2020-2022

Solana’s initial approach to governance looked very different from today’s framework. Early governance centered around the Feature Proposal Program, which allowed validators to vote on protocol changes using stake-weighted SPL tokens. Once a new feature release was available to be activated, validators were allocated voting tokens proportional to their active stake. By returning these tokens to a designated account during a two-week window, validators could signal approval for activating the proposed feature. Upon reaching a 67% stake threshold, the change would be directly enabled on-chain in the following epoch.

The Feature Proposal Program was used to conduct validator governance votes multiple times on both Testnet and Mainnet, most notably for activating the current inflation schedule.

Online records of these early governance votes are sparse, as the original Solana Forums have been taken offline and are now only accessible through archived versions on the Wayback Machine.

While this mechanism introduced a degree of on-chain coordination, it was widely criticized. Validators had no way to express dissent—only YES votes were counted, and there was no formal method to signal opposition or abstention. This system also created social pressure to approve changes, especially after significant engineering efforts had already gone into implementation. 

More importantly, the system offered no early signaling. This meant that complex features could be built without knowing whether they would be accepted, leading to inefficiencies and wasted development time.

Overall, while the Feature Proposal Program was an important early step in Solana’s governance journey, its limitations helped inform the development of more flexible governance mechanisms used today.

It is worth noting that several major economic changes during this early period—such as introducing priority fees with a 50% burn—were implemented without formal governance votes, reflecting a period when the governance system was still in its infancy.

Solana’s Current Governance: 2023 Onwards

Following the use of the Feature Proposal Program, Solana evolved into its current governance voting system. So far, five official governance votes have taken place:

• Initial Advisory Vote in October 2023
• SIMD-33 Timely Vote Credits in April 2024 by Bryan Ischo and Zantetsu, Shinobi Systems
• SIMD-96 Full Priority Fee to Validators in May 2024 by Tao Zhu, Anza
• SIMD-123 In-Protocol Distribution of Block Rewards by Justin Starry, Anza
• SIMD-228 Market-Based Emissions Mechanism by Tushar Jain and Vishal Kankani, Multicoin Capital, Max Resnick, Anza in March 2025

Initial Advisory Vote

A critical early decision in shaping Solana’s current governance framework was determining who should participate in the voting process. Three options were presented to the community:

1. Validator-only voting, with votes weighted by stake
2. Validators and stake accounts, allowing delegators to override their validator’s vote
3. Validators, stake accounts, and other stakeholders, such as RPC operators and developers

The advisory vote saw participation from over 170 validators, representing 14.3% of total stake. Of the stake that voted, over 70% supported validator-only voting, with 24% favoring a validator-and-delegator model. No minimum participation threshold was enforced for this vote.

Validator-only voting was favored as the most practical and efficient starting point, given that the infrastructure already exists and has been tested in practice. More complex systems involving delegators or other stakeholders were considered premature and potentially burdensome for a nascent governance process. The community acknowledged that alternative voting models could be introduced and refined through future proposals as governance matures.

Governance Voting Patterns

Since the initial advisory vote, there have been four further governance votes, with the same three voting options: YES, NO, and Abstain. These options indicate agreement with the proposed SIMD. For a vote to pass, at least two-thirds of the combined YES and NO votes must be in favor (i.e., YES). 

SIMD-33: Timely Vote Credits was approved with overwhelming support, receiving 98.4% YES votes. This uncontroversial consensus change addressed misaligned incentives by eliminating the benefit validators previously gained from submitting late votes, thereby improving network behavior and fairness.

SIMD-96: Full Priority Fee to Validators passed with 77.7% YES votes. This economic proposal aimed to discourage side-channel transaction processing by directing 100% of priority fees to validators. While effective in aligning incentives, it was somewhat controversial due to a modest increase in inflation and perceived favoritism toward validators over SOL holders.

SIMD-123: In-Protocol Distribution of Block Rewards was approved with 74.91% YES votes. The proposal introduced an optional, standardized mechanism for validators to distribute block rewards directly to stakers. Though several validators already did this through more manual methods, bringing it in-protocol sparked debate over competitive pressure, with concerns it could lead to a "race to zero" in block reward commission rates.

SIMD-228: Market-Based Emissions Mechanism failed to pass, with only 61.39% voting YES. The proposal aimed to make Solana’s inflation rate more responsive to staking participation, arguing that current emissions are too high, unresponsive to yield demand, and result in the network overpaying for security.

Opponents raised concerns about the economic viability of smaller validators and the added uncertainty it could introduce to staking yields. The vote proved highly contentious, generating extensive debate and highlighting differing views on Solana’s long-term economic model.

For detailed voting behavior, readers are encouraged to refer to open-source vote dashboards for SIMD-96, SIMD-123, and SIMD-228. Additionally, we provide a spreadsheet with the voting data available here.

Quorum thresholds of 33% stake participation—including abstain votes—were enforced for SIMD-228 and SIMD-123. In contrast, earlier proposals such as SIMD-96 and SIMD-33 had no minimum participation requirement, meaning they could pass regardless of how much of the total stake voted.

Participation Rates

Voting participation rates have shown an upward trend over time. The Initial Advisory Vote in October 2023 saw minimal engagement, with only 14.3% of the stake participating. Since then, participation has steadily increased, culminating in the March 2025 vote on SIMD-228, the Market-Based Emissions Mechanism, which reached a participation rate of 74.3%. The three other votes to date saw relatively consistent participation levels, ranging from 51.2% to 57.1%.

The vote on SIMD-228 marked the largest governance event in crypto history by both participant count and total market capitalization represented. At the time of the debate, Solana’s market cap was comparable to Bitcoin’s during the mid-2017 blocksize wars, underscoring the significance of the decision. A total of 281 million SOL, valued at $35 billion, participated in the vote, with over 900 validators submitting more than 1,000 votes. Notably, this was the first instance of major exchange validators—including Coinbase, Kraken, and Bybit—actively engaging in Solana’s on-chain governance, signaling a growing institutional presence in the network’s decision-making process. This recent uptick in participation, especially from U.S.-based entities, could also be partially attributed to a more favorable blockchain regulatory climate under the current administration.

Issues and Recommendations

In the next section, we will explore key challenges in the governance voting process and, where relevant, provide recommendations for improving transparency, security, and efficiency.

Lack of Participation from Stakers

A recurring concern in Solana’s governance process is the limited role of delegators in decision-making. While validators vote on proposals using stake-weighted governance power, there is no formal mechanism for delegators to express their preferences or override validator decisions. This can lead to situations where validator votes conflict with the interests of their delegators, leaving stakers without a direct way to influence governance outcomes.

Validators with thousands of delegators struggle to collect individual voting preferences, and staker engagement rates are typically low. Several validators partially address this by consulting with their largest delegators before voting and splitting votes based on their preferences. Others have experimented with custom tooling that mirrors the existing token vote system—issuing new governance tokens to their stakers based on their proportional stake. However, this remains a validator-specific solution rather than a standardized protocol-wide feature.

Those arguing against staker participation point out that most delegators are non-technical, rarely follow governance decisions closely, and lack the in-depth understanding of blockchain mechanisms and trade-offs required for informed decision-making. Supporters, however, contend that relying solely on validators creates a conflict of interest—it is unrealistic to expect a majority of validators to vote for proposals that benefit the network if those proposals come at the expense of their own economic incentives.

Potential improvements include better communication channels between validators and delegators, such as governance dashboards, sentiment-tracking tools, or even wallet notifications for governance events. A later section of this report will revisit this topic, examining the Cosmos ecosystem's approach.

Challenges in Governance Discourse

Effective governance in decentralized ecosystems relies on clear, high-signal communication. However, during the recent SIMD-288 proposal, heated debates, personal attacks, and factionalism created an unhealthy governance environment, ultimately hindering productive discourse. Discussions around key proposals on Solana can suffer from inefficiencies and deteriorating signal quality across different platforms. While technical discussions on GitHub and the official Solana forums provide structured and thoughtful debate, by the time conversations reach Discord and Twitter, meaningful discourse at times devolves into flame wars and ad hominem attacks, reducing the overall quality of decision-making.

Additionally, most participants only engage in the final days before the vote rather than take advantage of the full discussion period. Encouraging earlier participation and better structuring of governance timelines—such as ensuring that key discussions happen well in advance of the final voting window—could help mitigate these issues.

Governance calls proved effective, allowing for direct engagement, fast clarification, and reduced opportunity for trolling or misdirection. Strengthening moderation, fostering structured discussions, and emphasizing fact-based analysis over adversarial exchanges are critical in maintaining a constructive governance process.

Bundling of Governance Proposals

Governance decisions are often most effective when each proposal is voted on independently, allowing voters to consider each issue on its own merits. A key concern with bundling proposals is unconscious bias—voters who feel strongly about one issue may unintentionally let it influence their stance on others, even if they are unrelated. This reduces the likelihood of nuanced decision-making and could prevent otherwise beneficial changes from being implemented.

Another risk is that bundling increases operational complexity, making errors more likely. This was observed during the joint voting period for SIMD-228 and SIMD-123 when a small number of tokens intended for SIMD-123 were mistakenly sent to the abstain address for SIMD-228. Such errors, though rare, distort voting outcomes and undermine confidence in the governance process.

However, the counterargument for bundling proposals is that consolidating multiple decisions into fewer voting periods can help reduce voter fatigue and encourage higher participation rates. While this may improve engagement, it comes at the cost of clarity and precision in decision-making. Aditionally, wdhen bundled proposals are complex, they often require extended discussion and review periods before voting begins to give voters—especially those who typically engage at the last minute—enough time to understand and evaluate each component thoroughly.

A more effective approach may be to separate governance proposals whenever possible, ensuring that each issue is evaluated independently. If bundling is necessary, it should be justified clearly.

Voting Quorums

The role of a defined quorum in Solana governance votes has raised concerns. In practice, quorums can create perverse incentives, where participants strategically withhold their votes to prevent a proposal from reaching the required threshold. In the recent SIMD-228 vote, this was particularly evident among NO voters, who, during the first two epochs of voting, found abstaining to be a more effective strategy than actively voting against the proposal. 

The visibility of ongoing vote counts influences participation. Some validators may choose not to vote if the expected outcome already aligns with their preference. To prevent quorum manipulation, a potential improvement could be to delay vote visibility until the voting period ends.

Given these challenges, there is growing support for reevaluating or eliminating quorum requirements to encourage more straightforward and transparent governance participation.

Effects of SFDP

At the time of writing, Solana Foundation Delegation Program delegates SOL to 897 validators, representing 66% of all active validators on the network. The total amount delegated is 41.01 million SOL, 10% of the total staked SOL. Readers can refer to the Helius blog’s previous report on SFDP for full details of the program and its delegation strategies.

Under the current governance model, validators in the program effectively have their voting power amplified and vote on behalf of the Solana Foundation. Our internal analysis and public dashboard of the recent SIMD-288 governance vote confirm that SFDP stake plays an important role in voting outcomes. In this vote, SFDP stake was primarily used to vote NO against the proposal. If the SFDP-controlled stake that voted NO or abstained had instead voted YES, the proposal would have passed. If all SFDP controlled stake had remained neutral and abstained, the proposal would have still failed, but by a narrower margin—64.77% versus the actual 61.39% (with 66.6% required to pass).

Clarity on Criteria for Enacting Votes

The March 2025 governance votes originally included three proposals, SIMD-228, SIMD-123, and SIMD-218: Intermediate Vote Credits (IVC). IVC eliminates the need for validator-run mods that optimize Tower BFT (Solana’s variant of the pBFT consensus algorithm) voting credits by automatically backfilling credits for all parent blocks when validators vote on a child block.

During the discussion period, there was a growing consensus that SIMD-218 should not require governance approval. The change was widely considered a bug fix rather than a substantive protocol change, as it simply enhanced or corrected the Timely Vote Credits (TVC) upgrade. TVC had already passed a governance vote and demonstrated strong community support. An informal poll among validators on the Solana Tech Discord reinforced this view with near-unanimous agreement.

Additionally, engineers from Anza noted that SIMD-123: In-Protocol Distribution of Block Rewards was not an economic change as the name implies. The proposal introduced an optional, in-protocol method for distributing block rewards to stakers, formalizing a practice that several validators already performed through alternative methods and standardizing what had previously been an out-of-protocol activity.

This raises important governance questions:

• Who decides whether a proposal requires a vote? Currently, there is no official body or structured process for determining whether a proposal should go through governance or be implemented directly.
• What constitutes a “substantive protocol change” remains ambiguous. The line between a routine upgrade and a change that warrants formal governance intervention is blurry, with current definitions relying heavily on the somewhat vague notion of “economic impact.”

Security Issues

The current voting process for governance proposals relies on a third-party tool, solgov-distributor, developed and hosted by a community member, Laine. This tool is a fork of a Merkle-based token distributor originally developed by Jito. While Laine is a well-respected community member, reliance on an externally controlled tool introduces trust assumptions and security risks.

• Mutability – both the tool and its documentation are mutable, meaning they can be unilaterally modified at any time.
• Use of Validators’ Identity Keypairs – Validators are required to build the CLI and claim tokens using their validator identity keypairs, which are highly sensitive. Any process that depends on external software to interact with such critical credentials presents a security risk.
• Dependency on an Individual Maintainer – An official governance process should not have critical dependencies on external third parties without formal security guarantees or independent audits.

Alternative Voting Mechanisms

There is an existing SPL Feature Proposal tool (documentation here), which was initially designed to facilitate on-chain governance. However, recent governance processes did not follow this approach. Instead, solgov-distributor was used, raising questions about whether this additional tool was necessary.

In principle, the SPL token system already provides a native method for distributing governance voting power. The process initiator could simply distribute SPL tokens to all validators, allowing them to cast votes using the standard spl-token CLI, rather than relying on an external tool. This would eliminate unnecessary dependencies and enhance trustlessness in the voting process.

Upcoming On-Chain Governance Tooling: SIMD-133

The upcoming SIMD-133: Get Epoch Stakes, which is scheduled for activation on Mainnet shortly, introduces new governance tooling that allows programs to retrieve stake weights on-chain. Currently, on-chain programs lack knowledge of the current epoch's stake distribution and how much stake is delegated to each vote account.

With SIMD-133, governance programs can take on-chain snapshots of validator stake amounts via a new sysvar, eliminating the need for off-chain or manual stake verification processes. This significantly streamlines the existing governance flow and removes the need for manual stake reconciliation.

Comparison with Alternative Networks

Cosmos

Cosmos SDK chains offer a delegator-centric governance model, where stakers can override their validator’s vote directly through popular wallets such as Keplr and Leap. This means that while a validator initially casts a vote with its full stake weight, delegators who disagree can reallocate their share of the stake to a different voting option. For example, if a validator holds 2% of the total stake, but a delegator with 1% of stake weight disagrees, they can vote separately, reducing the validator’s effective vote to 1% and shifting their 1% elsewhere.

This system ensures delegators always have the final say, creating a transparent, user-friendly, and efficient governance process. Governance participation in Cosmos is highly visible, as voting is integrated directly into wallets and block explorers, making it easily accessible to all stakeholders.

A relevant example of differing voter behavior between stakers and validators occurred during the Cosmos ATOM Halving vote (Proposal 848, Nov 2023), where the proposal sought to reduce the max inflation rate to 10%:

• 94.93% of stakers voted YES, supporting the inflation cap.
• Only 53.44% of validators voted YES, as many sought to preserve higher revenue streams.

This divergence highlights the importance of direct staker participation, ensuring that governance decisions reflect broader community sentiment rather than just validator preferences.

The Cosmos governance module is embedded at the protocol level, reinforcing its role as a core feature of the blockchain. Certain governance decisions can be automatically executed on-chain, enhancing transparency and accountability. 

While this model offers a democratic governance structure, it depends on active participation and assumes that delegators have the time and knowledge to make informed decisions. Cosmos provides a compelling alternative governance framework that Solana could study to determine potential improvements.

Ethereum

Ethereum governance follows a social, off-chain process rather than direct stake-based voting. The decision-making process primarily relies on Ethereum Improvement Proposals (EIPs), core developers, and community consensus.

Changes to Ethereum are proposed through EIPs, equivalent to Solana’s SIMDs. These EIPs outline new features, standards, or upgrades to the Ethereum protocol. Ethereum Request for Comments (ERCs) define standards for application-layer features, such as ERC-20 tokens and ERC-721 NFTs. These proposals are discussed openly in Ethereum research forums (Ethereum Magicians), popular Ethereum events (e.g., Devcon, ETHDenver, ETHCC), GitHub, and core developer calls. The wider community plays a role in governance by debating proposals on platforms such as Discord, Farcaster, and X.

Unlike Cosmos or Solana, Ethereum does not use stake-based or token-voting governance for protocol decisions. Since Ethereum transitioned to Proof-of-Stake, validators have played a more active role in consensus but do not formally vote. Instead, a rough consensus is reached through technical debates and broad community support. Ethereum’s protocol changes depend heavily on core developers maintaining Ethereum’s execution and consensus clients (e.g., Geth, Nethermind, Prysm).

Major upgrades are activated through hard forks, which require validators and node operators to upgrade their software. Validators enforce network rules by choosing whether to adopt new upgrades. Although rare, if a proposed change is controversial and lacks consensus, it could lead to a chain split, as seen in past forks like the DAO Fork (2016, Ethereum Classic) and, to a lesser extent, Ethereum’s transition to Proof-of-Stake (2022, EthereumPoW).

Ethereum’s social governance model prioritizes technical consensus and community discussion over formal voting mechanisms. While this has kept Ethereum flexible and decentralized, it also means that changes require long, drawn-out discussions and social coordination rather than direct token-based governance. Additionally, there is no formal way for ETH holders or stakers to vote on proposals, limiting direct user influence.

Conclusion

Solana’s governance system is still developing and is shaped by real-world experimentation and community input. This report examined its core components—SIMDs, feature activations, and on-chain voting—alongside a review of all formal votes to date, key challenges, and comparisons to peer networks like Cosmos and Ethereum. 

The Solana ecosystem is rooted in a strong engineering-driven culture that values rapid iteration and execution over prolonged debate. While this high velocity of upgrades sets Solana apart from many peer networks, it also creates tension with governance models that rely on extended community discussion and broad social coordination, presenting unique challenges for balancing speed with inclusive decision-making.

Solana’s governance is still taking shape, but one thing is clear: community engagement has never been higher. As more stakeholders actively shape the network, Solana has a unique opportunity to build a governance model that matches its ambition, speed, and growing ecosystem.

Additional Resources

• Measuring Solana’s Decentralization: Facts and Figures - Helius Blog
• Solana Governance Think Tank
• Blockchain Governance: Programming Our Future - Fred Ehrsam