TL;DR

💡
If you stream, index, or measure the chain, action is REQUIRED!
  • Solana is switching its consensus from TowerBFT to Alpenglow while the chain keeps running; this should take 5,000 slots (about 17 minutes)
  • The switch will happen on Wednesday, October 21, ~14:50 UTC
  • The only disruption to you is a 2 slot gap (roughly 400 ms) where user transactions don’t land
  • After the 400ms blip they land again, and blocks finalize in ~150 ms. Your transactions that reached the confirmed commitment BEFORE the 2 slot gap remain as is without any effect.
  • Harmonic block packing and preconfs will NOT BE AVAILABLE for ~10 mins during the switch. The exact time span is yet to be announced by the Harmonic team
  • JitoBAM block packing and preconfs WILL NOT BE AVAILABLE as well. Jito has not yet announced the exact time span for the unavailability.
  • This post covers getting through the switch: what happens, how to tell it's happening, and what to do if you send transactions, trade, read data or stream blocks
  • To see the impact on your Triton account, and learn what else changes once Alpenglow is live, read Alpenglow and your Triton stack

How the migration happens

It's five steps. Anza has announced the epoch as 1064 which starts on Wednesday, October 21, ~14:50 UTC, after that, the cluster runs them on its own.

Step

When

What happens

What you notice

1. Activation

Start of epoch 1064 (see the time above)

The migration switch turns on and a 5,000-slot countdown starts

Nothing

2. Countdown

Next 5,000 slots (~17 min at 200 ms slots)

The chain runs exactly as it does today

Nothing. RPC, Transactions, Shreds and Geyser / gRPC notifications all continue as normal

3. Preconfs turn off

Time decided by Jito and Harmonic

Validators build blocks locally to ensure a seamless transition

You stop receiving data for preconf streams and get disconnected

4. User transactions off

Slot 5,000 after activation in step 1

Blocks carry only validator votes. Validators wait until 82% of stake has voted for a block N, with those votes landing in block N+1

Your transactions don't land. This will last for 2 slots (400ms)

5. Switch

As soon as that 82% is reached

Validators switch to Alpenglow, and user transactions are turned back on

Transactions land again. Blocks finalize in ~150 ms

How long am I affected? If you use preconfs then you’ll be affected by step 3 for as long as the Jito & Harmonic teams keep them turned off. Otherwise, only during step 4, which is 2 slots, so roughly 400 ms. Steps 1 and 2 look exactly like any other day on Solana.

Is my money safe? Yes. Anything that reached confirmed before step 4 is kept, and the blocks made during step 4 do not contain any user transactions. There's no going back to the old consensus afterwards.

If you want the deep version, it's all in SIMD-0384, SIMD-0326, Alpenglow Consensus, and Anza's Alpenglow page, 

How to tell it's happening

Don't go by dates or tweets. Ask your RPC node. One call tells you whether the switch is done:

curl https://<your-triton-endpoint> -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'

You get back

It means

"result": null

Not migrated yet. Old consensus still running

"result": { ... }

Done. Alpenglow is live. block.slot is where it started

Method not found (-32601)

The node is too old to know. This is not the same as "not yet"

In TypeScript, @solana/kit 8.3.0+ has it as rpc.getAgGenesisCert(). From the CLI, run solana alpenglow-genesis-info. For the heads-up before it starts, watch Anza on X, which posts the countdown.

Put this check in your code and let it flip behaviour automatically. Don't hard-code a date.

What to do during the migration

Find the line that describes you. Two things to remember: during the 17-minute countdown nothing changes, and step 4 is a 1–2 slot gap where user transactions don't land. Only step 4 will affect the majority.

If you subscribe to preconfs

  • Harmonic Preconfs will NOT BE AVAILABLE for ~10 mins during the switch to Alpenglow. The exact time span is yet to be announced. The Harmonic team will shut down the Harmonic block engines to ensure that validators build fallback blocks and that the Alpenglow transition is seamless.
  • JitoBAM Preconfs WILL NOT BE AVAILABLE. Jito has not yet announced the exact duration of the unavailability.
  • You will be disconnected only from the preconf streams. You will not be billed for preconfs while these are unavailable.

If you send transactions (wallets, apps, bots)

  • During the countdown, send as usual. Nothing about sending or confirming changes.
  • A transaction sent during step 4 won't land. It isn't rejected for being bad; blocks just aren't taking user transactions for those 1–2 slots. Your normal retry logic will get it in right after.
  • Retry with backoff and a fresh blockhash. Hammering the endpoint won't make anything land sooner and will burn your rate limit.
  • Fetch fresh blockhashes at confirmed or finalized, not processed. The vote-only blocks from step 4 are dropped at the switch, so a blockhash taken from them won't be valid.
  • Sent something just before step 4? If it reached confirmed, it's safe.
  • Don't switch your code to finalized yet. Until getAgGenesisCert returns a certificate, finalized still means a 12.8-second wait.

If you trade (bots, market makers, liquidators)

  • If you don’t use preconfs, you don't need to stop trading. The countdown is business as usual, and step 4 is about as long as two normal slots.
  • For 1–2 slots, nothing lands. No swaps, liquidations or on-chain oracle price pushes, because all of those are transactions. If your strategy can't tolerate a couple of missed slots, guard around the migration slot (activation slot + 5,000).
  • Watch the first blocks after the switch. Transactions that didn’t land during during step 4 will be retried and land together, so expect a small burst of activity and priority fees.
  • If you use preconfs, you won’t get any data while Jito & Harmonic keep them off.

If you read data (RPC polling, WebSockets)

  • During the countdown, nothing changes. All commitment levels, methods and subscriptions behave as today.
  • Read at confirmed around step 4. At processed you may see 1–2 vote-only blocks that don't carry over into Alpenglow. confirmed only shows you blocks that stick.
  • A slot or two may be missing. Expect a tiny gap in slot numbers after the switch. Don't treat it as lost data.
  • Your alerts won't notice. A 1–2 slot gap is shorter than any sensible "chain stalled" threshold. No timeout changes needed for the switch.

If you stream or index (Shreds, gRPC, Geyser, indexers)

  • Upgrade your gRPC client before activation day. Use the Alpenglow release of Yellowstone gRPC; our guide has the versions.
  • During the countdown, streams are unchanged. Shreds, transactions, accounts and Geyser notifications all arrive exactly as today.
  • Only commit what reaches confirmed. If you ingest at processed, buffer the step-4 blocks and drop any that never confirm. Even if you process those blocks, they'll only have vote transactions and no other transactions so your processor may just yield nothing for them and you don't notice anything.
  • Blocks in step 4 hold only votes. Zero user transactions in those 1–2 blocks is expected, not a bug in your indexer.
  • Transaction counts drop right after the switch and stay down. Under Alpenglow, votes no longer live inside blocks, so per-block counts and TPS fall sharply. Real activity hasn't changed. Adjust those alerts before activation.

Alpenglow is the largest change to Solana's core protocol since launch, but it was designed so that most of the ecosystem notices only one thing: transactions that become final almost instantly. If you only send transactions and read accounts, you’re all good. 

If you stream, index or measure the chain, a few days of work now will make activation day a non-event.

💡
Thanks to Greg Petrossian & the Anza team, and the Jito & Harmonic teams for contributing knowledge & feedback!

Sources