A separate, older track called a Solana Improvement Document, or SIMD, handles the follow-up: “Okay, how exactly do we do it？” – the technical details reviewed by the networks core developers.
A yes on an SGP is a clear signal to proceed, with the engineering work that follows written up as one or more SIMDs.
The vote does not open automatically, however. A proposal has to first clear a support threshold of 15% of active stake before it moves to a ballot, a gate meant to keep the network from voting on matters few actually care about while letting core developers keep shipping routine changes without a referendum on each one.
Once that threshold is met, the process runs on a fixed schedule measured in epochs, the roughly two-day periods Solana uses to organize its operations.
To pass, a proposal needs a supermajority, at least two-thirds of the stake voting for or against it, with abstentions left out of the math. There is no minimum turnout requirement.
What really stands out is that the system gives more power directly to delegators – the everyday users who stake their SOL with validators rather than running nodes themselves and collect staking rewards.