Alpenglow: What We Learned Running Solana's Biggest Consensus Change

TL;DR: Alpenglow, scheduled to go live on Solana mainnet on Wednesday, October 21, changes how validators agree on blocks. Votes move off the chain, finality is designed to drop from seconds to around 150 milliseconds, and a flat 0.8 SOL per-epoch fee replaces per-vote costs. Nothing changes in how stake earns rewards. Galaxy has run Alpenglow on the community test cluster since June 2026, through six re-geneses and the first successful migration, and our validators are ready.

Galaxy has operated a validator on Solana's Alpenglow test cluster since June 2026, through six re-geneses (each wiped the chain and restarted it from a fresh genesis block), a migration that failed network-wide, and a rollback. This is what that taught us.

Alpenglow is the largest change to Solana's core protocol since the network launched. Designed by Anza, Solana's core development team, it replaces the way validators vote on and finalize blocks, and it is scheduled to activate on mainnet on Wednesday, October 21, at the start of epoch 1064.

How Galaxy Took Part

A consensus rewrite cannot be validated on paper. It has to be started, broken, restarted and broken again. That is what Solana's Alpenglow community cluster exists for.

It launched in early May 2026 with around 50 independent operators and has since grown to roughly 100 validators. Everyone taking part is a volunteer, running their own hardware across different datacenters and time zones, which surfaces problems that no controlled environment produces.

Along the way, we rehearsed failovers between machines in both directions under Alpenglow's stricter rules on double voting.

Figure 1. Galaxy's validator on the Alpenglow community cluster, from joining on June 18, 2026, through six re-geneses, the first successful migration and the first rollback.

What Changes

Since launch, Solana has used TowerBFT, where validators vote by submitting transactions to the chain itself. Vote transactions account for roughly three quarters of everything the network processes and before the recent slot-time reductions, a block took about 12.8 seconds to reach full finality, about 6 seconds at today's 200ms slots. Alpenglow changes both, with a finality target of around 150 milliseconds.

Votes leave the chain. Validators exchange votes directly with each other rather than submitting them as transactions. The votes are signed with BLS, so many signatures aggregate into one compact certificate proving that enough stake voted, and that certificate goes into the next block in place of hundreds of individual vote transactions. If 80% of stake votes to notarize a block, it finalizes in a single round; if participation is lower, a second round finalizes it once a 60% notarization certificate and a separate 60% finalization certificate both exist. Both paths run concurrently, and whichever completes first decides.

Proof of History retires once the migration completes, because votes now arrive in a single network hop and the chain no longer needs a shared cryptographic clock.

A flat fee replaces per-vote fees. Each validator burns a Validator Admission Ticket from its vote account every epoch. SIMD-0357 sets it at the commonly quoted 1.6 SOL, a figure specified against the original 400ms slot and 48-hour epoch. Because the charge scales with slot time, it works out to roughly 0.8 SOL per day at every step, and now that mainnet has reached 200ms, the ticket at activation will be 0.8 SOL per epoch against an epoch of about 24 hours.

The fault model changes. Alpenglow is built for what its designers call “20 plus 20”: fewer than 20% of stake actively misbehaving, plus a further 20% simply crashed or offline.

The total budget rises from 33% to 40%, but the share that may be actively hostile falls from 33% to 20%. That is the tradeoff: less stake is needed to threaten safety, in exchange for tolerating more stake going offline. The designers accepted it because Solana's outages have come from bugs, congestion and correlated crashes rather than coordinated attacks.

Is Voting Cheaper?

It helps to separate Alpenglow from the slot-time cuts that finished on October 9. Faster blocks and shorter epochs came from those; Alpenglow brings faster finality, votes off the chain and the flat admission ticket.

For the vote itself, the answer is yes. Under TowerBFT, a validator pays a fee on every vote, once per slot, so the slot-time cuts pushed that bill up: about 1 SOL a day at 400ms and about 2 SOL a day at 200ms. The admission ticket replaces it with a flat 0.8 SOL per epoch, roughly 0.8 SOL a day, which is less than half of what validators pay to vote today. Anyone reading the rising vote costs of the last two months as an Alpenglow effect has it the wrong way around: the slot-time cuts raised the cost, and Alpenglow brings it back down.

Figure 2. What a validator pays per day to vote at each slot-time step, against the flat admission ticket that replaces it. Each step is labeled with the date and epoch it took effect on mainnet.

The saving is not the whole picture. Half of every vote fee went to the leader of the block that included it, so validators that produce many blocks also collected vote fees, and that income goes away along with vote transactions. The net effect for any one validator depends on how many blocks it produces. And this upgrade is about the cost of voting; the larger costs of running a validator, such as hardware, bandwidth and hosting, are a separate matter.

SIMD-0326 does not change how vote rewards are earned. What changes is the accounting: vote credits are now derived from BLS certificates rather than from vote transactions on chain, and on the cost side the admission ticket replaces per-vote fees and is charged to the vote account.

What It Means in Practice

For anyone building on or settling through Solana, the change that matters is not the headline number but how quickly a transaction becomes safe to rely on. Applications that waited seconds for finality can treat a transaction as final in a fraction of that. For stakers, nothing changes in how stake earns rewards. For validator operators, the cost of voting moves to the vote account.

Moving votes off the chain also returns a large share of block space to user activity, and the flat admission ticket gives validators a predictable cost in place of a fee that scaled with how often they voted. A vote account that cannot cover the ticket at an epoch boundary is excluded from consensus for that entire epoch, so the funding operators used to keep in their identity accounts will now belong in the vote account.

At Galaxy, an automated top-up service refills each vote account well before it approaches the admission threshold, and balances are continuously alerted on.

The Migration Itself Runs on Agave

Validators have been asked to run an Agave-based client through the migration. Operators on Firedancer can fail over to Agave beforehand and return afterwards, since Firedancer's 26.10 release supports Alpenglow. Frankendancer will not be supported once Alpenglow is active. Galaxy's validators will run Agave through the migration and return to Firedancer once it completes.

What Comes Next

Alpenglow is arriving in phases:

• Phase 1: Votor, the voting change described here.

• Phase 2: A fast leader handover, letting the next leader start building optimistically rather than waiting for the previous window's decision.

• Phase 3: Rotor, which flattens block propagation into fewer hops.

Slashing for validators that vote twice for conflicting blocks is well defined but deliberately not enabled in the first iteration.

Galaxy is one of the largest Solana validator infrastructure operators globally and has tested Alpenglow on the community cluster since June 2026. Our staking and infrastructure solutions give institutions secure, high-performance access to Solana. Get in touch here .