Solana governance explained: SIMDs, SGPs, and how the network votes

How Solana votes: SIMDs as technical proposals, SGPs as on-chain governance with a 100,000 SOL bar, 15% support phase, and delegator override. Explained.

SOLANA·HUB ·

How does Solana actually vote? Through two instruments that are often confused: SIMDs for the technology, SGPs for the direction. This article explains both — and where your vote as a staker counts.

Short answer: Solana makes protocol decisions in two stages. An SGP (Solana Governance Proposal) has been the on-chain directional vote since early July 2026: a validator with at least 100,000 SOL in stake submits it, voting opens once 15% of active stake supports it, and a proposal passes with at least two-thirds (66.67%) of the yes+no stake — there is no quorum. A SIMD (Solana Improvement Document) is the technical proposal behind it: a pull request in the official GitHub repository describing how a change gets built. Delegators can override their validator’s vote with a Merkle proof.

In plain terms: The SGP is the stakers’ referendum (“Do we want this?”). The SIMD is the engineers’ blueprint (“This is how we build it”). Direction first, blueprint second — and anyone who has delegated SOL gets a say on the directional question.

Two layers: direction and technology

A network like Solana has to answer two very different questions. First: should something change — say, the inflation curve or the consensus mechanism? Second: how exactly is the change built without endangering the network? Solana deliberately separates these questions. Since July 2026, the directional question is answered by SGPs on-chain. The technical question is answered by SIMDs in an open review process on GitHub.

SIMD: the technical proposal

SIMD stands for Solana Improvement Document. Don’t let the word “document” fool you: a SIMD is a proposal — a concrete suggestion to change the protocol, not a mere reference text.

The path of a SIMD looks like this:

  • Discuss the idea: proposals are debated publicly before being formally submitted.
  • Pull request: the proposal lands as a pull request in the official repository solana-foundation/solana-improvement-documents. The process itself is defined in SIMD-0001.
  • Review: maintainers and the developer teams behind the validator clients check the proposal for feasibility, security, and side effects.
  • Votes on big questions: far-reaching SIMDs were decided by stake-weighted validator votes even before the SGP system — but organized ad hoc, without a unified on-chain process.

Two examples show the range. SIMD-228, the proposal for market-based emission, failed a stake-weighted vote in March 2025: roughly 61% voted yes, while 66.67% was required — at a record participation of roughly three quarters of active stake. Alpenglow, Solana’s new consensus, by contrast, was approved as SIMD-0326 in September 2025 with over 98% of the votes cast. These ad-hoc mega-votes were one of the reasons to formalize the process.

SGP: the on-chain vote, step by step

Since early July 2026, directional questions have a fixed path: Solana Governance Proposals. The entire flow is on-chain; the tooling is available at governance.solana.com along with documentation and open-source code.

This is how an SGP works:

  1. Submission: a validator vote account needs at least 100,000 SOL in stake to bring a proposal on-chain. The bar filters spam without limiting access to a handful of giants — delegated stake counts too.
  2. Support phase: the proposal needs backing from at least 15% of active stake. Only then does voting open. Topics without broad interest never reach the ballot.
  3. Voting: validators vote stake-weighted with yes, no, or abstain — within a fixed window measured in epochs (one epoch lasts roughly two days).
  4. Result: a proposal passes when yes votes reach at least two-thirds (66.67%) of the yes+no stake. There is no quorum. The result is recorded on-chain and can be verified with a Merkle proof.

Important context: an SGP moves no funds and writes no code. It answers the directional question — the technical implementation follows afterwards via the SIMD path.

Delegator override: you can outvote your validator

Stake-weighted initially means: your validator votes with all the stake entrusted to it by delegators — yours included. The SGP system builds in a counterweight the Solana Foundation calls “staker sovereignty.”

As a delegator, you can vote yourself using the Merkle proof of your stake account. Your share of stake is then deducted from your validator’s vote and counts the way you vote — even if the validator has already voted or abstains. That makes choosing a validator more than a yield question; it is a governance decision. What to look for is covered in our article on validator selection.

SIMD and SGP compared

SIMDSGP
QuestionHow do we build it?Do we want it?
FormPull request in the GitHub repositoryOn-chain proposal
Who decidesReview by maintainers and client teams; validator votes on big questionsStake-weighted vote of all validators, with delegator override
ThresholdsProcess per SIMD-0001100,000 SOL stake, 15% support, two-thirds of yes+no stake
OutcomeTechnical specificationDirectional decision on-chain

Protocol governance is not DAO governance

A common misconception: “Solana governance” and “DAO governance on Solana” are two different things.

  • Protocol governance (SGPs, SIMDs) runs the network itself — consensus, emission, fees. Voting power comes from staked SOL that secures the network.
  • DAO governance runs individual projects and their treasuries under their own token rules. Whoever buys the governance token buys voting power.

July 2026 showed how different the risks are: BonkDAO lost roughly 20 million US dollars to a malicious proposal that took the DAO’s regular voting path — no smart-contract bug, just purchased voting power meeting low participation. Solana’s protocol governance is structured differently against this pattern: an SGP controls no treasury, the 15% support threshold prevents quiet votes, and the delegator override spreads voting power across all stakers rather than just token buyers. That does not make it invulnerable — but the attack surface is fundamentally different.

What this means for you

If you stake SOL, you are part of this governance — whether you want to be or not. By default, your validator represents you. If you disagree with its line, you have two levers: switch validators or vote yourself via the override. The thing to watch is which directional questions become the first SGPs to clear the 15% threshold — for instance, the emission debate that has been contested for years.

Note: Not financial advice.

At a glance

  • SIMD = Solana Improvement Document: the technical proposal as a pull request, vetted in open review.
  • SGP = Solana Governance Proposal: the on-chain directional vote, live since early July 2026.
  • SGP rules: 100,000 SOL stake to submit, 15% support of active stake, two-thirds of yes+no stake to pass, no quorum.
  • Delegator override: stakers can outvote their validator via Merkle proof.
  • Protocol governance is not DAO governance: SGPs run the network, DAOs run project treasuries.

Sources

#governance #simd #sgp #voting #validator #staking