Solana On-Chain Governance Explained: How It Compares to Other L1s

On July 1, 2026, Solana Foundation shipped something the network had lived without for six years: on-chain governance. The new framework, called SGP (Solana Governance Proposals), moves strategic decisions about the protocol on-chain, where they are settled by staked SOL through Merkle-proof voting instead of off-chain forum consensus.

The headline number, reported by CoinDesk, is the 100,000 SOL (roughly $7.7 million at July 2026 prices) a validator needs before it can open a proposal. That bar got most of the attention. The quieter change matters more: staker sovereignty, the right of a delegator to override their validator's vote with their own stake. It doesn't make Solana the first L1 to do this, but it changes what delegation means on the network.

And it is live, not a roadmap item: the programs are deployed on mainnet and the first proposals are already moving through them.

What Solana Governance Proposals (SGP) actually are

SGP covers the network's strategic decisions: consensus upgrades, economic parameters, protocol direction. It runs on two programs, and every vote is verified with a Merkle proof against a stake snapshot, so nothing depends on trusted off-chain counting.

• svmgov (govYkyQ3ePtGULAtY6V75qjWE8UH4vCUVQ1W4HdCAZU): the governance program that creates proposals, records support, and tallies Merkle-proof votes.
• ncn-snapshot (ncnwF8AgynRcdEnGLcprSQNaKvgSMTgk3yPRc8cf9Zf): the Node Consensus Network program that produces the canonical stake snapshot each vote is weighed against.

From there a proposal moves through two distinct stages that most explainers collapse into one. First it earns the right to a vote. Only then does the vote begin.

Stage 1: support

A validator needs 100,000 SOL of active stake at its vote account to create the proposal on-chain — but creating it does not start a vote. It opens a support window of up to 7 epochs (about 14 days) in which other validators signal that the proposal deserves one, and it must clear the Proposal Sponsor Threshold of 15% of active stake to advance.

Support carries no YES or NO; it only decides whether the network votes at all. Each signal re-measures supporting stake at the current epoch, so support can drift backwards as stake moves. Miss 15% before the window closes and the proposal expires, to be created again from scratch.

Stage 2: the vote

Once support clears, the proposal locks into a fixed 11-epoch schedule — about 22 days — with two thresholds waiting at the end:

• Review. 7 epochs (about 14 days). The commit SHA freezes when the proposal goes on-chain, so this window is for studying the text, not amending it.
• NCN snapshot. 1 epoch (about 2 days) fixes the stake distribution that sets voting weight. Nobody votes during this phase.
• Voting. 3 epochs (about 6 days). Each stake account votes For, Against, or Abstain by Merkle proof; validators can block-vote their whole stake or split it in basis points.
• Quorum. One-third of network stake has to turn out. Missing it is not a rejection — the proposal lands in Inconclusive, read as indifference rather than a no.
• Supermajority. Two-thirds YES to pass.

Counting the support window, a full cycle runs up to 18 epochs, roughly 36 days. The widely quoted "22 days" covers only the part after support is secured.

One caveat before you quote a threshold at someone: those last two rules are policy, not code. The deployed svmgov config carries the support threshold, the 100,000 SOL floor and the 7 / 1 / 3 schedule, but no quorum or supermajority field at all. And the two policy documents disagree. The repo README, which most launch coverage followed, drops the quorum entirely and excludes abstentions; the Constitution keeps both, and tells maintainers to reconcile the README once ratified.

SGP is also deliberately scoped. It handles the strategic proposals, while SIMD (Solana Improvement Documents) still handles technical specs and keeps passing optimistically without a vote. The bridge is elevation: validators holding 15% of stake can flag a SIMD as too systemic to pass quietly, converting it into an SGP. That escalation valve, more than the naming split, is what gives stakers leverage over technical change.

How Solana governance compares to other L1s

Solana didn't invent on-chain governance. Tezos shipped a self-amending protocol in 2018, Cosmos Hub its governance module in 2019, Polkadot OpenGov in 2023. Solana got to watch all of them hit their problems first, and SGP borrows proven ideas rather than breaking new ground.

Two things stand out. The entry bar is the highest here: 100,000 SOL is steep next to a 500 ATOM deposit on Cosmos, a few hundred dollars at current prices. Strong anti-spam, but critics argue it recreates the wealth concentration governance is meant to check, and both readings are fair. The cycle is middle of the road: about 22 days of voting, faster than Tezos and slower than Cosmos, stretching to roughly 36 days once you count support.

Ethereum sits deliberately outside the on-chain part of this table, coordinating through GitHub EIPs and All Core Devs calls. That is a different tradeoff, not a broken one: harder to capture with capital, but slower and more informal, which is one reason Ethereum decisions can take years.

Staker sovereignty and what it changes for delegators

