Alpenswitch is on public testnet: Solana is rehearsing the move to its new consensus, Alpenglow
This week Solana's public testnet is running the migration that moves a cluster from TowerBFT to Alpenglow. Anza said on September 22 that Alpenglow is coming to testnet this week, and that the rehearsal uses the same procedure later planned for devnet and mainnet-beta. A community cluster has already run Alpenglow for more than four months and practiced the switch. This is not a mainnet launch.
Two names for one change
Alpenglow (SIMD-0326) is the consensus upgrade. It replaces TowerBFT with a voting protocol called Votor. Votes move off the ledger into direct messages between validators. The target is finality in about 150 milliseconds. TowerBFT is often quoted at about 12.8 seconds, and that quote belongs to an older, slower slot clock. Mainnet's clock is faster now. Alpenglow reaches 150 milliseconds by changing how validators agree, not by speeding up that clock.
Alpenswitch (SIMD-0384) is the migration procedure. At a migration boundary the cluster flips from TowerBFT to Alpenglow. If that flip fails, it falls back to TowerBFT. Public testnet is exercising that handoff now. Devnet and mainnet-beta are meant to run the same procedure later, each on its own schedule.
How Votor, the Validator Admission Ticket, and the still-closed mainnet gate looked in July is in the Alpenglow status note.
What Anza announced
On September 22 Anza said Alpenglow is coming to public testnet this week. The note was specific about the procedure: testnet runs the same migration that devnet and mainnet-beta will run later. The community cluster has already been on Alpenglow for more than four months and has rehearsed that handoff.
Read the testnet move as underway this week. The public tracker can still list it as pending while operators get ready. There is no finished "it flipped at epoch N" time to report yet.
The first pass is Agave 4.3 only. Firedancer and Frankendancer do not support this Alpenglow testnet migration, so operators on those clients need Agave for the rehearsal. Later clusters will set their own client mix.
The same Anza schedule has a second date, and that is the line people are mixing up with this testnet news. September 28 is listed as a tentative day to turn on Agave 4.3 feature gates on mainnet. It sits on the release calendar beside the testnet announcement. It is a different item.
Finality and the clock are different levers
250ms slots went live on mainnet at epoch 1037. That change shortened the slot, the window a leader has to produce a block. It did not change how long the network waits before a block is irreversible. Alpenglow is the other lever: how validators agree that a block can no longer be undone. A faster clock and faster finality both change how apps feel. They are separate switches.
Once Alpenglow is actually live on a cluster, apps on that cluster can feel finality much sooner. Execution does not change: the SVM, transaction formats, and fees stay as they are. Rotor, the later data-propagation piece, is not part of this testnet pass.
What it means for…
Validators
This rehearsal wants Agave 4.3. Read Anza's operator notes before the testnet gate, and do not assume Firedancer or Frankendancer can take this first migration. The community cluster already practiced the switch; public testnet is the formal pass of that same migration. The September 28 mark above may open some Agave 4.3 gates on mainnet. It is not the day mainnet moves to Alpenglow.
Delegators
This consensus change should not create any extra hassle for you. The stake you already delegated stays with the same validator during the testnet rehearsal and when mainnet switches later.
Builders
Nothing in this week's testnet pass requires a mainnet program or wallet change. Do not ship mainnet UX that assumes ~150ms finality. On mainnet, finalized still means the TowerBFT wait. On a cluster that has completed Alpenswitch, confirmation and finality draw together, and vote transactions leave blocks, so indexers should re-baseline counts after that cluster has actually migrated, not on a calendar date. Slot duration and finality stay separate: keep the current slot time from the 250ms slots change, and do not treat 150ms as a new slot length.
Everyone else
If you hold or send SOL on mainnet, you do not configure anything, and this week does not make transfers finalize in 150ms. If you use apps pointed at public testnet, they can start to feel final much sooner once that cluster's migration is in effect. Wallets do not need a new flow on either cluster.
Sources: Solana – Alpenglow · SIMD-0326 · SIMD-0384 · CoinDesk – public testnet finality test · ForkLog – activation on testnet