← All Solana news

Alpenswitch is on public testnet: Solana is rehearsing the move to its new consensus, Alpenglow

Share on X

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.

Alpenswitch: a dark cluster crossing from stacked confirmations into one short agreement pulse
Public testnet is where the migration gets exercised. Mainnet still agrees on blocks with TowerBFT.

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.

What that September 28 mark means Agave 4.3 is already installed on mainnet. It arrived on September 18 with the Alpenglow code inside and the switch still off. A feature gate is that switch: the software can sit on a validator before one ability is turned on. September 28 is the tentative day on that calendar for opening some of those switches. It does not move mainnet onto Alpenglow. Operator notes still aim the consensus flip at a later release. Until the Alpenglow gate actually opens, mainnet keeps finalizing blocks with TowerBFT. How this client line got here is in the Agave 4.2 note.

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.

In plain terms Finality is the moment a bank transfer becomes irreversible. TowerBFT is waiting through a stack of confirmations before the bank will treat the payment as done. Votor is a short, direct round of agreement among the validators who have to sign off – one conversation, where the old path was a pile of receipts.

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.

In one sentence Public testnet is rehearsing Alpenswitch, the move from TowerBFT to Alpenglow. The September 28 line on Anza's schedule is a possible day for other Agave 4.3 switches. Mainnet has not moved to Alpenglow.

Sources: Solana – Alpenglow · SIMD-0326 · SIMD-0384 · CoinDesk – public testnet finality test · ForkLog – activation on testnet

Share on X