Solana Alpenglow: Activation Starts September 28, and What Delegators Should Check Now

Solana is not switching on Alpenglow at some secret date: the release schedule maintained by the development shop Anza names September 28, 2026 for feature activation on mainnet. If you hold Solana (SOL), in most cases you need to do nothing at all. If you stake by delegating yourself, you have exactly one job, and the date that matters more for it is not September 28 but September 21.

This article answers the question of when Solana's Alpenglow activation happens, at the primary source, in three steps: what the schedule actually says, what "activation" means technically, and how far the network stands on the day of this measurement from the state the schedule assumes. The figures on how far the new version has spread were collected by us on mainnet on September 1, 2026.

When Solana Alpenglow will be activated: the Agave 4.3 schedule names September 28

The answer sits in a document almost nobody reads: the release schedule for Agave v4.3 in the validator client's wiki. Agave is the software maintained by Anza with which the majority of Solana validators run their nodes. The schedule lists every milestone of the release with a target date and a delivery date, and the final row for mainnet-beta carries the entry Begin feature activation with the target date 2026-09-28.

The branch for v4.3 was created on August 11, 2026, testnet received the recommendation on August 17, and feature activation on testnet and devnet was completed on August 19 and August 24 respectively, according to the delivery dates. That is an important detail when judging how much weight the document carries: the table is maintained, the completed rows carry real delivery dates, and some of those fall before the target dates. An abandoned document looks different.

For German-language readers this is new information. The figures in circulation say "third quarter of 2026" or "October 2026", and neither is wrong. Both simply describe something other than September 28, and that distinction is the core of this article.

Why the word Alpenglow does not appear in the schedule at all

Search the schedule for the word Alpenglow and you find nothing. It speaks only of v4.3 and of feature activation. A second official document makes the connection: in the release overview for Agave 4.2, the Solana Foundation writes that Alpenglow will not yet be activated in 4.2 and that activation is to be expected for Agave 4.3, "targeted for October 2026". The same page lists Alpenglow in its metrics bar with "150ms Alpenglow target finality, activating in 4.3".

Only both documents together produce the statement: v4.3 contains Alpenglow, and feature activation for v4.3 begins on September 28. Read only one of the two and you find either a date without a subject or a subject without a date. That also explains why no specific day has appeared in German coverage so far.

What Alpenglow actually is and what it changes for your SOL staking, we covered at length in a separate article: Solana Alpenglow and your SOL staking. This piece starts one level below that and answers the question of timing from the document itself.

The five dates leading up to feature activation, one by one

The schedule stages the path to mainnet across five markers. That staging is the real find, because it makes visible that a slow ramp precedes the cut-off date:

• September 4: Anza marks a mainnet-beta upgrade candidate on the v4.3 branch. From here there is a version intended for production use.
• September 8: a call for volunteers to move ten percent of the stake onto v4.3. On the same day the procedure for restarts and for moving up and down between versions begins on testnet.
• September 14: the same call for 25 percent of the stake.
• September 21: general recommendation to switch to v4.3. This is the point at which an operator can make the change without time pressure.
• September 28: start of feature activation on mainnet-beta.

Exactly one week lies between the general recommendation and activation. That week is no formality. It is a buffer, meant to ensure that the great majority of the stake is already running the new implementation before the first switch is thrown at all. The order of events in the schedule is therefore itself the answer to the question of how much time a validator has.

Feature gate and epoch boundary: why September 28 is a starting gun and not a switching day

A feature gate is a switch in the protocol that only makes an already shipped change take effect once enough stake supports it. The software therefore sits on the nodes long beforehand and does nothing until the gate is thrown. That is precisely why both official documents use the word begin: activation starts on September 28, and it is not finished that day.

What an epoch is and why it sets the rhythm

On Solana, an epoch is a fixed stretch of 432,000 slots, at whose boundary the network settles its bookkeeping: delegations take effect, rewards are accounted for, switches are armed. An epoch therefore does not last a fixed number of hours; it lasts as long as 432,000 slots happen to take.

