Inside Solana’s governance as Alpenglow passes
Solana’s Alpenglow has passed, targeting ~150ms finality
Arelix/Shutterstock and Adobe modified by Blockworks
This is a segment from the 0xResearch newsletter. To read full editions, subscribe.
Last week, we dove deep into SIMD-326 (Alpenglow), which proposes a new consensus protocol for Solana. The headline impact of Alpenglow is a 100x reduction in Solana’s finality time, from ~12.8 seconds to around 150ms.
A validator-signaling vote for SIMD-326 took place between epochs 840 (starting Aug. 27) and 842 (ending today), with a preliminary stake participation rate of 51% as of writing.
SIMD-326 will pass, with ~99% of non-abstaining votes in favor. With Alpenglow’s voting period coming to a close, it’s a good time for a refresher on how Solana governance works.
Solana’s onchain governance is meant to signal community sentiment rather than automatic enforcement of changes. In other words, social consensus is the final arbiter, with the real decision point resting with validators and developers who must collectively agree to deploy and run the new software. A key stakeholder in this process is the Anza team, which must design and roll out changes in the Agave client via feature gates.
With this context in mind, all Solana Improvement Documents (SIMDs) formally begin as written proposals on Solana’s GitHub. In this stage, the community and core contributors can openly discuss and adjust variables before a SIMD goes into a vote, implement it without requiring one, or outright reject it before that happens. Forum discussions play a crucial role in Solana governance by enabling structured, thoughtful debate on proposals and their potential effects.
Solana’s onchain governance model is akin to a representative democracy in the sense that validators vote on behalf of stakers, who are free to delegate their staked SOL to any validator. Each validator’s voting power is proportional to the stake delegated to them, and validators can even split their vote weight among distinct options if they choose (Yes, No, or Abstain). Typically, the voting period for any given SIMD lasts three epochs (around six days).
Finally, Solana requires two parameters for a SIMD vote to pass. The first is the quorum threshold: At least 33% of the total stake must participate (including abstains) for the vote to be valid. The second requirement is the supermajority: At least two-thirds of non-abstaining votes must be “Yes” for the proposal to pass. SIMD-326 received overwhelming support compared to more contentious proposals, such as SIMD-96 (which discontinued the burn on priority fees), SIMD-123 (which will implement an in-protocol way to distribute priority fees), and SIMD-228 (the infamous failed inflation reduction proposal).
Get the news in your inbox. Explore Blockworks newsletters:
- The Breakdown: Decoding crypto and the markets. Daily.
- 0xResearch: Alpha in your inbox. Think like an analyst.
- Empire: Crypto news and analysis to start your day.
- Forward Guidance: The intersection of crypto, macro and policy.
- The Drop: Apps, games, memes and more.
- Lightspeed: All things Solana.
- Supply Shock: Bitcoin, bitcoin, bitcoin.
