Anza Issues Live Upgrade Call: Agave v4.3 Is the Recommended Version for All

Anza issued a live upgrade call at 15:37 UTC on September 21: Agave v4.3 is the recommended version for all mainnet-beta validators and operators should upgrade immediately. The instruction came via the official Anza account and was followed ninety minutes later by Anza CEO Brennan Watt, who confirmed "v4.3.0 is a go for mainnet" and linked the GitHub release directly.

September 21 is the general adoption day milestone in the Agave v4.3 release schedule, the release that carries the Alpenglow consensus upgrade. Our earlier coverage covers what Alpenglow changes for the network. Validators still running Agave 4.2 will be on unsupported software when the Alpenglow gate eventually opens.

What Agave v4.3.0 Adds Before the Feature Gate

The v4.3.0 release carries four changes from the release candidate. Votor-transport receives improved send-error statistics, an observability extension into Alpenglow's networking layer that was introduced in earlier 4.3 builds. Two new CLI commands land alongside it: vote-update-commission-bps lets operators adjust vote-account commission in basis points, and vote-update-commission-collector sets a separate collector address for commission proceeds. Anza tagged the release stable and suitable for Testnet, Devnet, and Mainnet Beta.

The votor-transport change is the most directly Alpenglow-relevant of the four. Votor is the component replacing TowerBFT as Solana's voting mechanism; better send-error visibility gives operators one more diagnostic surface to verify their nodes are healthy before the feature gate opens.

Why Validators Should Upgrade Before Alpenglow Activates

Alpenglow (SIMD-0326) activates through Solana's feature-gate process, which is stake-weighted: the gate opens once a supermajority of active stake is running a compatible client version. The September 21 recommendation is how that threshold gets cleared. Operators who delay risk being out of consensus when the gate opens, which Anza has said happens on testnet first, then devnet, then mainnet-beta after an observation period.

The protocol change itself is substantial. Alpenglow's Votor targets finality of around 150 milliseconds, compared with the current TowerBFT system's roughly 12.8 seconds, per SIMD-0326. Fault tolerance rises from 33% to 40% of stake under the new protocol. The initial mainnet deployment covers Votor only; Rotor, the block-propagation layer planned to complement it, is a later proposal.

Network Arrives at This Upgrade Already Running 250ms Slots

Validators upgrading to v4.3 land on a network that has been operating on a 250-millisecond target slot time since epoch 1037 on September 18. Early measurements from September 20 found produced slots landing at roughly 266ms on average, with an epoch-1037 skip rate of about 0.05%, according to Blockonomi. Alpenglow's Votor protocol operates independently of slot time; it governs when a block reaches finality, not how often leaders produce one, so the two changes sit on separate tracks.

The upgrade call positions the validator set to clear the stake threshold the Alpenglow feature gate requires. Anza has not announced a mainnet activation date.