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.
