Solana developers have started testing the Alpenglow upgrade on the network’s public testnet. The change seeks to shorten the time required for transactions to become irreversible from roughly 12.8 seconds to around 150 milliseconds.

Finality marks the point at which a transaction can no longer be reversed under the network’s consensus rules. Exchanges typically wait for this confirmation before crediting deposits, cross-chain bridges use it before releasing assets on another network, and merchants rely on it to confirm that payments are locked in.

How the Upgrade Works

Alpenglow replaces Solana’s existing TowerBFT consensus system with a new voting protocol called Votor. Under TowerBFT, validators record votes as on-chain transactions and must accumulate sufficient support across 32 slots before a block reaches finality. With slots previously running near 400 milliseconds, this process produced a finality window of about 12.8 seconds.

Votor allows validators to exchange votes directly with one another. A block can reach finality after one or two voting rounds. In the faster path, at least 80 percent of network stake must notarize the block in the first round. If that threshold is not met, a second round can finalize it with a 60 percent stake threshold. This structural shift removes the longer sequence of on-chain votes that currently drives the delay.

A second component of the broader Alpenglow design, known as Rotor, is planned to improve block propagation by replacing the existing Turbine system. Rotor is expected in a later phase and is not part of the current testnet migration.

What Stays the Same for Users

The upgrade leaves transaction execution unchanged for applications and end users. The Solana Virtual Machine, transaction formats, programs, and fee mechanics remain the same. Wallet users will continue sending transactions through existing interfaces. The overhaul occurs entirely at the consensus layer and is invisible in day-to-day application behavior.

Infrastructure providers face adjustments. Vote transactions will no longer appear in blocks, and slot and block identifiers will be treated as distinct. Agave 4.3 introduces a bank_id field to help data consumers track which candidate block an event belongs to. Systems that rely on Geyser streaming tools or Proof of History ticks for pacing will need to update their indexing and monitoring processes.

Testnet Rollout and Software Requirements

Alpenglow had already operated for more than four months on a smaller community validator cluster created specifically to validate the design. Moving it to the public testnet exposes the upgrade to a broader set of validators, infrastructure providers, and services that already connect to Solana’s testing environment. The public testnet uses tokens without monetary value, allowing teams to test migration procedures, identify issues, and restart the network without risking mainnet funds.

Validators participating in the test must run Agave 4.3, the validator software maintained by Anza. Anza staged the recommendation carefully, first advising operators responsible for 10 percent of staked SOL, then expanding to 25 percent, before recommending the version to all mainnet validators on September 21. Alternative clients such as Firedancer and Frankendancer, developed by Jump Crypto, do not yet support the Alpenglow test, so the initial migration runs entirely through Agave.

Anza’s schedule lists September 28 as a tentative date for enabling Agave 4.3 features on mainnet. That date refers only to the resumption of feature activations and is not a confirmed launch date for Alpenglow itself. As of early September 23, the feature gate tracker still listed the testnet switch as pending. No firm mainnet activation date for Alpenglow has been locked in.

Separate Slot-Time Improvements

Solana has also reduced target slot times in parallel under a different proposal. The network recently moved from a 400-millisecond target to 250 milliseconds, bringing it to four slots per second. A further stage aims for 200-millisecond slots. Slot duration governs how frequently new slots are produced, while Alpenglow addresses how validators reach irreversible agreement on blocks. The two changes operate on separate tracks.

The public testnet phase is intended to surface performance, compatibility, and coordination issues before any decision is made on mainnet activation. Successful completion would bring Solana closer to near-instant settlement times while preserving the existing application and user experience.