Agave 4.3.2 lands before Solana’s October 21 consensus switch

Anza published Agave v4.3.2 late October 15 UTC, giving Solana validator operators a new stable software build days before the network’s planned shift from TowerBFT to Alpenglow consensus.

The GitHub release is labeled suitable for mainnet beta, testnet and devnet. Its change list includes fixes for Alpenglow slot timing in transaction buffering, an optional thread pool for BLS certificate verification, and performance work on vote-state serialization. Those are implementation changes in validator software; the release did not itself activate Alpenglow on Solana mainnet.

The Solana Foundation’s current schedule places activation at epoch 1064, expected to begin October 21 at approximately 15:00 UTC. That clock time is an estimate because epoch boundaries move with actual slot timing. The Foundation’s status page still listed mainnet as not activated when checked October 18.

The switch changes consensus, not execution

Alpenglow replaces the TowerBFT voting layer used to decide which blocks become irreversible. Under TowerBFT, validator votes are transactions placed onchain and finality takes about 12.8 seconds, according to the Foundation. Under the first Alpenglow phase, called Votor, validators send votes directly and combine them into certificates. A block can be finalized after one or two voting rounds.

The Foundation targets roughly 150 milliseconds for finality. That is a protocol objective, not a measured mainnet result. Network conditions, validator behavior and the migration itself will determine production performance after activation. The published Solana improvement document also covers Votor rather than the full Alpenglow design; Rotor, a planned data-dissemination replacement, is explicitly deferred.

Execution remains outside this change. The Solana Virtual Machine, transaction formats, programs and fee mechanics are not being replaced by the consensus migration. Wallet users are not expected to change how they sign or send transactions solely because of Alpenglow.

Data providers need a new baseline

Moving validator votes out of blocks creates an important measurement break. Reported transaction counts may fall sharply even if user payments, trades and program calls remain unchanged. Throughput dashboards will need to distinguish the removal of consensus traffic from a decline in economic activity.

Infrastructure providers also face data-model changes. Agave 4.3 introduces a bank identifier for streams in which a slot can carry more than one candidate block. The Foundation tells indexers and Geyser or gRPC consumers to buffer by both slot and bank identifier, retain the candidate that reaches confirmed status and discard competing candidates. Systems keyed only to a slot could combine events from different candidate blocks.

The operational migration has two stages. The feature gate is scheduled for the start of epoch 1064, but TowerBFT is expected to continue for the first 5,000 slots of that epoch, about 18 minutes. The current plan places the actual consensus handoff at slot 459,653,000. Operators are told to verify the live consensus state through the new genesis-certificate query instead of relying only on the calendar.

Activation remains the evidence point

Agave v4.3.2 narrows near-term software risk by packaging fixes into a stable release, but a release label does not establish network-wide adoption or a successful migration. The available records do not provide a final count of upgraded validator stake, and they do not demonstrate 150-millisecond finality under mainnet load.

Coinburn is publishing October 18 in New York, after the software release but before the scheduled activation. The next verifiable milestones are the epoch boundary, the genesis certificate showing that Alpenglow has taken over, and post-migration measurements of finality, participation and network stability.