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.
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:
- 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.
- 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.
- Voting: validators vote stake-weighted with yes, no, or abstain — within a fixed window measured in epochs (one epoch lasts roughly two days).
- 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
| SIMD | SGP | |
|---|---|---|
| Question | How do we build it? | Do we want it? |
| Form | Pull request in the GitHub repository | On-chain proposal |
| Who decides | Review by maintainers and client teams; validator votes on big questions | Stake-weighted vote of all validators, with delegator override |
| Thresholds | Process per SIMD-0001 | 100,000 SOL stake, 15% support, two-thirds of yes+no stake |
| Outcome | Technical specification | Directional 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
- Solana Governance — official documentation
- governance.solana.com
- solana-foundation/solana-governance on GitHub
- solana-foundation/solana-improvement-documents on GitHub
Related articles
- Solana launches on-chain governance (SGP launch) — the launch news
- SIMD-228: market-based emission explained — the big emission debate
- Alpenglow: Solana’s new consensus explained — the most prominent approved SIMD
- Solana validator selection — your vote starts with your delegation
- BonkDAO governance attack — why DAO governance carries different risks
- Glossary: SIMD · Validator