Governance FAQ
A high-level guide to how Solana Governance Proposals (SGPs) work. For the full process and policy, see the SGP repository README and the proposed Solana Constitution (SGP-0001).
›What is an SGP?
A Solana Governance Proposal (SGP) is a stake-weighted, on-chain signaling vote. It captures a directional decision rather than a detailed technical specification. A "yes" outcome is a mandate to proceed; the implementation that follows is normally specified in one or more SIMDs. Proposals live in the SGP repository on GitHub.
›How is an SGP different from a SIMD?
They answer different questions. An SGP answers "should we do this?" and gauges community support. SGPs are decided by a stake-weighted vote of validators and stakers. A SIMD answers "how exactly do we do this?". A SIMD is a detailed protocol specification reviewed by core developers. SIMDs pass optimistically and are not voted on, unless enough stake demands a vote (see below).
›When does a vote happen?
A vote occurs when the validator set asks for one. An SGP vote is triggered when 15% of active stake supports holding it. If less than 15% of stake signals support within the support window, no vote occurs. This keeps voting reserved for systemic decisions with genuine community interest.
›What are the phases, and how long do they take?
Once a proposal is created on-chain, it moves through fixed, program-enforced phases (one epoch is roughly two days):
- Support — up to 7 epochs for validators representing 15% of stake to sponsor the proposal. If the threshold is not met in time, the proposal expires. During the support phase, if at least 15% of stake supports a proposal, then the discussion phase begins in the following epoch.
- Review (discussion) — 7 epochs. The proposal text is frozen at a specific GitHub commit; the community studies it.
- Snapshot — 1 epoch. The Node Consensus Network (NCN) fixes the stake distribution used to weight votes.
- Voting — 3 epochs. Validators and stakers cast stake-weighted votes: For, Against, or Abstain.
A proposal that reaches the support threshold early advances early — the review clock starts when support succeeds, not when the support window would have ended.
›Who can create a proposal?
Anyone can author a draft SGP as a pull request in the SGP repository. Creating the on-chain proposal must be done by a validator with at least 100,000 SOL of active stake. The minimum stake required for proposals prevents spam.
›How is the vote weighted?
By active stake, at the snapshot taken before voting opens. Each vote is verified on-chain against a Merkle proof of that snapshot. Validators can cast their full stake on one option or split it across options in basis points.
›Do stakers have the ability to vote?
Yes. By default your stake votes with your validator, but you have vote sovereignty: you can cast an override vote with your own stake account before, after, or in the absence of your validator's vote. A staker can override the validator's vote for the portion of stake they delegate to the validator.
›What does it take for a vote to pass?
Per the proposed Solana Constitution (SGP-0001): a quorum of one-third of network stake must participate (For + Against + Abstain), and two-thirds of participating stake must vote For. If quorum is not met, the outcome is inconclusive. An SGP that does not reach quorum does not pass and does not block any associated SIMD.
›Where do I discuss proposals?
The canonical venue is GitHub. Discussions should occur on each proposal's pull request and the repository's Discussions in the SGP repository. Conversation on other platforms is welcome as advisory input, but GitHub is where deliberation formally happens.
›Where can I learn how the on-chain system works?
The technical documentation covers the on-chain programs, the NCN snapshot process, CLI usage for validators and stakers, and program reference material.