We measured this ourselves on September 1, 2026 at 12:49 UTC. The network stood in epoch 1026 at slot 195,474 of 432,000. From the gap between two block timestamps across 198,000 slots, an average slot time of 0.318 seconds follows, and from that an epoch duration of roughly 38 hours. That puts around 16 further epoch boundaries between the end of the current epoch and September 28.

From this follows the resolution of the apparent contradiction between "September 28" and "October 2026": September 28 is the start of activation, the effect in live operation sets in over the following epoch boundaries, and those land in October. The starting gun and the effect are two different moments, not two competing dates.

Our own mainnet measurement: how much stake runs on Agave 4.3 today

A schedule says what is supposed to happen. Whether the network is following it can be checked. So on September 1, 2026 at 12:49 UTC we queried two lists through Solana's public network endpoint and merged them: the list of all nodes with their reported version, and the list of all vote accounts with their active stake. That makes it possible to calculate the share of stake per client version rather than merely counting nodes.

The basis: 679 active validators holding roughly 438.1 million SOL in active stake between them, plus 15 delinquent validators carrying just 0.01 percent of the stake. The distribution by version branch:

• Agave 4.2: 86.61 percent of the stake, 608 validators
• Frankendancer, older numbering: 8.49 percent, 40 validators
• Frankendancer, calendar numbering: 3.88 percent, 15 validators
• Agave 4.3 (alpha and beta): 0.39 percent, 6 validators
• Agave 4.4 (alpha): 0.08 percent, 6 validators
• remaining entries and nodes without a version string: 0.56 percent, 4 validators

The finding in one sentence: a week before the schedule's first marker, 0.39 percent of the active stake runs on a 4.3 build, and those are exclusively alpha and beta versions. The schedule wants to see ten percent on September 8 and 25 percent on September 14. That is neither a contradiction nor an alarm signal, because the upgrade candidate for mainnet is only marked on September 4. It does show how much still has to happen between today and the target date, and it hands you a figure against which you can check the progress yourself.

What the version numbers reveal: Agave, Frankendancer and client diversity

Working through the measurement, it stands out that around twelve percent of the stake reports version numbers that do not follow the Agave scheme at all. That is not an error but the fingerprint of a second validator client. Frankendancer is the production-ready intermediate stage of the second Solana client, Firedancer; according to its documentation it builds the Agave validator as a dependency and nonetheless keeps its own numbering. In the older form, the final group of digits encodes the underlying Agave version; in the newer form there is a calendar numbering, as the Firedancer documentation gives in the example v26.08.2 for the current Frankendancer release.

Convert the older form back and a revealing picture emerges: all 40 nodes in this group run on a 4.2 core. Not a single node with a Frankendancer version number reports a 4.3 core. The six validators on 4.3 are all Agave nodes on alpha or beta versions.

For you as a holder, one thing above all follows from this: the question of whether your validator is already running the new version cannot be answered from the provider's name. What counts is the reported version alone. And you can look that up without installing anything.

Do you have to do anything as a SOL delegator? The answer depends on your custody

Delegator, validator and commission in one sentence each

A validator is a machine that verifies blocks, votes on them and receives rewards for doing so. You are a delegator when you assign your SOL to a validator without running a node yourself; your coins never leave your wallet and are not transferred to the validator. The commission is the share of the rewards the validator keeps.

Three cases follow from that, and only one of them calls for attention:

• SOL on an exchange, staked or not: nothing changes for you. The trading venue runs the technology and carries the risk of the switch. Which providers offer staking at all and on what terms is set out in our overview of the best staking platforms.
• SOL in self-custody but not staked: again nothing to do. A protocol upgrade demands no wallet action from you, no swap and no approval.
• SOL in self-custody and delegated to a validator: here a look is worth it. Not because your coins would be at risk, but because a validator who sleeps through the switch earns no rewards for the duration of its outage and therefore costs you yield.

