Solana Alpenglow will not arrive on September 28: “No Alpenrush”, says Anza's head of research

Alpenglow, the new consensus mechanism for Solana, did not go into operation on mainnet on September 28, 2026. The date that had been running through calendars and headlines for weeks comes from a schedule entry that means something else. Anza, the development house behind the most important Solana validator client, has expressly denied that an activation took place that day.

For you as a holder of Solana, the first consequence is that nothing happens today. Anyone who was considering unstaking because of the date, preparing a validator switch or planning withdrawals around it can put that aside. The coin traded at $118.75 on September 28, 3.29 percent below the previous day, while the seven-day balance was almost unchanged at 0.55 percent (data: CoinGecko).

This piece sets out where the date came from, what has actually been decided and which date counts next. And it records that cryptoticker.io named September 28 itself.

What really stood in the Solana calendar for September 28

Anza published the schedule for version 4.3 of the Agave validator client on August 12, 2026. It lists September 28 with the entry “Mainnet-beta: Resume feature activation”. Translated, that says: from that day Anza works through the queue of pending protocol switches on the production network again. Alpenglow is not named in that entry.

Feature gate is the technical term for such a switch: a code change that already sits in every running copy of the software but only takes effect once enough validators release it. Solana opens these gates at epoch boundaries, and an epoch lasts around 38 hours. A date in the schedule therefore marks the start of a window, not the minute at which a particular feature goes live.

In the reporting, “feature activations resume from September 28” turned into “Alpenglow arrives on September 28”. That is the entire origin of the date. No postponement in the proper sense, but a date that was never assigned to Alpenglow.

Anza and Yakovenko contradict the expectation around the date

As the expectation of a weekend launch gathered pace, the developers spoke up. Solana co-founder Anatoly Yakovenko answered the rumours of an imminent mainnet launch with a single word: “decel”, the opposite of accelerating.

Roger Wattenhofer, head of research at Anza, was more explicit. He asked publicly why a protocol should be activated that had only been in public testing for a few days, and closed with the sentence “No Alpenrush”. Those two statements are the reason several specialist newsrooms now describe September 28 as wrong.

This is not a cancellation of Alpenglow. It is the statement that a consensus mechanism which changes how the network agrees on a valid state is not laid over a network carrying billions in value after a few days of test operation.

Alpenglow has been running on testnet since September 22

What did happen: on September 22, 2026, Alpenglow went live on the Solana testnet. There it replaces the previous mechanism and makes confirmed blocks final at the same time. The distinction between “confirmed” and “finalized”, which exchanges and applications have gone by until now, loses its purpose on testnet as a result.

The activation had an immediate consequence for operators on testnet: Frankendancer, an intermediate stage on the way to the alternative client Firedancer, lost support there. Anyone still running it had to switch. For mainnet that does not yet apply.

Votor replaces TowerBFT: how the new consensus reaches finality

Votor is the component that takes over validator voting in Alpenglow and supersedes the previous TowerBFT mechanism. The most visible difference lies in the time to finality of a transaction. Depending on the source, the target is given as 100 to 150 milliseconds; today several seconds pass before finality.

The second point is less spectacular and, for validators, the more important one: Alpenglow does away with separate voting transactions. Until now validators write their votes into the chain as transactions of their own and pay fees for them. If that item disappears, the cost calculation of running a validator shifts noticeably, and with it, over the long run, the arithmetic behind the staking rewards that reach you.

The complete code for this already sits in Agave 4.2, Votor included. At Solana, however, shipped does not mean switched on. Anza deliberately held back mainnet activation at the time until further hardening and a bug bounty competition worth 50,000 SOL, which ran in August, had been completed.

November 9 is the next window, not a launch date

On September 22, Anza published the schedule for Agave v4.4 and created the corresponding development branch the same day. It contains two dates: on devnet, feature activations resume from October 7; on mainnet-beta, from November 9.

This entry, too, does not name Alpenglow. It again describes a window in which switches can be released. In Anza's feature gate tracker, SIMD-0326, the identifier of the Alpenglow proposal, still sits in the list of features awaiting a mainnet activation. There is no confirmed date for that one switch.

