Skip to main content
Solana Swaps Its Consensus Engine for Alpenglow
News
Security
6 min read5 views

Solana Swaps Its Consensus Engine for Alpenglow

Floriano Righetti
Floriano Righetti

On Wednesday, 21 October 2026, Solana is scheduled to replace TowerBFT, the consensus protocol it has run since launch, with a new protocol called Alpenglow. At the time of writing, the switch has not happened. The Solana Foundation calls it Solana's first major consensus replacement since TowerBFT, and Anza, the team that builds the Agave validator client, describes it as the biggest upgrade in the network's history. Consensus is how validators agree on the order of transactions and on when a transaction can no longer be reversed. Transaction execution, programs and fees do not change.

What is scheduled#

According to the Foundation, the Alpenglow feature gate activates at the start of epoch 1064, estimated for about 13:20 UTC. Activation does not switch consensus immediately. The network keeps running TowerBFT for a further 5,000 slots, which the Foundation puts at about 18 minutes, and Alpenglow consensus takes over at slot 459,653,000. In a post cited by Solana Compass, Anza projected that moment at "~14:00 UTC." Solana Compass, which operates a validator, notes that epoch start times drift with slot timing, and its own estimate from recent slot times placed the epoch start nearer 13:44 UTC. We treat all times as estimates. The switch is defined by a slot number, not by a clock.

Anza describes the handoff in steps. After the boundary, blocks carry only votes, so they can be rolled back without losing any user transaction. Validators then sign a vote for an Alpenglow genesis block, and a genesis certificate forms once 82% of stake has signed. Consensus passes to the new voting protocol, and user transactions resume. Anza expects the handoff itself to take hundreds of milliseconds. The Foundation says a new RPC method, getAgGenesisCert, returns null while the cluster runs TowerBFT and a certificate once it has migrated, which makes it the reliable way to check the outcome.

What changes#

Under TowerBFT, validators vote by sending transactions, and the Foundation puts the time to finality at about 12.8 seconds. Alpenglow's first component, Votor, has validators send votes directly to each other and aggregate them into certificates. A block can be finalized in one round if at least 80% of stake votes to notarize it, or in a second round at 60% thresholds. The stated target is roughly 150 milliseconds. The Foundation calls this an expectation that depends on stake distribution, not a constant.

The fault model also shifts. The Foundation and Anza say Alpenglow tolerates 20% adversarial stake plus 20% offline stake at the same time. Anza describes TowerBFT's adversarial threshold as under 33%. Engineers at Galaxy Digital who have run validators on the Alpenglow test cluster wrote that slashing for double voting is defined but deliberately not enabled in this first version, as reported by Solana Compass. The second phase, Rotor, which replaces the Turbine block propagation layer, is planned for a later release and is not yet scheduled.

Validator costs change in form. According to the Foundation, voting under TowerBFT costs about 1 SOL per epoch in vote transaction fees. Under Alpenglow, each voting validator pays a flat Validator Admission Ticket of 0.8 SOL per epoch from its vote account, charged one epoch in advance and burned. A validator whose vote account cannot pay does not vote or produce blocks in the next epoch. Validators also need a registered BLS key; since July, those without one have been excluded from the admitted validator set.

Where the sources differ#

Reported figures are not fully consistent. CoinDesk describes current finality as "about six seconds," while the Foundation's documentation gives about 12.8 seconds. CoinDesk puts current vote costs at about 2 SOL a day, while the Foundation cites about 1 SOL per epoch. Published times range from about 13:20 to about 14:00 UTC, depending on whether they refer to the epoch start or the consensus switch. We rely on the Foundation's documentation for figures and do not calculate cost comparisons of our own.

What is not yet known#

Whether the switch completes as planned can only be confirmed afterwards. Whether mainnet reaches the 150-millisecond target under real stake distribution and load can only be measured once Alpenglow is running. Readiness was also still moving. Solana Compass, citing SolanaFloor and a public readiness tracker, reported 20.3% of stake flagged as unprepared on the morning of 20 October, down from 45% the day before. It also noted that it is not clear how much of the drop reflects upgrades rather than a change in how the tracker counts. How much stake is actually voting when epoch 1064 begins is the number to watch.

There is also a temporary client-diversity question. The Foundation says the Firedancer and Frankendancer clients are not supported during the migration, so operators must run version 4.3.2 of an Agave-based client: Agave, Jito-Solana or Harmonic Salsa. Galaxy's engineers wrote that Firedancer operators can return after the switch, while Frankendancer will not be supported once Alpenglow is active. For the duration of the migration, the network relies on clients built on one codebase.

Why it matters for infrastructure teams#

The Foundation says wallets and applications that only send transactions and read account state need no changes. For anyone who indexes, streams or measures the chain, it lists breaking changes:

  • Vote transactions leave blocks, so transaction counts drop sharply without any drop in real activity.
  • A slot can carry more than one candidate block, so streaming pipelines should buffer data by slot and bank (bank_id), not by slot alone.
  • Tick entries leave the ledger, and each block's leader now sets the program-visible timestamp within a bounded range.
  • confirmed and finalized become equivalent once the switch is complete. The Foundation advises moving to finalized only after Alpenglow is live.

Dashboards and alerts built on the old assumptions will need re-baselining, or they will read a change in accounting as a collapse in activity.

We will review the migration record and early finality data once the switch is complete, and update this article.

Sources#

This article is for information only and is not investment, legal or financial advice.

Share this article

Related Articles