A separate, older track called the Solana Improvement Document, or SIMD, handles the tracking: “Okay, how exactly do we do this?” – technical details reviewed by the main network developers.
A yes on an SGP is a clear signal to proceed, with the engineering work that follows being drafted in the form of 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 topics that few people care about while allowing core developers to continue making routine changes without a referendum on each.
Once this threshold is reached, the process proceeds on a fixed schedule measured in epochs, the roughly two-day periods that Solana uses to organize its operations.
To be adopted, a proposal must receive a qualified majority, with at least two thirds of the votes voting for or against, abstentions being excluded from the calculation. There is no minimum participation requirement.
What really stands out is that the system gives more power directly to delegators – everyday users who stake their SOL with validators rather than running nodes and collecting staking rewards themselves.
