Solana Alpenglow starts on October 21 in epoch 1064: what matters now for stakers

Solana gets a new consensus procedure on Wednesday, October 21, 2026, at around 15:00 UTC. The Solana Foundation has set the date for Alpenglow at epoch 1064. For everyone who only holds or transfers Solana, nothing changes: payments become final faster in future, wallets and applications keep running as before. If you have delegated your SOL, by contrast, there is one thing to settle, and to settle beforehand.

The upgrade sets two conditions for every validator. Miss them at the start of epoch 1064 and the validator no longer votes in the following epoch and produces no blocks. For the delegation attached to it, that means no staking rewards for that period. It can be checked beforehand, not afterwards.

Epoch 1064 begins on October 21 at 15:00 UTC

An epoch is the period for which Solana assigns its validators their duties in the network, and it always covers 432,000 slots, meaning 432,000 short time windows in each of which a block can be created. Alpenglow is armed at the start of epoch 1064.

Epoch 1057 was running on Wednesday morning. Seven epochs therefore lie before the switch, and the date is exactly a week away. The Solana Foundation names October 21 “at approximately 15:00 UTC” on its upgrade page; the word approximately is there for good reason, because the start of an epoch hangs on block progress rather than on the clock.

The switch for the upgrade, called a feature gate in Solana, carries the identifier A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS. It is active on testnet and on devnet; on mainnet it reads “not activated”. Alpenglow went live on devnet on September 25.

Alpenglow replaces TowerBFT, execution stays untouched

Consensus describes the procedure by which the machines of a network agree on the order of payments and on the point from which a payment can no longer be reversed. That is exactly the procedure Solana is swapping out: TowerBFT, in operation since the launch in 2020, gives way to Alpenglow.

Today it takes around 12.8 seconds for a payment on Solana to be final. Alpenglow targets about 150 milliseconds, barely a hundredth of that. CoinDesk puts the figure in sober context: the 150 milliseconds are a target, and the actual speed depends on the state of the network. As a side effect, the new procedure tolerates 20 percent malicious plus 20 percent offline stake, according to the Solana Foundation.

Important for everyone using an application on Solana: the execution of payments does not change. The Solana runtime environment SVM, the transaction formats and the fee mechanics stay as they are. Alpenglow intervenes one layer below, in the agreement on blocks.

The primary source clears up a widespread misunderstanding straight away: the 150 milliseconds are the time to finality, not the rhythm in which blocks are created. Block time was lowered independently of this, in four stages from 400 to 200 milliseconds, completed in October 2026.

Votor first, Rotor later: the upgrade comes in two phases

Alpenglow consists of two building blocks that arrive one after the other. On October 21, Votor starts, the voting part. Validators will send their votes directly to one another in future and bundle them into certificates, so that a block is final after one or two rounds of voting. Votor sits in Agave 4.3.

Rotor, the second building block, will later replace the way a block is distributed across the network. It is meant to replace the current distribution layer, called Turbine, with a single relay layer. There is no date for it yet; Rotor only arrives once Votor has settled into operation.

In practice, that means this for next week: on October 21 only the voting changes. Reading about “the Alpenglow upgrade” as a single event is reading a shorthand.

The first 5,000 slots still run on TowerBFT

One peculiarity concerns everyone who wants to watch live on October 21. The feature gate opens at the start of epoch 1064, yet the network works through the first 5,000 slots of the epoch on TowerBFT. Only after that does Alpenglow take over, at slot 459,653,000 according to the Solana Foundation, around 18 minutes after the epoch begins.

That figure can be recalculated, and it adds up. From the block progress on Wednesday morning, the start of epoch 1064 falls at slot 459,648,000. To the switchover named at slot 459,653,000 that is exactly 5,000 slots. The primary source's statement and the state of the blockchain therefore match to the slot.

In that window of a good quarter of an hour, the network still reports that it is running on the old procedure. Check at 15:05 UTC on October 21 and find no Alpenglow confirmation, and you are not looking at a fault but at this transition phase.

Agave 4.3.0 is mandatory, Firedancer is left out of the migration