Under a validator-controlled model, delegating your stake also delegates your voice — Tezos being the clearest example, where your only recourse is switching bakers. Solana rejects that, following Cosmos rather than inventing anything, but it is a real departure from how Solana staking worked before SGP. The mechanic is an opt-in: by default your vote still flows with your validator, but at any point your stake account can prove its balance against the snapshot and cast independently.

That changes validator incentives. Delegators who disagree with you can now route around you without moving their stake, so a published voting policy becomes a way to retain delegation rather than a courtesy. It only matters if delegators actually use it.

Case study: what SGP would have meant for SIMD-228

In March 2025, SIMD-228, a proposal to switch Solana to market-based inflation emissions, went to a vote under the old system. Participation was record-breaking: 74.3% of stake, more than 900 validators, 281 million SOL. The tally was 61.39% YES against the 66.67% needed, so it failed by 5.28 points.

Post-mortem analysis surfaced an open secret. SFDP (the Solana Foundation Delegation Program) delegates roughly 41 million SOL, about 10% of staked SOL, and that stake voted predominantly NO. Helius ran both counterfactuals: had it voted YES the proposal passes, and had it merely abstained the tally moves from 61.39% to 64.77% — still short, far closer. That is de facto veto power on close votes: not a criticism of the Foundation, a structural fact of how stake mapped to votes.

It is tempting to say SGP dissolves that concentration. It doesn't, and the reason matters. Staker sovereignty moves voting power from the validator to whoever holds the stake account's withdraw authority. For self-custodied delegators that is a genuine transfer. For SFDP-delegated stake the authority is the Foundation, so SGP dilutes nothing — if anything it lets the Foundation vote its 41 million SOL directly rather than through the validators it funds. Same for exchange-held stake, where the authority is the exchange, not its customers.

What genuinely changes is that a validator no longer speaks for stake it merely received. Would SIMD-228 have passed under SGP? Maybe, maybe not — it would also have needed 15% support just to reach a ballot, and most delegators hold no strong view on inflation policy. That is the honest answer, and it is also the point:

The new system doesn't guarantee different outcomes. It guarantees different inputs, and that is the entire point of decentralized governance.

What validators should do now

If you run a validator, SGP adds a handful of concrete responsibilities:

• Learn the svmgov CLI. Creating, supporting, and voting all run through it: create-proposal, support-proposal, cast-vote, modify-vote. Reference at docs.governance.solana.com, and both programs run on testnet under the same IDs, so rehearse there first.
• Secure a dedicated voting keypair. Keep it separate from your validator identity key and apply cold-storage practices.
• Publish your voting policy. A public commitment by proposal category reduces the incentive for delegators to override you, since they already know where you stand.
• Set your block-reward commission. SIMD-123 passed in March 2025 with 74.91% YES and ships with Agave 4.1, letting you set a commission in basis points on your vote account to share block revenue with delegators, locked forward one epoch so it can never change retroactively.
• Watch the support queue, not just the ballot. A proposal you disagree with can be stopped by simply not sponsoring it, and that window is at most 7 epochs. Track it at governance.solana.com/proposals — once voting opens your leverage is much smaller.
• Communicate visibly. Under staker sovereignty, transparency directly protects your delegated stake.

What stakers should do now

Delegators get something they have never had on Solana: a direct vote. To make use of it:

• Check your validator's voting policy. Look for a public commitment. If they don't have one, that itself is a signal.
• The tooling already exists. The same svmgov CLI ships cast-vote-override and modify-vote-override for stakers. You need the stake account's withdraw authority, a delegation captured in the NCN snapshot, and an operator API to serve your Merkle proof.
• Vote early either way. If your validator has already voted, your override adjusts their tally immediately. If they haven't, your choice is cached and applied automatically the moment they do.
• Track SGPs where they live. governance.solana.com/proposals shows every proposal and its current stage, with the on-chain accounts as ground truth.
• Reserve overrides for votes that matter. An override costs a transaction and your attention, so save it for proposals that genuinely affect your position.

Where this leaves Solana

SGP doesn't make Solana's governance the best in crypto — that is a PR claim, not an analytical one. What it does is close a real gap. For six years, Solana's biggest decisions happened through off-chain rough consensus. Now they happen on-chain, with staked SOL, and with delegators able to speak for themselves.

The tradeoffs are real. The 100,000 SOL threshold favors serious proposals but concentrates who can start them. Staker sovereignty empowers delegators but asks more of them. And whether the 15% support bar filters noise or simply filters out whatever the largest validators dislike is a question only the next few votes can answer.

If you run a validator, the delegation programs behind your stake shape how much say your delegators have in all of this. Our guide to Solana validator delegation pools breaks down how the 13 major programs score operators. And for updates as the first SGPs play out, follow @lumlabs on X.