A separate, older track called the Solana Improvement Document, or SIMD, handles the follow-up: “Okay, how exactly do we do this?” – technical details reviewed by the main network developers.
A yes to an SGP is a clear signal to proceed, and subsequent engineering work is drafted into one or more SIMDs.
However, voting does not open automatically. A proposal must first pass a support threshold of 15% of active participation before moving to a vote, a gate intended to prevent the network from voting on issues that few truly care about while allowing core developers to continue submitting routine changes without a referendum on each.
Once that threshold is reached, the process runs on a fixed schedule measured in epochs, the roughly two-day periods that Solana uses to organize its operations.
To be approved, a proposal needs a supermajority, that is, at least two-thirds of voters voting for or against, and abstentions are left out of the calculations. There is no minimum participation requirement.
What really stands out is that the system gives more power directly to delegates: everyday users who stake their SOL with validators instead of running nodes themselves and collecting staking rewards.
