Anza Publishes Agave 4.3 Release Schedule, Mapping the Rollout That Carries Alpenglow Consensus

AnzaAnza published the Agave 4.3 release schedule on August 12, setting out the rollout path for the release that carries Alpenglow consensus, alongside SHA512 syscalls, big-integer modular exponentiation, and an increase in CPI depth. The schedule's final mainnet milestone, on September 28, is the resumption of feature activation on mainnet-beta; it does not set a date for Alpenglow itself.

The schedule arrived the same day a Teraswitch routing failure pushed 28.83% of staked SOLSOL offline, 4.5 percentage points short of the one-third threshold that would halt finality under the current Tower BFT system. Solana co-founder Anatoly Yakovenko noted in response that Alpenglow can survive "to 40% down," pointing directly to one of the protocol's central improvements over the system it replaces.

Agave 4.3 Schedule: Testnet Adoption Aug 17, Mainnet Feature Activation Resumes Sep 28

The v4.3 branch was created on August 11, completing the first milestone. What follows is a seven-week runway from testnet adoption to the resumption of mainnet feature activation:

Between the upgrade candidate and activation, the schedule includes a graduated stake rollout: 10% of validators on September 8, 25% on September 14, and general adoption recommended on September 21. That means the network will be running v4.3 widely for a week before feature activation resumes on the 28th. Alpenglow's own activation is sequenced separately, and Anza notes the schedule is tentative and all dates are subject to change.

Alpenglow's 40% Fault Threshold vs. Tower BFT's 33% Ceiling

Alpenglow replaces Tower BFT as Solana's voting protocol while retaining Proof of History as the ordering mechanism. The core change is Votor, a two-round voting algorithm: an 80% stake threshold on the fast path finalizes blocks in approximately 150 milliseconds, with a 60% fallback threshold for notarization and skip decisions when the fast path does not clear.

Under Tower BFT, consensus requires more than two-thirds of stake to vote for blocks to reach confirmed status, which means any offline event exceeding one-third of staked SOL stops finality. Alpenglow tolerates a higher offline share in non-adversarial failure scenarios, covering the class of routing and datacenter incidents that cause correlated delinquency. Our Alpenglow upgrade analysis covers live test cluster data where 96% of blocks achieved fast-path finalization at 214ms.

A second structural change: Alpenglow moves validator votes off the block ledger. Under the current design, vote transactions compete with user transactions for block space. Votor communicates votes directly between validators through a separate data structure called Pool, removing that competition.

SHA512 Syscalls, Big-Integer Exponentiation, and Deeper CPI in 4.3

Beyond Alpenglow, the 4.3 feature set adds SHA512 hashing and big-integer modular exponentiation as new native syscalls, plus an increase in CPI depth. The cryptographic syscalls expand what Solana programs can compute without routing operations off-chain or through expensive workarounds, relevant for cryptographic verification use cases that have had to work around current syscall limits.

The 4.3 activation builds directly on Agave 4.2, which shipped the complete Alpenglow codebase, including Votor, but withheld mainnet activation pending further hardening and the 50,000 SOL bug bounty competition that ran through August.

What Validators Need to Do Before Alpenglow Activates

Validators must register a BLS public key on-chain before the Alpenglow feature gate activates. Any validator that skips registration will not be admitted into the Alpenglow consensus set. Solana's BLS pubkey and Validator Admission Ticket guide details the registration steps. The general adoption recommendation on September 21 marks the point at which all operators are expected to be on v4.3; validators still on v4.2 after that date would be running unsupported software.