The first of two conditions concerns the software. A validator has to run an Agave-based client before the start of epoch 1064, and on a version built on Agave 4.3.0. Agave itself, Jito-Solana and Harmonic Salsa are admitted.

A validator client is the program with which an operator takes part in the network. Several teams develop such programs independently of one another, which protects the network against bugs in a single implementation. That very diversity is briefly curtailed during the migration: Firedancer and Frankendancer, the clients from Jump Crypto, are explicitly not supported during the switch. CoinDesk states the consequence independently: operators have to change software temporarily.

For a delegator, that is the first question to put to their validator: is an Agave-based client running there, on a version built on Agave 4.3.0? Validators that rely on Firedancer and do not switch will not be part of the migration.

The Validator Admission Ticket costs 0.8 SOL per epoch

The second condition is a question of money. A validator has to hold at least 0.8 SOL in its vote account, on top of the amount that has to sit there as a minimum balance anyway. The Validator Admission Ticket, VAT for short, is paid out of that balance, a kind of entry fee for taking part in the voting.

The schedule behind it is staggered: the first fee is debited at the start of epoch 1064 and pays for participation in epoch 1065. It continues from there, each epoch paying for the next. The Solana Foundation writes the sentence that matters here: if the fee is not paid, the validator does not vote in the next epoch and produces no blocks.

It even gets cheaper. Until now validators paid for their votes as ordinary transaction fees, around 1 SOL per epoch according to CoinDesk. Those costs fall away and are replaced by the flat 0.8 SOL, a fifth less.

An epoch now lasts around 26 hours instead of two days

A calculation of our own is worth doing here, because it appears in no report. An epoch covers 432,000 slots. As long as a slot lasted 400 milliseconds, that was two days. After the reduction to 200 milliseconds, the epoch shrinks accordingly.

From the gap between the block count on Wednesday morning and the announced start of epoch 1064, a slot time of around 218 milliseconds follows. An epoch therefore lasts a good 26 hours, about a day. Many older explainers still cite 38 or 48 hours; those figures date from before the reduction.

For the fee, that is the actual point. The 0.8 SOL does not fall due every two days but a good once a day. Annualised, that is around 267 SOL per validator, or just under $28,700 at a price of $107. On Wednesday morning the network listed 678 validators with a vote account, 673 of them active and five delinquent. Scaled up, the entire network therefore pays around 542 SOL per epoch, roughly $58,000.

Operators of a validator with little delegated stake have to earn that fee out of block rewards. For large operators, 0.8 SOL a day is a line in the overheads; for small ones it is a hurdle.

Solana's transaction counts collapse on October 21 without usage falling

One consequence of the upgrade will cause confusion in the coming weeks, for everyone who judges Solana by its metrics. Until now the validators' votes were ordinary transactions in the block and were counted as such. With Alpenglow they leave the block entirely.

Addressing developers, the Solana Foundation writes that any metric which counted votes should be put on a new baseline. CoinDesk draws the consequence for outsiders: Solana's reported transaction count could fall sharply without usage by real users declining.

So anyone who sees a chart of Solana's transactions per second pointing steeply downwards after October 21 should check the date first. A break in the measurement looks exactly like a break in the market in a chart. At Solana the share of votes in all transactions has traditionally been high, so the jump will be pronounced.

Two further changes mainly concern developers, but they explain why this is called a breaking change. The two confirmation levels confirmed and finalized merge and will mean the same thing. And Proof of History, Solana's own timekeeping, gives up setting the pace of block production; the timestamps attached to it disappear from the data stream.

The validator behind your delegation: client version and vote balance

Delegating SOL transfers your voting rights to a validator while you keep the coins. The delegator shares that validator's failure risk: if the validator does not vote in epoch 1065, the staking rewards of the delegation attached to it fall away for that period. The SOL themselves are not affected; they stay untouched.

Two details can be settled before October 21. First, the validator's client software including its version. Second, the balance of its vote account, which has to carry the necessary 0.8 SOL on top of the minimum amount. Both appear in the public validator overviews, and staking through a provider means asking them for it.

