Solana Launches Onchain Governance With SGPs, Giving Validators a Formal Vote on Protocol Direction

Solana SOL$118.97+1.0% has launched a formal onchain governance system for its validator set, giving participants a direct mechanism to register directional mandates on protocol decisions for the first time. The Solana Foundation announced the system live on July 1, with governance.solana.com accepting proposals immediately.

The system is called Solana Governance Proposals (SGPs). It is fully onchain, stake-weighted, and verified via Merkle proof, with every vote cryptographically tied to actual delegated SOL stake rather than a token-holder count.

SGPs vs SIMDs: Ecosystem Signals vs Technical Specs

SGPs are deliberate ecosystem signals, not protocol-change specs. The distinction matters: the existing Solana Improvement Document (SIMD) process continues to handle technical, implementation-level changes (what code ships and how). SGPs answer the upstream question of whether a direction should be pursued at all.

The official proposals repository puts it plainly: SGPs answer "Should we do this?" while SIMDs answer "How exactly do we do this?" A passed SGP is a mandate from stake-weighted community consensus; the detailed engineering work that follows is then specified through one or more SIMDs. The Alpenglow consensus redesign is cited in the repo as the kind of decision SGPs are built for: a major directional bet that needed validator buy-in before implementation work could begin in earnest.

The Foundation noted that SGPs should be "signals from the ecosystem" while SIMDs remain "technical in nature and small in scope." Core developers continue shipping independently; an SGP vote is triggered only when 15% of active stake signals it matters.

How the Process Works: 11 Epochs From Support to Outcome

Any validator with at least 100,000 SOL delegated can submit a proposal, making the system permissionless for any sufficiently large validator. Solana Compass data tracked roughly 700 unique validators actively voting on blocks in the week of June 25–30, the electorate these governance mechanics are designed to serve.

The lifecycle runs through two core onchain programs: ncn-snapshot and svmgov. Operators independently read the ledger and generate identical Merkle trees of all validator stake. Once enough operators agree on the same snapshot, a ConsensusResult is published onchain. Governance votes are then verified against that Merkle root; no stake can be double-counted or fabricated.

After an SGP is posted, it must first gather support. Once 15% of active stake signals support, a fixed 11-epoch process begins: 7 epochs for community discussion, 1 epoch for the NCN snapshot that establishes voting weights, and 3 epochs for the vote itself. A Solana epoch runs approximately two days. An SGP that never clears 15% support expires without going to a vote.

The approval bar is a supermajority: at least two-thirds of "For" plus "Against" stake must vote For. Abstain votes are excluded from the denominator. There is no quorum requirement; only the ratio of decisive votes matters.

Delegators Can Override Their Validators

One of the system's more notable design choices is delegator sovereignty. If a validator votes against a delegator's preference, or does not vote at all, the delegator can override that vote using their stake account's Merkle proof at governance.solana.com.

The Solana Foundation described it this way: "Delegated your stake but disagree with how your validator voted? Or has your validator not voted at all? Delegators can now override the validator based on the delegator's stake weight." Overrides are proportional to the delegator's staked SOL, so the system reflects actual economic weight rather than headcount. Delegators do not need to unstake or move their SOL to participate.

NCN Snapshot and svmgov: The Two Programs Behind SGP Voting

The technical architecture splits across two programs. The ncn-snapshot program establishes a verifiable, consensus-backed Merkle root of all active stake each time a vote is called. The svmgov governance program uses those Merkle roots for stake-weighted proposal voting. Development was led by @solanaturbine, with @exo_solana handling the NCN implementation.

Both programs are deployed on mainnet with published program IDs: ncnwF8AgynRcdEnGLcprSQNaKvgSMTgk3yPRc8cf9Zf for the NCN snapshot and govYkyQ3ePtGULAtY6V75qjWE8UH4vCUVQ1W4HdCAZU for svmgov. The codebase is open source under an Apache-2.0 license.

Why a Separate Layer From SIMDs

Solana has had informal signaling mechanisms: validators have historically adopted or rejected software upgrades by simply choosing which client version to run. That approach works for binary decisions, but provides no mechanism for nuanced directional mandates or for capturing the views of stake delegators rather than just validators.

Earlier this year, debate over whether to adjust Solana's inflation schedule exposed the absence of a formal process. Proposals surfaced through podcasts, forum threads, and offchain polls before eventually reaching a SIMD vote, with results contested partly because the framing of the question itself was disputed. SGPs are designed to separate the "do we want this?" layer from the technical specification layer, sitting above the SIMD process that continues to govern protocol implementation.

The proposals repository currently contains only a template; no SGPs have been submitted yet. The first proposals will be the real test of whether the 15% support threshold filters for genuine stake-weighted consensus or proves a high bar to clear for all but the most widely-backed initiatives.