An important qualification: your SOL remain your SOL in every one of these cases. A feature gate changes the behaviour of the network, not the balance in your account. With this upgrade there is nothing to claim, nothing to swap and no deadline after which something lapses.

How to tell in five minutes which client version your validator runs

The route we used for the measurement above is open to everyone. You need the address of your vote account, which any wallet with a staking function will show you:

1. Look up your delegation. Open the staking section in your wallet and note the name or address of the validator you have delegated to.
2. Check the version. Public validator overviews list the reported software version for every node. If a 4.2 is still shown there from mid-September onwards, while the general recommendation has long since moved to 4.3, that is your signal.
3. Check the status. The same overviews show whether a validator is listed as delinquent and how high its skip rate in block production is. Those two values say more about the quality of your delegation than any yield figure.
4. Redelegate if needed. You can move your delegation to a different validator at any time. The change takes effect at the next epoch boundary, so within roughly 38 hours at the rhythm we measured.

A sensible moment for this check is September 22 or 23, immediately after the general recommendation. Before that, a 4.2 is not an omission but the recommended state.

Why September 21 is the more important date for you

September 28 is the day that gets written about. The day on which you can actually tell something is September 21. Until then a validator on the old version is operating by the book, because the recommendation explicitly says otherwise. From September 21 that reverses: an operator who does not switch then has left unused a week that the schedule deliberately provides as a buffer.

That reversal is the real reason the date is worth remembering: a technical entry turns into a quality signal about your validator. An operator who follows the staging and volunteers early shows more about their diligence than any self-description does.

Note the second marker on September 8 as well: the call is for volunteers to carry ten percent of the stake. A validator taking part is deliberately running a fresh version in production. That is a sign of commitment to the community and at the same time a somewhat higher risk. The two belong together, and neither on its own is a mistake.

What Alpenglow changes technically: Votor, 150 milliseconds and the 40 percent threshold

Alpenglow replaces the previous voting mechanism, Tower BFT, with Votor, a two-stage procedure. If a block gathers votes from 80 percent of the stake on the fast path, it counts as final immediately; if that majority does not materialise, two rounds of 60 percent each decide. So says the associated proposal SIMD-0326, which has been through the validators' voting process and has since sat in the official register of Solana Improvement Documents. The Solana Foundation names roughly 150 milliseconds as the target for finality. Finality here is the moment from which a transaction can no longer be reversed, and it is something other than the confirmation time a wallet displays to you.

The second change concerns the network's resilience. Under the previous mechanism, finality stalls when more than a third of the stake drops out. Alpenglow raises that limit to 40 percent. How close to practice that is became clear on the day the schedule was published: an outage at the data centre provider Teraswitch took 28.83 percent of staked SOL off the network, according to Solana Compass, which is 4.5 percentage points below the threshold in force today.

An important qualification for the SOL price: a consensus upgrade is an infrastructure matter. There is no distribution, no new coins and no claim you could assert. Deriving a price statement from a date for feature activation confuses two different levels.

Validator admission ticket: what the Alpenglow upgrade changes about your validator's costs

One part of the rebuild is practically never mentioned in German coverage, even though it affects the economics of every node. Today a validator has to write its vote for every slot onto the blockchain and pays around one SOL a day in fees for that, according to SIMD-0326. Under Alpenglow, votes no longer travel over the chain, and that cost block would fall away entirely.

To preserve the economic balance, the proposal introduces the validator admission ticket, or VAT. It is a fee debited from a validator's account before admission to an epoch; anyone who cannot cover it drops out of the active set. The level is set at 80 percent of today's vote fees, so around 0.8 SOL a day or 1.6 SOL per epoch to begin with. Unlike today, this money is burned in full, which dampens inflation.

The proposal also caps the active set at the 2,000 validators with the highest stake, because that simplifies the implementation considerably. On today's numbers that limit is far away: our measurement found 679 validators active. For you as a delegator, that means your validator will foreseeably not drop out under this rule, provided it covers the ticket fee.

