Key Insights
- Solana Alpenglow aims for better finality of 150 milliseconds, directly through a vote on the validators without on-chain vote transactions.
- Devnet and testnet testing enables developers to test their compatibility before deploying it onto the mainnet.
- There is no confirmation of mainnet activation and changes to transaction records and validator participation tracking for data providers.
Solana Alpenglow reached Solana’s public developer network on September 25, allowing application teams to test its proposed 150-millisecond transaction finality. The upgrade targets a reduction from approximately 12.8 seconds, potentially changing settlement speeds for exchanges, payment providers, and decentralized applications.
Anza, Solana’s core software developer, announced the devnet activation one day after testnet completed its transition. However, the Solana Foundation still lists the upgrade as inactive on mainnet, leaving the launch date unconfirmed.
Solana Alpenglow Advances Through Public Testing
The September 25 activation gives developers access to the upgraded consensus system before its potential deployment on the network handling real funds.
According to the Solana Foundation’s upgrade documentation, Alpenglow now operates on devnet and testnet. These environments serve different purposes during development.
Application teams can create tokens that do not have any monetary value to run software tests on Devnet. In the meantime, testnet will enable validator operations and testing of the validator infrastructure under more challenging network conditions.
The transition follows preparations involving Agave 4.3, the validator software associated with the upgrade. A previous September 23 report covered preparations for the public testnet rollout.
Consequently, developers can examine application behavior without waiting for mainnet activation. Solana’s existing TowerBFT consensus system remains operational on mainnet. The proposed 150-millisecond finality therefore remains a development target rather than a live-network performance measurement.
New consensus design targets faster settlement
Solana Alpenglow introduces changes to how validators reach agreement about blockchain transactions.
Under TowerBFT, validators submit votes as transactions included in blocks. The network accumulates sufficient votes across 32 slots before finalizing a block, producing approximately 12.8 seconds of finality.
Alpenglow replaces this approach with direct communication between validators. Its Votor component allows validators to exchange votes without recording each vote as an onchain transaction.
The Foundation describes two possible voting rounds under the new system.
- One round can finalize a block when validators representing at least 80% of the stake approve it.
- A second round provides another opportunity to establish agreement when the first misses that threshold.
- Finality determines when the network considers a transaction irreversible under its consensus rules.
For example, an exchange could use faster finality when deciding whether to credit a Solana deposit. Similarly, payment providers could assess completed transactions sooner.
But every platform has its own security controls and deposits requirements. Faster blockchain finality does not automatically eliminate additional processing delays.
The upgrade also differs from Solana’s separate efforts to reduce block production times. Shorter slots increase how frequently the network produces blocks, while Alpenglow changes how validators agree on finality.
Infrastructure changes extend beyond transaction speed
The consensus redesign also affects blockchain data providers, transaction explorers, and infrastructure operators.
Applications that submit transactions and retrieve account balances require no migration, according to the Foundation. Transaction execution, fees, and transaction submission formats remain unchanged. However, services maintaining transaction histories must adjust their data-processing systems.
Alpenglow can expose competing candidate blocks for the same slot before validators select the confirmed version. Data providers must therefore separate those candidates and retain the block that reaches confirmation. Combining transactions from competing candidates could produce inaccurate transaction histories.
Validator’s votes on blocks will also be removed, as the validators will communicate directly with each other. This means that transaction counters counting votes of validators may even be reduced after activation even if there is no user activity.
The Foundation has recommended that comparisons and alerts be updated with the previous totals of transactions. Moreover, services that monitor validator participation need to obtain data from the certificates in block data.
Operators using Solana’s Geyser and gRPC data streams must also accommodate identifiers distinguishing competing blocks within individual slots. These requirements make testing important for exchanges, explorers, and other businesses relying on accurate blockchain records.
Mainnet Deployment Depends on Further Validation
The rollout has no confirmed mainnet activation date, despite earlier roadmap discussions connecting deployment preparations with Agave 4.3 and an October target. Anza’s software schedule tentatively allows mainnet feature activations to resume on September 28. However, the schedule does not identify that date as Alpenglow’s launch.
Furthermore, the Foundation separates Alpenglow’s consensus changes from Rotor, a later component designed to replace Solana’s block-distribution system. The current rollout focuses on Votor and its proposed improvements to validator communication and finality.
The upgrade marks the growing competition between different blockchain settlement speeds and infrastructure reliability for the broader blockchain sector. A quicker speed of finality could foster trading, payments and DeFi applications that rely on transactions being confirmed quickly.
However, it is important for developers to assess real-world network performance before making decisions about the operation. The deployment process will be informed by the outcomes of testing, the coordination of validators, and additional technical validation.
