Inside Solana’s governance as Alpenglow passes

This is an excerpt from the latest issue of the 0xResearch newsletter. For access to the full editions, consider subscribing.


Last week, we delved into the details of SIMD-326 (Alpenglow), a new consensus protocol proposed for Solana. The standout feature of Alpenglow is a significant reduction in Solana’s finality time, from approximately 12.8 seconds to just 150ms.

A vote by validators on SIMD-326 took place between epochs 840 (starting on Aug. 27) and 842 (ending today), with an initial stake participation rate of 51% at the time of writing.

The approval for SIMD-326 is expected to be high, with around 99% of non-abstaining votes in support. As the voting period for Alpenglow draws to a close, it’s a good opportunity to revisit how Solana governance functions.

Solana’s on-chain governance serves as a signal of community sentiment rather than an automatic enforcement mechanism for changes. Ultimately, social consensus plays a crucial role, with validators and developers needing to reach a collective agreement to deploy and operate the new software. The Anza team holds significant influence in this process, responsible for implementing changes in the Agave client through feature gates.