On July 1, 2026, Solana Foundation moved network governance onchain: its new Solana Governance Proposals (SGP) system runs on two programs deployed onchain, and Solana’s governance documentation describes validators creating proposals and voting on protocol-level decisions that finalize once a consensus result is published onchain.
Key Takeaways
- A validator vote account needs at least 100,000 SOL staked to open or submit an SGP onchain, per Solana Foundation’s SGP repository.
- A proposal only opens for a vote once it clears 15% of active cluster stake support.
- Voting is stake-weighted and verified by Merkle proof against an onchain ConsensusResult, per Solana’s governance documentation.
- Delegators can override their validator’s vote, or a non-vote, using their own stake weight.
- Once the support threshold is met, the process runs a fixed 11 epochs before the outcome is final.
What Happened?
Validators create proposals, other validators support them, and once consensus is reached a ConsensusResult is published onchain, according to Solana’s governance documentation at docs.governance.solana.com. That moves protocol-direction decisions from off-chain forum discussion into a verifiable onchain vote.
The rollout sits alongside a broader run of validator and staking-focused activity across Decentralized Finance Markets, where onchain voting rights increasingly attach directly to staked positions rather than off-chain forum polls. The SGP process sits apart from Solana Improvement Documents (SIMDs), the technical-review track core developers already use, per Solana Foundation’s SGP repository.
Under the mechanism, any validator vote account with at least 100,000 SOL staked can open a proposal. That proposal moves from a support-gathering stage to an active vote only after it clears 15% of active cluster stake support, a threshold documented identically in both the governance docs and the SGP repository.
The system is built on two onchain programs, per Solana’s technical documentation: the ncn-snapshot program, which establishes verifiable validator stake weights, and svmgov, which handles the vote itself. NCN stands for Node Consensus Network, the snapshot layer that feeds the vote. Whitelisted operators each independently read the Solana ledger and build an identical Merkle tree of every validator’s stake, and once a ConsensusResult is published onchain, validators prove their stake weight against it with a Merkle proof when they cast a vote.
1/ Solana onchain governance is live🗳️
— Solana Foundation (@SolanaFndn) July 1, 2026
Validators can now propose, support, and decide core protocol decisions via Solana Governance Proposals (SGPs)
These are fully onchain, stake-weighted, and verified by Merkle proof 👇 pic.twitter.com/9Lpskle5L6
Delegators Get an Override
A stake account’s Merkle proof isn’t just for validators. The documentation states that individual stakers can override their validator’s vote using their own stake account Merkle proof, which the Foundation frames as preserving “delegator sovereignty.” Individual stakers can override their validator’s vote using their stake account Merkle proof, ensuring delegator sovereignty.
That override matters because opening a proposal is gated at a stake level concentrated among larger validators. Delegators who disagree with how their operator voted, or whose operator abstained entirely, are not locked out. They can cast their own weighted vote independent of the validator they staked with.
The proposal-opening bar and the delegator override function as two ends of the same design: one restricts who can start the process, the other keeps the vote tied to the full base of staked SOL, not just the validators who chose to participate.
SGPs Are Not SIMDs
Solana Improvement Documents (SIMDs), the existing process core developers use for technical protocol specification, answer a different question than an SGP. The SGP repository states an SGP asks “Should we do this?” and is decided by a stake-weighted onchain vote, while a SIMD asks “How exactly do we do this?” and is decided by technical review from core developers. The repository frames an SGP as the tool to use when core developers need a directional signal from stakeholders, a different question than the technical “how” a SIMD answers.
That division keeps low-level protocol engineering inside the existing developer review process. After the 15% support threshold is met, the onchain process runs for a fixed 11 epochs, split into 7 epochs of discussion, 1 epoch for the NCN snapshot, and 3 epochs of voting, before the result is final. On Solana’s roughly two-day epoch length, that cadence stretches a proposal’s path to finality to several weeks, building in a deliberation window before any onchain outcome locks in.
Implications for Validator Governance
The Merkle-proof design is the more consequential change buried under the vote mechanics. Off-chain governance forums have historically relied on validators self-reporting or being polled about their stake positions, the same trust assumption that shapes Self-Custody Wallet around who actually controls a given stake. A whitelisted-operator Merkle tree checked against a published ConsensusResult replaces that self-reporting with a cryptographic proof any participant can verify independently, shifting governance legitimacy from “trust the forum tally” to “the chain itself can attest to the vote.“
The proposal-opening threshold is a gatekeeping choice, not a neutral technical constant, and it concentrates proposal-initiation power among validators large enough to clear that stake bar, even as the cluster-support requirement and the delegator-override function pull the eventual vote back toward the broader staked base. Framed against the SGP/SIMD split, the design reads as an attempt to let stakeholders set direction without handing them line-item control over protocol engineering, which stays with core developers.
CoinLaw’s Takeaway
This launch formalizes something Solana previously handled through informal forum consensus and validator signaling: a verifiable, onchain record of who supported a given protocol direction and by how much stake. The 11-epoch cadence is the clearest signal of intent. A network capable of shipping changes quickly chose to build in roughly three weeks of discussion, snapshot, and voting before a stake-weighted outcome becomes binding, trading speed for a paper trail that can’t be disputed after the fact.
The design’s real test will be whether the entry bar and the delegator-override mechanism actually balance each other in practice, or whether proposal-setting ends up dominated by the same small set of large validators who already carry outsized influence over network operation.
Delegator override gives individual stakers a documented path to counter a validator’s vote, but it depends on stakers actually exercising it rather than defaulting to whatever their validator does. This is infrastructure governance mechanics, not a signal about SOL as an asset, and nothing here should be read as guidance on holding or trading the token.
