Solana activated its first-ever native on-chain governance system on July 2, giving the network’s more than one million SOL stakers a formal, cryptographically verified path to override their validators’ votes — a structural shift away from six years of foundation-led, off-chain decision-making for one of the largest proof-of-stake blockchains in the world. Solana Foundation governance proposals
The new system, called Solana Governance Proposals (SGPs), makes Solana the latest major Layer 1 network to replace informal consensus with binding on-chain votes — joining Polkadot, Tezos, MakerDAO, and Compound in formalizing how protocol-level decisions get made. The distinction from those predecessors: Solana’s design gives individual delegators a direct override right, so voting power cannot be fully captured by the validator operators who run the nodes on their behalf.
SOL responded sharply. The token was trading around $82 at the time of publication, up roughly 22% over the prior week, making it one of the few large-cap tokens to gain while the broader crypto market traded flat or lower. SOL price July 2026 Open interest in SOL futures surged more than 17% in 24 hours to a five-week high of approximately $2.3 billion, according to Santiment SOL futures data — a significantly larger move than comparable metrics for Bitcoin or Ethereum over the same window.
How Merkle Proofs Make Every Vote Auditable Without a Central Tallier
The SGP system’s core technical innovation is that votes are not recorded by a trusted off-chain service or a foundation-controlled database — they are verified cryptographically on the Solana blockchain itself.
Two programs underpin the system. The first, ncn-snapshot, is a Node Consensus Network program that builds a canonical Merkle tree of validator stake weights directly from the Solana ledger. A set of whitelisted operators independently construct these trees and vote on a consensus snapshot; once they agree, the result publishes on-chain. The second program, svmgov, is the voting engine: every ballot a validator casts is accompanied by a Merkle proof — a path of cryptographic hashes from that validator’s ledger entry to the Merkle tree root — which svmgov verifies on-chain before counting the vote. Solana governance documentation
A Merkle proof makes it possible to confirm a validator’s stake balance is part of the canonical snapshot without reprocessing the entire ledger, which would be computationally prohibitive. The result is that the vote tally is publicly auditable by anyone, and no intermediary can alter the count after the fact.
Each proposal document is tied to a specific, immutable Git commit. Once a proposal enters the voting phase, the document cannot be changed; if a correction is needed, a new SGP must be filed to supersede the original.
What Staker Sovereignty Actually Means in Practice
In Solana’s delegated proof-of-stake model, most SOL holders do not run validator infrastructure themselves. They assign their stake to validators and collect staking rewards while validators vote on protocol decisions using that delegated stake. Before SGPs, there was no formal mechanism for a delegator to disagree with their validator’s vote — the validator’s position was the position.
Under the new system, any delegator who disagrees with how their validator voted — or whose validator chose not to vote at all — can cast a ballot directly, weighted by their own proportional stake. The Solana Foundation calls this “staker sovereignty.” Nick Almond, the Jito governance lead, described the design as intended to “grant ultimate sovereignty to stakers” by ensuring they can always escalate contentious decisions beyond their validator’s judgment.
The practical effect: voting power stays anchored to actual token ownership rather than to the operators running network infrastructure, which is the most common failure mode in large delegated-stake systems.
How a Proposal Goes from Idea to Binding Mandate
The proposal lifecycle has five stages and a strict timeline once the support threshold is met.
A proposal begins as an idea in SGP governance proposals repo GitHub Discussions. When it is formalized as a pull request, it becomes a Draft. It then enters a Support phase, during which other validators must signal backing. Only after at least 15% of the network’s total active stake has signaled support does the proposal advance — this filter keeps low-interest ideas from consuming network attention while letting developers continue shipping routine technical changes without a network-wide vote.
Once the 15% threshold is crossed, a fixed 11-epoch process begins: seven epochs for extended community discussion, one epoch for the NCN snapshot that locks in stake weights, and three epochs for the formal vote. One Solana epoch lasts approximately two days, so the full process from threshold to result takes roughly 22 days.
To pass, a proposal needs at least two-thirds of the participating stake — “For” plus “Against,” with abstentions excluded from the denominator. A passing SGP is described in the governance documentation as “a mandate to proceed,” with subsequent engineering work handled through one or more Solana Improvement Documents that specify the technical implementation.
What the $7.7 Million Proposal Threshold Gates
Only a validator with at least 100,000 SOL delegated to its vote account — worth approximately $7.7 million at current prices — can file a formal SGP. That threshold is a deliberate spam deterrent: the Solana network currently processes a high volume of economic activity, and without a meaningful cost of entry, low-quality proposals could flood the governance system and exhaust validator attention.
Multicoin Capital managing partner Tushar Jain, speaking at a community presentation, framed the broader goal as addressing “the current ambiguity issues in Solana governance” — a reference to prior contentious situations, including the SIMD-0096 priority fee proposal that raised concerns about potential validator coordination and the SIMD-0228 inflation schedule overhaul that drew approximately 74% validator turnout before ultimately failing.
Critics of the threshold note it concentrates direct proposal power in larger validators and institutional stakers. Smaller SOL holders retain indirect influence through their choice of which validator to delegate to and through the delegator override mechanism if their validator’s behavior conflicts with their preferences — but they cannot themselves initiate a formal proposal.
How Does Solana’s System Differ from a Standard Blockchain Vote?
SGPs and the existing Solana Improvement Documents (SIMDs) serve distinct purposes in a two-track governance structure.
SIMDs, which existed before SGPs, handle the technical question: “How exactly do we build this change?” They are reviewed by core developers, require a 33% quorum of total stake to be valid, and focus on the engineering specifics of protocol modifications. Most technical changes continue to move through SIMD review without triggering an SGP. SIMD process GitHub repository
SGPs handle the strategic question: “Should the network pursue this direction at all?” They require no quorum — a proposal passes based solely on the ratio of For to Against votes among participants, regardless of how much total network stake actually votes.
The Alpenglow consensus upgrade is the clearest example of how the two tracks interact. Alpenglow passed a SIMD-process signaling vote in September 2025 with 98.27% validator approval and roughly 51% stake participation — but the full technical design was not yet ready when the directional decision was made. The SGP framework is designed to separate that “should we do this?” question from the engineering work that follows, giving the community a formal mandate to proceed before developers commit to the build. Alpenglow live for testing on community validator test clusters and targeting a Q3 2026 mainnet launch.
What Happens If Most Stakers Do Not Vote?
One design choice in the SGP system carries implications the Solana Foundation has not prominently addressed: there is no minimum participation requirement. Under the SIMD process, at least 33% of total network stake had to participate for a vote to count. Under SGPs, that safeguard is absent.
This matters because a small but coordinated coalition of large validators could, in theory, pass a significant protocol change while the majority of stakers remain passive — the quorum threshold in the SIMD process existed specifically to prevent this outcome. With 68% of Solana’s circulating supply already staked across more than 700 validators, the network has the participation depth to produce high-legitimacy votes for major proposals. But the 15% support threshold to advance a proposal, combined with no minimum turnout for the vote itself, means that off-peak or lower-profile SGPs could pass without reflecting genuine network-wide consensus.
Crypto News Flash analysts noted that the real test will come in the months ahead: “whether contentious economic changes are successfully steered through this new process.” The prior failure of SIMD-0228, which drew substantial turnout and still failed to pass, suggests validators will engage seriously for high-stakes decisions. Whether they engage with the same energy for lower-profile SGPs remains to be seen.
Solana Constitution and What Comes Next
The Solana Foundation has described SGPs as part of a broader effort to rebuild the network’s “social contract” with its stakers. A companion document, referred to as a “Solana Constitution,” is under development and is intended to establish clearer norms for which types of systemic changes require a full network vote versus the lighter SIMD technical review track. Solana social contract initiative
The governance dashboard is live at governance.solana.com, with full documentation at docs.governance.solana.com. The svmgov codebase is open source and available through the Solana GitHub repository for validators and developers who want to inspect or build on the system.
Frequently Asked Questions
How does Solana’s on-chain governance system actually verify votes without a central tallier?
Each validator’s ballot includes a Merkle proof — a path of cryptographic hashes from that validator’s ledger entry to the root of a canonical stake tree built by the ncn-snapshot program. The svmgov voting program checks this proof against the on-chain snapshot before counting the vote. Because the proof is verified entirely on-chain, no trusted intermediary controls the tally, and anyone can independently audit the result. The stake snapshot itself is built by multiple whitelisted operators working independently and agreeing on a canonical root before it publishes on-chain.
What is the difference between an SGP and a SIMD, and why does it matter for SOL holders?
An SGP (Solana Governance Proposal) asks whether the network should pursue a given direction — it is a community mandate. A SIMD (Solana Improvement Document) specifies how a technical change would actually be built — it is an engineering blueprint reviewed by core developers. Most routine protocol work continues through the SIMD track without requiring a network-wide SGP vote. SGPs become relevant when at least 15% of active stake determines that validators and stakers deserve a direct say in a major economic or architectural decision. For SOL holders, the practical difference is that SGPs are where the community’s voice is formally recorded and binding, while SIMDs are where developers turn that mandate into working software.
Can a small group of large validators pass an SGP that most stakers oppose?
Technically, yes — because SGPs have no minimum quorum requirement. A proposal passes if at least two-thirds of the stake that actually votes supports it, regardless of how much of the total network stake participates. The 15% support threshold to advance a proposal to a vote provides some protection against low-legitimacy outcomes, but it does not guarantee that the eventual vote reflects the preferences of the majority of stakers. The delegator override mechanism means any staker who feels strongly about an issue can cast their own vote rather than letting their validator represent them — but only if they actively monitor governance activity and choose to participate.
What do I need to submit a Solana governance proposal, and what if I cannot meet that threshold?
A validator must have at least 100,000 SOL delegated to its vote account — approximately $7.7 million at current prices — to file a formal SGP. Smaller token holders who want to influence governance have two paths: choosing a validator whose governance views align with their own, and using the delegator override feature to vote independently on any active proposal regardless of what their validator decides. The governance dashboard at governance.solana.com shows all active proposals and provides tools for both validators and delegators to participate.
Source: Original Article
