Solana Validators Gain Formal Onchain Vote on Protocol Direction

The Solana Foundation switched on Solana Governance Proposals early on Thursday, opening a stake-weighted onchain route for validators to put core protocol questions to a formal vote. The new SGPs are fully onchain, stake-weighted, and verified by Merkle proof, per the Foundation’s Solana Foundation’s launch thread on X.

Any validator with at least 100,000 SOL delegated can register a proposal. Once 15% of active stake backs it, the question moves into a fixed, eleven-epoch onchain ballot decided by a two-thirds supermajority. SGPs run in parallel to the long-standing Solana Improvement Documents process rather than as a replacement for it, and they change what kind of question Solana can settle onchain in the first place.

How an SGP Is Built and Triggered

SGPs sit on two onchain programs. An ncn-snapshot program builds a canonical tree of validator stake weights from the Solana ledger, while a voting program called svmgov checks every ballot against that tree with Merkle proofs, per the Defiant’s report on the launch. Validators and delegators see the system through a governance dashboard built on top of those programs.

To take an SGP onchain, a validator vote account needs at least 100,000 SOL staked, and the proposal document has to be locked at a specific commit SHA so it cannot be edited after submission, the official SGP repository and policy README states in its policy documentation. Corrections require a new SGP that supersedes the old one. The lifecycle runs from idea through draft to support to voting, then either accepted, implemented, and activated, or rejected.

A proposal that fails to attract the 15% support threshold moves into an Expired side state without ever opening for a vote. Most of the work in the system’s design happens before a single ballot is cast.

How an SGP Differs From a SIMD

SGPs answer a different question than SIMDs. The SGP repository defines an SGP as capturing a stake-weighted directional decision that records what the community wants, separate from the technical detail of how to build the feature. SIMDs cover the implementable specification that core developers review line by line.

The split matters because Solana’s biggest live upgrade sat awkwardly inside the SIMD-only path. Alpenglow, the new consensus protocol from Solana developer Anza, was originally taken to a validator vote as a SIMD before the design had enough technical detail to clear SIMD review, the SGP repository points out. A future Alpenglow-style change could route through an SGP for the directional signal first, with the detailed SIMDs trailing once engineering matured. The governance system explicitly cites this scenario as the canonical use case.

A yes on an SGP is a mandate to proceed. The implementation work that follows is normally specified in one or more SIMDs.

The Solana Governance Proposals repository, hosted by the Solana Foundation, sets that policy for the svmgov program. The directional vote runs alongside rather than ahead of the SIMD process in normal cases.

SGPs stay opt-in rather than mandatory. If core developers propose a SIMD and fewer than 15% of stake backs a stakeholder vote, the SGP is skipped and the SIMD continues through technical review under the Solana Improvement Documents repository. The 15% bar is meant to keep votes focused on questions with genuine validator-set or staker interest, the repo explains, rather than forcing every protocol question through a stakeholder ballot.

Three Numbers That Run Every SGP Vote

Once a proposal clears the 15% support threshold, the onchain process runs on a fixed clock measured in epochs, where a Solana epoch is approximately two days. The discussion phase lasts seven epochs, with the document locked and the community in debate but no votes yet cast. An NCN snapshot occupies one epoch to capture the stake state that determines each validator’s vote weight, and voting then opens for three epochs.

The lack of a quorum rule is the most unusual parameter on that table. Most onchain governance systems apply a turnout floor before a result is treated as valid. SGPs skip that filter entirely. The system treats abstention as silence and counts only decisive votes in the denominator, so a proposition passes whenever the supermajority math holds, regardless of how much of the total stake showed up.

What the No-Quorum Rule Changes

In a system with a quorum, a low-turnout vote can fail outright even if every participant votes yes. SGPs do not have that trip wire. The bar for any single position is high at 66.67% of decided stake, but the secondary gate of enough people showed up is absent. The design is a deliberate trade.

The trade has a particular fit for Solana’s validator set, in which a relatively small number of large validators hold a disproportionate share of stake. If a cluster of top validators coordinate to support an SGP while a critical mass of smaller validators abstains, the proposal can still meet the supermajority. The SGP repository frames this as a feature rather than a bug: the 15% trigger and absent quorum together ensure the network only votes on topics with genuine stakeholder interest, rather than forcing broad turnout on matters that few stakeholders prioritize.

The system still leaves one check on that power. The Defiant’s report on the launch says delegators who disagree with their validator’s vote, or whose validator did not vote at all, can override that choice using their own stake weight through the governance page. The override window closes with the three-epoch voting period.

Where SGPs Land in Solana’s 2026

The SGP launch lands inside a heavy Solana upgrade cycle. Anza, one of Solana’s core development firms, brought Alpenglow to a community test cluster on May 11, calling the upgrade the biggest consensus change in Solana’s history and inviting validator operators to spin up the new design ahead of mainnet. The upgrade targets confirmation times of about 150 milliseconds and would remove both Proof of History and on-chain vote transactions from Solana’s core process, according to a separate crypto.news report on the testing rollout.

The same Alpenglow proposal introduces a Validator Admission Ticket at 1.6 SOL per epoch, paid by validators each time they enter the consensus set. That is a meaningful change in validator economics, the kind of long-term economic shift the new SGP process is designed to capture a directional vote on before the SIMD path defines the technicals. The launch also follows a run of Solana Foundation initiatives tied to institutional validator participation, including a native payments rail for subscriptions and allowances and MoneyGram joining the network as a validator, per the Defiant.

The author of any future SGP needs the same 100,000 SOL floor that defines today’s eligibility. The broader the validator set, the more diverse the pool of parties able to take an SGP onchain at all. SGPs go live against that backdrop, with both the directional and the technical tracks now formally on the table.

Frequently Asked Questions

What is the difference between a Solana SGP and a SIMD?

An SGP captures a directional, stake-weighted onchain vote on whether Solana should pursue a path, while a SIMD is the technical specification of how a change is built and is reviewed by core developers. The SGP repository frames an SGP as the yes, pursue this signal and a SIMD as the implementable design.

What happens if fewer than 15% of stake supports an SGP?

Per the SGP repository, the proposal moves to an Expired side state without ever opening for a formal vote, and any underlying SIMD continues through normal technical review without interruption.

Can delegators override their validator’s SGP vote?

Yes. According to the Defiant’s report, delegators who disagree with their validator’s vote, or whose validator did not vote at all, can override that choice using their own stake weight through the governance page during the three-epoch voting window.

Does an SGP passing automatically change the protocol?

No. A passing SGP is a mandate to proceed, but the actual implementation is normally specified in one or more SIMDs and shipped through client releases after the directional vote resolves. The SGP repository is explicit on this point.

Disclaimer: This article is for informational purposes only and does not constitute financial, investment, or legal advice. Cryptocurrency markets carry substantial risk; consult a qualified professional before acting on any decision described here. Figures are accurate as of publication on July 2, 2026.