'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 last planned checkpoint before the Alpenglow consensus feature gate is targeted to open on September 28. Our earlier coverage traced the full activation timeline and what Alpenglow changes for the network. Validators still running Agave 4.2 through the activation window will be on unsupported software when that gate 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 September 28 Is the Hard Deadline for Solana Validators

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 on schedule. Operators who delay past this window risk being outside the supermajority or out of consensus when the gate opens.

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. Seven days remain until the targeted September 28 activation.