If you want to follow the progress yourself, Anza's feature gate tracker is the place where the status changes first. As long as SIMD-0326 sits there among the waiting entries, nothing is switched on mainnet.

Your SOL in staking: unstaking period and epochs in the schedule

For staked SOL, the date that did not happen changes nothing. What remains important is the mechanism that applies anyway: a delegation does not come free immediately but at the end of the current epoch, and an epoch lasts around 38 hours. Anyone who wants access to their SOL at short notice should factor in that waiting time.

Anyone drawing rewards through a platform rather than through their own delegation should read the terms there regularly in any case: minimum terms, fee shares and the question of whether the platform holds the coins or merely arranges the delegation differ widely. These points decide the return more than the advertised percentage does.

Switching validators purely because of a protocol date makes no sense. It makes sense where your validator shows persistently poor availability or charges high commission. That assessment is due independently of Alpenglow.

Holding period and tax remain untouched by the upgrade date

A protocol change is neither a swap nor a disposal. Your SOL remain the same coins, with the same acquisition date. The one-year holding period for private disposals therefore continues to run, regardless of when Alpenglow is switched live.

Ongoing staking rewards are a different matter: those rewards arise at the moment they are allocated to you and are treated separately from any price gain. Anyone collecting many small allocations over the year needs a clean record. It has to be a record that still makes sense months later. For the assessment of your particular case, your tax adviser remains the right address.

Buying route and custody for SOL in Europe

Anyone wanting to buy SOL in Europe has had a simpler preliminary test since the EU regulation on markets in crypto-assets took full effect: the provider needs MiCA authorisation, and anyone acting as a service provider in the EU must be able to evidence it. That is no substitute for a look at the fees, though it narrows the field sensibly. The cost models of the licensed trading venues still differ considerably, from the spread to the withdrawal fee.

On custody the familiar principle applies: what sits on an exchange is yours only on the exchange's terms. Anyone holding larger amounts over months who does not trade anyway sleeps more soundly with their own wallet; our hardware wallet comparison sets out the differences between the devices. For staked SOL that is a trade-off, though, because delegating from your own wallet means more work of your own.

How to handle postponed protocol dates

Dates for network upgrades are planning figures, not commitments. For Ethereum, Base and Solana alike: a date in a release schedule describes when a development team would like to ship something, provided nothing speaks against it by then.

A date becomes dependable only once it appears in the source that actually throws the switch, meaning the feature gate tracker or the client maker's own announcement. Secondary reports often adopt a date faster than the developers confirm it. With Alpenglow, that is exactly what produced September 28.

In practice, that means: do not tie a selling, unstaking or tax decision firmly to an announced upgrade date unless it comes from the primary source. The cost of reacting too early, such as an unnecessary unstaking wait of two epochs, is one you carry yourself.

What cryptoticker.io wrote about September 28

For completeness: we carried the date too. On September 1 we published “Solana Alpenglow: activation from September 28, and what delegators should check now”, and on September 23 a price piece followed that framed the market five days before Alpenglow. Both texts rested on the Agave schedule as published at the time.

That framing has proved to go too far. The schedule named a window for feature activations, not the launch of Alpenglow. We record it here so that the earlier account does not stand without comment. The background to the upgrade itself, meaning what Votor changes technically and why that counts for staking rewards, is untouched by this.

Solana Alpenglow: What to take away

Alpenglow has not been cancelled; it is running in testing. The date doing the rounds was never one. As long as SIMD-0326 sits among the waiting features at Anza, nothing is live on mainnet, and the next window for feature activations opens on November 9. The three steps that follow for you:

1. Leave the staked holding alone. Absent another reason, there is no occasion to pull SOL out of delegation now. The epoch boundary of around 38 hours still applies, and a switch only pays off where your validator performs poorly. Provider terms are set out in the staking comparison.
2. Keep a clean record of reward allocations. Staking rewards accrue continuously, independently of the upgrade date, and need a record that still holds up next spring. The tools for it appear in the overview of crypto tax software.
3. Sort out buying route and custody independently of all this. MiCA authorisation, fees and the question of where your coins sit are decisions you take by your investment horizon, not by an upgrade date. The exchange comparison is the way in.

The full timeline of the testnet activation and the v4.4 schedule has been documented by Solana Compass.

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