The situation is simplest with large, professionally operated validators that have worked on the switch anyway. A small validator whose operator rarely publishes anything deserves attention. If the choice is hard: a delegation can be moved to another validator at any time, though the change only takes effect with the next epoch, so it takes a good day.

Staking via exchange, wallet or your own validator: who carries the risk

For investors in Germany three routes come together, and they differ on precisely this question.

Staking through an exchange means having nothing to do with clients and vote accounts. The exchange operates its own validators or works with partners and is responsible for their readiness. In return you carry the exchange's counterparty risk. An overview of the providers and their terms is in the comparison of staking platforms.

Delegating out of your own wallet means choosing the validator yourself. Here the two checks above apply directly, and in return the SOL stay in your own custody.

Running a validator yourself means actively meeting both conditions. For that group, October 21 is a working date, not a reading date.

For tax purposes the upgrade changes nothing. In Germany, staking rewards count as other income under Section 22 number 3 of the Income Tax Act and are taxable in the year they are received, with an exemption threshold of €256 a year. For the staked SOL themselves, the one-year holding period under Section 23 of the Income Tax Act continues to apply; the Federal Ministry of Finance scrapped the earlier extension to ten years for staking back in 2022.

Our assessment: the failure risk is concentrated at small validators

From the editorial team's point of view, the risk for the average German staker is low but not zero, and it is spread unevenly.

Three pieces of evidence argue for that. The switch has been running on devnet since September 25 and on testnet before that, so operators have had weeks. At 0.8 SOL per epoch the fee sits below the previous voting costs of around 1 SOL, so it demands no additional budget. And with 438 million SOL staked, 74.4 percent of circulating supply by our own measurement, the bulk of the stake hangs on a few large validators whose operators are accompanying the switch.

Against that stands the exclusion of Firedancer. It forces precisely those operators who deliberately chose an alternative implementation into a software change, and a change under time pressure is the classic source of error. How much stake hangs on Firedancer validators cannot be read out of the public data; that gap remains. Five delinquent validators out of 678 are the normal state against which it will be possible to read, after October 21, whether the switch went quietly.

No recommendation to buy or sell SOL follows from this. Solana traded at $107 on Wednesday morning, just under 10 percent below its level the week before. Total loss is possible with any cryptocurrency.

What your own holdings say about Alpenglow, and what has changed since September

This date has a backstory that belongs to the picture. At the end of September, September 28 was circulating as the activation date. A mix-up lay behind it: in the roadmap of the developer house Anza, that day merely marked the general resumption of feature activations, without naming Alpenglow. We put the missed date in context at the time.

The checking route for delegators was already in our piece of September 1, though still with the old date there. Exactly three things have changed since: the date is now fixed, the Agave 4.3.0 condition has been named, and the fee has a number at 0.8 SOL. How the stake is distributed across the validators and where the blocking minority sits is something we measured at the beginning of October.

Coverage in German is still lagging behind this state of play. Pieces that carry September 28 as the date or speak of an upgrade “without a fixed date” have been out of date since Wednesday morning. When reading any statement about Alpenglow, look at the publication date.

Alpenglow on October 21: 0.8 SOL decide one epoch of rewards

The date is set, the conditions are named, and both can be settled in the coming week. Three steps are enough:

1. Establish who has delegated your SOL. With a provider, responsibility for the client and the vote balance lies there; ask whether their validators run on Agave 4.3.0. Which providers offer which terms is shown in the comparison of crypto exchanges.
2. With your own delegation, check the two details. Client software including version, and the balance in the vote account. If one of them is wrong, the delegation can be moved before October 21; the change takes effect with the next epoch. To hold your SOL in your own custody while doing so, the devices are in the comparison of hardware wallets.
3. Record your staking rewards for tax. The rewards count in the year they are received, and the exemption threshold is €256. The tools for that are in the comparison of crypto tax software.

The details on the date, on Agave 4.3.0 and on the Validator Admission Ticket come from the Solana Foundation's upgrade page; the framing of the costs and the transaction counts is confirmed independently by CoinDesk.

(As of October 14, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)