What the Alpenglow upgrade speeds up and what stays the same

Because blockchain upgrades regularly raise expectations the update does not serve at all, here is the sober separation. The transaction time a wallet shows you as confirmation is already short today; what shortens is the time until irreversibility. The targeted acceleration to roughly 150 milliseconds therefore concerns the point from which a payment truly can no longer be clawed back.

Speed like that becomes noticeable above all where amounts are moved on in quick succession: in trading applications, in payments at the checkout, and in bridges between chains that wait for final confirmation before releasing assets. For you as a holder transferring something once a month, the difference stays invisible in daily use.

What explicitly stays the same: the number of your coins, your addresses, your recovery words and the way you store crypto. A consensus mechanism is the rule by which the network agrees on an ordering, and that rule leaves balances untouched. In the competition between the large layer 1 blockchains the rebuild still matters, because it affects the entire ecosystem: every application running on Solana inherits the shorter finality without having to change anything itself.

What a missed upgrade means for your staking yield

A validator earns rewards by taking part in voting on the chain and by producing blocks itself. If it goes down it earns nothing, and because your reward depends on its reward, you earn nothing for that period either. Nothing is deducted from you in the process: your holdings stay untouched, you simply forgo the return for the downtime.

How much weight that carries depends on the duration. A validator that needs half an epoch after a switch to rejoin the network costs you roughly a day of return. At the orders of magnitude common today, that is an amount that disappears after the decimal point. A validator that stays delinquent for weeks, by contrast, is a genuine problem, and one entirely independent of any upgrade.

On top of that comes a second development, running over the same period and having nothing to do with Alpenglow: Solana's emission curve was decided on separately, which will lower staking yields in the coming years. We broke down what lies behind that in Solana staking yields are falling. For your assessment that means yields are shifting from several directions at once, and the share a single consensus upgrade has in that is the smallest of them.

Provisional means provisional: how firm the date is and how you would spot a delay

The schedule writes its own caveat into its first line: this is a provisional timetable, all dates may change, and before every upgrade you should wait for the announcements in Discord. That is not boilerplate but standard practice for a network that is upgraded without a central authority. September 28 is a target date, not a deadline with legal consequences.

There is, though, a good indication of how seriously the table should be taken: the rows already completed carry delivery dates, and two of them fall before their target date. That speaks for a plan that is being kept, and against a wish list.

You can spot a delay at exactly two places, without depending on news coverage. First, in the schedule itself: if the row for the mainnet candidate on September 4 stays without a delivery date, the whole chain behind it will very probably shift. Second, in the spread: if the stake share on 4.3 is still around our current measurement of 0.39 percent on September 15 instead of the 25 percent being aimed for, September 28 is in practice no longer achievable. Both checks cost you two minutes and carry more weight than any forecast.

Checking the Solana Alpenglow date: what to take away

The question of timing can be answered, and the answer is unspectacular: a target date of September 28, an effect that stretches over the following epoch boundaries into October, and for the vast majority of holders no need to act at all. Three steps with which you can close the matter for yourself:

1. Establish in a minute whether this concerns you at all. If your SOL sits with a trading venue or unstaked in your own wallet, you are done. If you delegate yourself, note September 22 for the version check. If you are comparing where staking is possible and on what terms anyway, our overview of the best staking platforms helps with sorting that out.
2. Judge your validator on hard characteristics rather than on advertised yield. Reported version, status and skip rate tell you more than any percentage on a landing page. If you would rather hand the whole subject over, the providers in our comparison of the best crypto exchanges offer the more convenient and correspondingly less independent option.
3. Keep documenting your staking income exactly as before. A consensus upgrade changes nothing about the tax treatment of rewards; inflows still have to be valued at the moment they arrive. If you have no clean record for that yet, our comparison of crypto tax software and portfolio trackers is the right place to start.

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