All news is rigorously fact-checked and reviewed by leading blockchain experts and seasoned industry insiders.
The Solana Foundation has officially rolled out Solana Governance Proposals (SGP), a move that marks a significant step in how the network handles decision-making.
SGP vs. SIMD: The “Why” vs. The “How”
To understand SGP, you first have to understand what it isn’t. Many people will naturally compare it to the existing Solana Improvement Document (SIMD) process, but they serve two distinct purposes:
SIMDs are engineering blueprints: They answer “how” a technical change should be implemented. These are vetted by core developers to ensure protocol integrity.
- SGPs are directional mandates: They answer “should we do this?” These are about community will and high-level strategy. Think of it this way: SGP is the political will, while SIMD is the engineering execution.
A perfect example of this is the “Alpenglow” proposal. In the past, the community attempted to move this through the SIMD process before the technical details were fully ready. It created friction because the developers needed a “green light” on the concept before spending the time to build the blueprint. With SGP, the community can now provide that “yes” vote first, validating the direction before the heavy engineering lifts begin.
| Feature | SGP (Solana Governance Proposals) | SIMD (Solana Improvement Documents) |
|---|---|---|
| Primary Question | “Should we do this?” | “How exactly do we do this?” |
| Altitude | High-level, directional | Detailed protocol specification |
| Decided By | Stake-weighted on-chain vote | Technical review by core developers |
| Maturity Required | A clear idea worth a community signal | A complete, implementable design |
A “Pressure Valve,” Not a Power Grab
A common misconception is that SGP replaces the role of core developers. It doesn’t. The SGP process is best described as an interrupt mechanism. The normal development pipeline—where developers propose SIMDs—continues to function as it always has. SGP only kicks in when the community feels a decision is significant enough to require a formal, stake-weighted vote.
- The Threshold: To trigger an SGP vote, a proposal must gain support from at least 15% of the total active network stake.
- The Intent: This high barrier ensures that the network isn’t clogged with trivial votes. It is a “pressure valve” reserved for matters with long-term economic impact where the community demands a seat at the table.
How the Mechanics Work
When an SGP is initiated, it follows a structured, transparent path. Each proposal consists of a markdown document (detailing the rationale) and an on-chain record linked to a specific, immutable commit SHA. This ensures that the proposal being voted on cannot be changed mid-process.
The Voting Rules:
- Submission: Requires a validator with at least 100,000 SOL staked.
- Trigger: 15% of active stake must signal support to move to a formal vote.
- Approval: Requires a two-thirds (66.67%) supermajority of the participating “For” and “Against” stake (abstentions are excluded).
- Timeline: The entire cycle takes roughly 22 days (11 epochs) from the moment the support threshold is met to the final outcome.
The Big Picture: Governance Maturation
For years, the critique of Solana has been that its governance was too centralized, leaning heavily on the expertise of core developers. While this approach allowed for incredible speed and performance, it left stakers and validators feeling like passengers on someone else’s bus.
SGP changes that dynamic by codifying the voice of the community. It doesn’t hand the keys to the kingdom over to a DAO, nor does it slow down critical engineering. Instead, it creates a formal channel for economic and strategic decisions that previously relied on informal consensus.
The real test will be in the coming months. We will be watching to see how often that 15% threshold is reached and whether contentious economic changes are successfully steered through this new process. For now, it represents a mature, measured evolution for Solana. a way to balance the need for fast, expert-led engineering with the necessity of community-backed governance.
