Solana Foundation announced on July 2 via X that the Solana on-chain governance mechanism is now live; validators can propose, support, and vote on core protocol decisions through Solana Governance Proposals (SGPs), with all proposals completed on-chain. Any validator with at least 100,000 SOL delegated can permissionlessly initiate an SGP; the threshold for a proposal to enter the voting phase is 15% active stake support.
Solana Foundation: Minimum Threshold for Validators to Submit SGP is 100,000 SOL
(Source: Solana Github)
According to the official announcement from the Solana Foundation, any Solana validator with at least 100,000 SOL delegated can permissionlessly initiate an SGP on-chain; submitting an SGP requires a Solana validator vote account, the svmgov CLI, and an SGP pull request frozen to a specific commit SHA.
Once an SGP document is locked to a specific commit SHA, it becomes tamper-proof; any corrections must replace the original version with a new SGP, ensuring document integrity for on-chain voting.
Functional Distinction Between SGP and SIMD: Directional Decisions vs. Technical Specifications
According to Solana Foundation documents, SGP answers "Should we do this?" through stake-weighted on-chain voting, requiring directional ideas with feasibility; SIMD answers "How exactly should we do it?" through technical review by core developers, requiring complete and implementable designs. SGP is not a mandatory prerequisite for SIMD; only when validators or stakers reach a 15% support threshold does the SGP intervene and submit the decision to an on-chain vote, otherwise the SIMD process proceeds as usual.
The Solana Foundation cites the Alpenglow consensus protocol change as a typical case: because technical details were insufficient for SIMD review, developers used an SGP to first gather community directional signals, then detailed SIMD protocol development after the design matured.
Voting Policy: 15% Stake Trigger Threshold, Two-Thirds Supermajority for Passage
According to the official voting policy document from the Solana Foundation, the full parameters of the SGP voting policy are as follows:
Submission Eligibility: Validator vote account must hold at least 100,000 SOL delegated
Voting Trigger: 15% of active stakeholders signal support for the SGP to advance from Support to Voting; if the threshold is not met, it automatically expires
Quorum: No minimum vote count requirement
Passage Threshold: For votes must reach two-thirds (66.67%) of (For + Against) total; Abstain votes are not counted in the denominator
Voting Period: 3 Epochs (one Solana Epoch is approximately two days, so the voting period is roughly 6 days)
SGP Lifecycle Timeline: Fixed 11 Epochs After Reaching 15% Support Threshold
According to Solana Foundation documents, once an SGP is locked on-chain, it enters a fixed schedule measured in Epochs. After reaching the 15% support threshold, the on-chain process runs on the following fixed timeline: Discussion phase 7 Epochs (proposal locked, community members review and discuss, voting not yet open), NCN snapshot 1 Epoch (Node Consensus Network captures staking state that determines voting weight), Voting phase 3 Epochs (stake-weighted voting opens, SGP is finally accepted or rejected), totaling 11 Epochs (approximately 22 days) for the final result.
Delegator Vote Override Mechanism: Can Override Validator Vote by Stake Weight on Governance Page
According to the Solana Foundation announcement, if a delegator disagrees with their validator's vote choice, they can override the validator's vote on the governance page based on their own stake weight; the override must be completed within the 3-Epoch voting period. Voting "For" an SGP authorizes continued progress in that direction; subsequent implementation is typically specified in one or more SIMDs and client releases.
Frequently Asked Questions
What is a Solana SGP and how is it different from SIMD?
SGP (Solana Governance Proposal) handles directional decisions, triggered by 15% stake support, requiring a two-thirds supermajority, decided by stake-weighted on-chain voting. SIMD (Solana Improvement Document) handles specific technical specifications, reviewed by core developers, requiring complete and implementable designs; SGP is not a mandatory prerequisite for SIMD.
What is the threshold for a proposal to enter the SGP voting phase?
According to the Solana Foundation official documents, a proposal must receive support signals from at least 15% of active stakeholders to move from the Support phase to the Voting phase; if the support signals do not meet the threshold, the SGP automatically expires and the SIMD process proceeds as usual.
After reaching the support threshold, how long does the SGP voting take?
According to the official timeline, after reaching the 15% support threshold, the on-chain process runs a fixed 11 Epochs: Discussion 7 Epochs, NCN snapshot 1 Epoch, Voting 3 Epochs; one Solana Epoch is approximately 2 days, so the final result is determined about 22 days after the threshold is reached.
