Alpenglow Tracker Flags 45% of Solana Stake as Not Ready Two Days Before Epoch 1064, Most of It on Agave 4.3.0 and 4.3.1

As of 16:17 UTC on October 19, the Alpenglow Watchtower run by validator operator Pumpkin's Pool listed 317 Solana SOL$103.99+2.3% validators holding 198.1 million SOL, or 45.2% of stake, as not ready for Alpenglow. Alpenglow is the consensus upgrade that replaces TowerBFT, the voting system Solana runs today, and the Solana Foundation's Alpenglow page says it activates at the start of epoch 1064, "approximately 13:20 UTC" on Wednesday, October 21. More than half of the flagged stake, 109.2 million SOL, sits with validators on Agave 4.3.0 or 4.3.1, which the tracker itself says "carry the migration but are not the required release." The remaining 88.9 million SOL, about a fifth of all stake by the tracker's count, is flagged for problems that need more than a patch upgrade.

Pumpkin's Pool posted the new client check at 13:52 UTC with three instructions for operators: "Move to an Agave based client - preferably 4.3.2", "Fund your vote account with at least 0.8 SOL" and "Make sure you set your BLS pubkey." The tracker is a snapshot. Its page says balances and keys are read from chain about every 10 minutes, and operators can still switch clients, top up vote accounts or register keys before the epoch boundary.

How the Alpenglow Watchtower defines a validator as not ready

The Pumpkin's Pool tracker counts a validator as ready only if, from the epoch 1064 boundary, it "runs Agave 4.3.2 and its vote account holds a BLS key and can pay the 0.8 SOL admission ticket." That matches the Foundation's operator checklist, which says validators must upgrade to v4.3.2 of Agave, Jito-Solana or Harmonic Salsa, the three clients built on the Agave code that Anza maintains, and hold at least 0.8 SOL above the rent-exempt minimum in the vote account. Jito JTO$0.443+4.4% publishes the Jito-Solana build.

Anza's own guidance on the 4.3 line is looser. Asked which versions would cause trouble, Anza's Brennan Watt replied on X on October 17 that validators on "v4.2 or earlier" will "get forked off," while "v4.3 versions are fine, but v4.3.2 is the most performant and stable." On that reading, the 193 validators the tracker lists on 4.3.0 or 4.3.1 are below the Foundation's stated requirement but on a release line Watt calls fine. We covered Anza naming v4.3.2 the recommended release for all validators on October 16.

The tracker's other categories are 77 validators on "a client or version that cannot migrate," 52 with an unfunded vote account and one without a BLS key. Some rows on the list carry more than one problem, so the categories overlap.

Firedancer, pre-4.3 builds and unfunded vote accounts make up the harder fifth

Firedancer and Frankendancer, the independent clients built by the Firedancer team at Jump, "are not supported during the migration," according to the Solana Foundation, which says Firedancer operators "should switch to agave before the start of epoch 1064." The Pumpkin's Pool tracker adds that the Firedancer team will announce when it is safe to switch back. Client concentration was one of the themes in Fidelity's FCAT report on Solana, which we covered on October 17, and the migration asks every voting validator to run Agave-based software for now.

The five largest validators the tracker flags are Helius hSOL$125.09+2.2% (15.7 million SOL, listed as running Jito 4.2.2 and needing 4.3.2), Everstake (7.8 million SOL, Firedancer 26.9.6), Galaxy (7.0 million SOL, Firedancer 26.10.2), Staking Facilities (6.7 million SOL, Harmonic Firedancer 26.9.6) and Forward Industries (6.6 million SOL, Firedancer 26.9.6). Solana Compass's validator list, refreshed at 16:15 UTC, shows the same stake for each and labels all but Helius as Firedancer-family clients. Our data also counts 437.9 million SOL of activated stake network-wide, matching the total behind the tracker's percentages. For the Firedancer operators the fix is the documented switch to an Agave-based build; for Helius the listed fix is a version upgrade. We found no public statement from any of the five about their migration plans, and the tracker cannot show changes made after its snapshot. The list also includes the Solana Compass validator, flagged at snapshot time for a vote account holding 0.00 SOL against the 0.8 SOL needed.

The vote-account check bites one epoch later than the client check. The Foundation says the first Validator Admission Ticket (VAT) fee "is charged at the start of epoch 1064 and pays for epoch 1065," and a validator that cannot pay "does not vote or produce blocks in the next epoch." Missing BLS keys already have consequences: since VAT activated on July 22, the Foundation says validators without a registered BLS key "are now excluded from the VAT admitted validator set."

Why ready stake matters for the SIMD-0384 genesis vote and Votor thresholds

The handoff to Alpenglow depends on enough stake taking part. SIMD-0384, the migration specification by Anza's Kobi Sliwinski, Ashwin Sekar and Carl Lin, sets a migration boundary 5,000 slots after the feature activates. The Foundation puts that at about 18 minutes into epoch 1064, at slot 459,653,000. From that slot, blocks carry only vote transactions while validators cast a BLS "genesis vote" for the last TowerBFT block, and Alpenglow takes over once those votes reach 82%, which the SIMD calls the genesis certificate.

Until the certificate forms, SIMD-0384 says validators "perform regular TowerBFT consensus for all blocks" and refresh their genesis votes once a slot. The spec expects the pause in ordinary transactions to last "optimistically only one slot past the migration boundary slot." The tracker's notes say the migration code "only exists in Agave-based clients," so Firedancer and Frankendancer nodes cannot take part in it.

After the handoff, Votor, Alpenglow's voting protocol, finalizes a block in one round when at least 80% of stake votes for it, and in two rounds at 60%, according to the Foundation, which says the protocol "tolerates 20% of adversarial stake plus 20% of offline stake while still reaching consensus." The tracker's 45.2% applies its own rules, including a VAT balance that first matters for epoch 1065, so it is not a count of stake that will miss the genesis vote. We found no published stake threshold in the Foundation or Anza material that would delay the feature gate itself.

Epoch 1064 timing: the Alpenglow activation estimate moved to about 13:20 UTC

When Anza set the date on October 13, we reported a go-live time of about 14:50 UTC. The Foundation page now gives approximately 13:20 UTC for the start of epoch 1064 and tells readers to "treat 13:20 UTC as an estimate and track the epoch." The Pumpkin's Pool tracker projects 13:33 UTC. The trigger is the epoch boundary, so the clock time drifts with slot pace.

Solana Compass's epoch records show the last nine complete epochs, 1053 to 1061, lasting between 25.9 and 26.2 hours, with epoch 1061 taking 26.0 hours at an average slot time of 216.8 milliseconds. At 16:22 UTC on October 19, epoch 1062 had about 19 hours left. On that pace, our arithmetic puts the epoch 1064 boundary in the same early-afternoon UTC window on October 21.

Anyone can check whether the switch has happened. The Foundation says the new getAgGenesisCert RPC method returns null while the cluster is still on TowerBFT and returns the genesis certificate once it has migrated.