Solana onchain governance is live: how SGPs actually work

Until this month, "Solana governance" meant a process that was social first and chain second. SIMDs were debated on GitHub and the forum, and for the few decisions big enough to need a network-wide signal (the SIMD-0228 inflation cut, the Alpenglow consensus vote), the Foundation minted SPL tokens to validator identities in proportion to stake and counted which address they were sent to. It worked, but it was one-off tooling every time, and delegators had no direct voice beyond choosing a validator.

That changed in early July. Solana Governance is now a standing onchain system, live at governance.solana.com, with its own document track called Solana Governance Proposals (SGPs), two mainnet programs, a fixed lifecycle measured in epochs, and stake weights verified onchain with Merkle proofs rather than trusted spreadsheets. This is the builders' guide to how it actually works.

Click to zoom

SGP vs SIMD: should we, versus how exactly

The first thing to understand is that SGPs do not replace SIMDs. The SGP repo's own framing: an SGP answers "should we do this?", a high-level directional question decided by stake-weighted vote. A SIMD answers "how exactly do we do this?", a technical spec decided by core-dev review. A yes on an SGP is a mandate to proceed; the implementation still arrives through SIMDs.

The motivating example cited in the SGP documentation is Alpenglow itself: the biggest consensus change in Solana's history was put to a stake vote as a SIMD before its spec was complete, exactly the directional question an SGP should have captured. The system is also deliberately an interrupt, not a toll booth: the SIMD process proceeds as before unless 15% of stake demands a referendum.

The lifecycle, end to end

• Submit. Proposing requires a validator vote account with at least 100,000 SOL staked (about $7.7M at launch prices). It is an eligibility gate, not a fee; nothing is consumed. Onchain this is the min_proposal_stake_lamports parameter in the svmgov program's GlobalConfig.
• Support. The proposal sits in a support phase until validators representing 15% of cluster stake signal for it (cluster_support_pct_min_bps = 1500). No threshold, no vote: it expires.
• Discussion: 7 epochs. The proposal is locked for debate. No votes yet.
• Snapshot: 1 epoch. Stake weights are captured (see the NCN section below).
• Voting: 3 epochs. Ballots are split allocations in basis points: For + Against + Abstain must sum to exactly 10,000, so a voter can split their weight.
• Result. Passing requires two-thirds of For + Against stake; Abstain is excluded from the denominator, and there is no minimum turnout. After the end epoch, anyone can call finalize_proposal and the tally locks permanently.

Total: a fixed 11 epochs from support threshold to result, roughly 22 days. One more integrity detail worth copying in other governance systems: the onchain proposal must link to the SGP markdown frozen at a specific commit SHA in the proposals repo. Frozen SGPs are never edited; corrections require a superseding SGP. Nobody can quietly reword what was voted on.

Staker sovereignty: delegators can overrule their validator

This is the genuinely new mechanism, and the direct answer to the SIMD-0228 controversy, where a vote representing mostly validator-operator opinion failed at 61% amid complaints that delegators had no voice. Under SGP rules, a delegator whose stake account is captured in the snapshot can cast a vote override: vote their own stake even if their validator voted differently, or voted not at all.

Mechanically, the override is proven with a two-level Merkle proof (a MetaMerkle proof that the validator is in the snapshot, plus a StakeMerkle proof for the specific stake account), signed by the stake account's withdraw authority. If the validator already voted, the override adjusts the validator's vote weight immediately; if not, it parks in a cache account and counts anyway. Each stake account overrides independently.

For validators, the incentive shift is subtle but real: your vote is now a default, not a proxy. Stake that disagrees with you can say so onchain without redelegating.

The machinery: two programs and an NCN

The trust problem in any stake-weighted vote is agreeing on who had how much stake at snapshot time. The SGP system solves it with a Node Consensus Network: whitelisted operators independently generate stake snapshots, reach consensus, and commit an immutable Merkle root onchain. Every subsequent ballot and override is verified against that root by the voting program itself. No trusted oracle, no Foundation spreadsheet.

Program        ID                                            Role
────────────   ───────────────────────────────────────────   ─────────────────────────
ncn-snapshot   ncnwF8AgynRcdEnGLcprSQNaKvgSMTgk3yPRc8cf9Zf   stake snapshot consensus,
                                                             Merkle root storage
svmgov         govYkyQ3ePtGULAtY6V75qjWE8UH4vCUVQ1W4HdCAZU   proposals, support,
                                                             voting, overrides

Key accounts: GlobalConfig, Proposal, Support, Vote,
VoteOverride, ConsensusResult. All are ordinary program
accounts, inspectable over RPC.

Everything is driven by a Rust CLI called svmgov(create-proposal, support-proposal, cast-vote, cast-vote-override, finalize-proposal, list-proposals), and the tooling repo also ships the dashboard frontend and the NCN verifier service. Because proposals and votes are plain accounts under known program IDs, anyone can build an independent tracker, an alerting bot for stake you delegate, or a dashboard that diffs validator votes against their delegators' overrides. That last one is going to make some validators uncomfortable, which is rather the point.

What is queued to vote

As of publication nothing has formally gone to a vote; the proposals folder in the repo is still empty and the first drafts are open PRs:

• SGP-0001, "The Solana Constitution" (Nick Almond of Jito and Tushar Jain of Multicoin): a ratification vote for a canonical network-governance document, with articles covering stake sovereignty, validator stewardship, and transparency.
• SGP-0002, "Double Disinflation": the SGP counterpart of SIMD-0550, doubling the disinflation rate from 15% to 30% per year so terminal 1.5% inflation arrives in roughly 2.8 years instead of 5.7, cutting around 18.9M SOL of emissions over six years.
• Behind them, per ecosystem coverage: the fee-reform lineage including SIMD-0553's resource-fee burn restructure, and SIMD-0123's block reward distribution to delegators.

The tokenomics fights that strained the old process are, in other words, exactly what the new process will be stress-tested with. Worth noting neutrally: the svmgov and ncn-snapshot programs are upgradeable, and no public audit has been announced yet for either; for a system whose whole pitch is verifiability, an audit and a path to immutability are the obvious next milestones to watch. Per the SGP-0001 draft, v1.0 of the tooling was built by Turbine, ExoTech, Jito, and the Solana Foundation, with Foundation funding.

Resources

• solana-foundation/solana-governance-proposals: the SGP repo: process rules, thresholds, and draft proposals
• solana-foundation/solana-governance: svmgov program, CLI, NCN verifier, and dashboard source
• docs.governance.solana.com: architecture, program IDs, and CLI reference
• governance.solana.com: the live dashboard
• CoinDesk launch coverage and Helius on the old token-ballot era
• Related on devrels.xyz: Alpenglow explained, MetaDAO futarchy, and how Solana staking works