A separate, older track called a Solana Improvement Document, or SIMD, handles the follow-up: “Okay, how exactly do we do this?” – the technical details reviewed by the core developers of the network.
A yes to an SGP is a clear signal to go ahead, with the engineering that follows written up as one or more SIMDs.
However, the poll does not open automatically. A proposal must first clear a support threshold of 15% of the active share before moving to a vote, a gate intended to prevent the network from voting on issues that few actually care about, while allowing core developers to continue sending routine changes without a referendum on each one.
Once this threshold is reached, the process runs on a fixed schedule measured in epochs, the roughly two-day periods Solana uses to organize its operations.
To adopt a proposal requires a supermajority, at least two-thirds of the effort voting for or against it, with abstentions out of the calculation. There is no minimum requirement for participation in elections.
What really stands out is that the system gives more power directly to delegators – the regular users who set their SOL with validators instead of running nodes themselves and collecting stake rewards.
