// Mainnet epoch 1064 · Wednesday 21 October 2026, ~15:00 UTC · verified 2026-10-19
Solana Alpenglow October 2026: what changes for Yellowstone gRPC, Geyser and trading bots.
This is not a 150ms-slot think-piece. Alpenglow is a breaking consensus change on Wednesday 21 October 2026, ~15:00 UTC. Slot time is already 200ms. Finality is expected to compress from ~12.8s (TowerBFT) to ~150ms (Votor expectation, not a constant). The work for operators is bank_id, reconstruction, reconnect, and not flipping to finalized early. Subglow is Alpenglow-ready on Yellowstone gRPC.
Confirmed activation facts
Numbers last checked 2026-10-19against the Foundation upgrade page, Triton's stack note, and the yellowstone-grpc changelog. If a page still says "Alpenglow is unscheduled" or "slot time stays 400ms", it is stale — including our own April 2026 draft of this URL, which this page replaces.
| Cluster / epoch | mainnet-beta · epoch 1064 |
|---|---|
| When | Wednesday 21 October 2026, ~15:00 UTC (Anza quoted ~14:50 UTC) |
| Alpenglow starts at slot | 459,653,000 |
| Feature gate | A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS |
| TowerBFT after the gate | 5,000 slots (~18 min) |
| Breaking / indexing | Yes / yes |
| Agave | 4.3.0 minimum, 4.3.2 recommended (Alpenglow slot timing for transaction buffering) |
| Supported at the switch | Agave, Jito-Solana, Harmonic Salsa |
| Not supported at the switch | Firedancer, Frankendancer. Firedancer v26.10.2 can run Alpenglow in operation, but is not supported for the TowerBFT → Alpenglow switch itself. |
| Slot time | 400ms → 200ms (already done; not an Alpenglow deliverable) |
| Finality | ~12.8s (TowerBFT) → ~150ms (Votor expectation, not a constant) |
| Yellowstone versions | proto 14.0.1 · geyser 16.1.2 · client 15.0.0 · @triton-one/yellowstone-grpc v9.0.0 |
| Detect Alpenglow | getAgGenesisCert / solana alpenglow-genesis-info |
Sources: Solana Foundation — Alpenglow upgrade · Triton — Alpenglow and your Triton stack · yellowstone-grpc CHANGELOG.
What actually changes
Alpenglow replaces TowerBFT. Votor ships in Agave 4.3.0; Rotor (the Turbine replacement) is unscheduled. Fast finalization is ≥80% stake in round one; the slow path uses 60% thresholds in round two. Five vote types. Fault tolerance is 20% adversarial + 20% offline stake. There is no new "notarized" commitment level.
After activation, confirmed and finalized converge and arrive back-to-back. Do not switch production bots to finalized before the feature gate. confirmed will be deprecated and removed later — that is a second migration, not this one. Anza did not redefine confirmed as 60% notarization.
Vote transactions leave the block. TPS and tx counts drop sharply (Triton's worked example: 1,200 → 400 per block). Vote filters become no-ops. Participation data moves to footer certificates when you opt in: notar_reward_cert, skip_reward_cert, block_final_cert. Ticks are gone (previously 64 per slot). Use block meta and the footer for completeness; use a local slot clock for leader routing. Clock.unix_timestamp is now leader-set within [parent, parent + 2× elapsed slot duration] (SIMD PR #363).
JSON-RPC and WebSocket are unchanged. getBlock has no footers yet. During the switch, two vote-only slots are deleted — treat processed data in that window as temporary.
bank_id: the actual streaming break
A slot can have more than one candidate bank. In 4.3 that comes from equivocation; Agave 4.4 (planned November) adds fast leader handoff on under 1% of slots. If your consumer still does HashMap<u64, Block> keyed only on slot, the first dual-bank slot will merge two histories and you will not notice until fills go wrong.
Buffer per (slot, bank_id). Keep the bank that reaches Confirmed; drop the rest. Seal a bank only when it matches executed_transaction_count and entries_count in block meta. At confirmed/finalized, Yellowstone emits a sealed bank in fixed order: data → block meta → slot status. At processed there is no ordering, and abandoned banks can appear via UpdateParent.
bank_id is node-local. Do not join two providers on bank_id. Reconcile on blockhash, and only after sealing — unsealed banks both have an empty blockhash. bank_id is optional on slot/account updates for is_startup, FIRST_SHRED_RECEIVED, COMPLETED, and a plain uint64 elsewhere. Deshred transactions have none.
Yellowstone and Geyser versions that actually work
A proxy or client still on proto 6 will compile, connect, and silently strip bank_id, block_footer and entry_update_parent because prost drops unknown fields on decode/re-encode. That is the failure mode that looks like "Alpenglow is fine" until reconstruction is wrong.
Minimum that understands Alpenglow on the wire: proto 14.0.1, geyser 16.1.0+ (current 16.1.2), rust client 15.0.0, TypeScript @triton-one/yellowstone-grpc v9.0.0. subscribe no longer reconnects. Use subscribe_with_reconnect, which is bank-aware, requires processed commitment, forbids a startup snapshot, and emits ReconnectEvent::DiscardBanks. New filters: block_footer, include_certificates, include_update_parent. Reference implementations: yellowstone-block-machine, block_reconstruction_v2.rs.
- update_account
- notify_transaction
- notify_entry
- notify_block_metadata
- update_account_from_snapshot / update_account_for_bank
- notify_transaction_for_bank
- notify_entry_for_bank
- notify_block_metadata_for_bank
- update_bank_status (CreatedBank / Processed / Confirmed / Rooted)
- notify_entry_update_parent
- notify_deshred_update_parent
- notify_block_footer (opt-in: block_footer_notifications_enabled)
// Subglow readiness
Subglow is Alpenglow-ready for Yellowstone gRPC trading workloads.
Subglow's Yellowstone gateway speaks proto 14.0.1 — the Alpenglow wire format — and forwards every message whole. bank_id, block footers and update-parent events reach standard clients unchanged, nothing in the path merges banks by slot, and client 15's subscribe_with_reconnect gets every field it needs. JSON-RPC is unchanged. Bots that still key state on slot alone are the ones that have to change — not the subscribe call.
Alpenglow fields reach your client
bank_id, block_footer (oneof 12) and entry_update_parent (oneof 13) arrive exactly as the validator emitted them. A gateway that still decodes with an older proto strips them silently — and client 15's subscribe_with_reconnect then stops with "cannot track an account update without bank_id". Subglow's gateway runs proto 14.0.1 and ships with wire tests that fail the build if any of these fields would be dropped.
No slot-only merging in the path
Subglow forwards each update with its bank_id and never re-keys by slot, so two candidate banks for one slot are never collapsed into one before they reach you. Your client (or yellowstone-block-machine) buffers per (slot, bank_id), seals a bank when block-meta counts match, and keeps the bank that reaches Confirmed.
subscribe_with_reconnect works through Subglow
Client 15's subscribe() no longer reconnects. subscribe_with_reconnect needs processed commitment, bank_id on every account update and a from_slot on reconnect; Subglow forwards all three unchanged, so your client can emit DiscardBanks for banks invalidated by the outage. SubscribeReplayInfo is forwarded too: call it to see first_available before you rely on a reconnect window. We still don't sell historical replay.
Confirmed and finalized are treated as a burst
After activation they arrive back-to-back. We do not tell you to switch to finalized before epoch 1064, and we do not invent a new 'notarized' commitment level — Anza did not add one.
Vote filters become no-ops, TPS counts drop
Vote transactions leave the block. Filters that matched votes stop matching; block tx counts fall sharply (Triton example: 1,200 → 400). Participation data moves to footer certificates when you opt in.
JSON-RPC and WebSocket stay as they are
No bank_id on RPC. getBlock has no footers yet. If you only call sendTransaction and account reads, Alpenglow is a consensus change, not an API change.
Versions: gateway on proto 14.0.1; works with rust client 15.0.0 and @triton-one/yellowstone-grpc v9.0.0. Call GetVersion with your key to see the upstream plugin and proto versions yourself. What we will not fake: post-activation latency and confirmed→finalized timings. Those land in What Actually Changed for Yellowstone gRPC After Solana Alpenglow, written from our own logs after epoch 1064, covering confirmed → finalized wall-clock delta, observed bank_id multiplicity per slot, reconnect / DiscardBanks behaviour, vote-tx disappearance in block meta, any compatibility issues we hit.
Production-readiness checks
Four tests Subglow runs on the Yellowstone path, and that any trading bot should run against testnet or an Alpenglow-enabled environment before epoch 1064. If you fail one of these, you are not ready — regardless of which provider you pay.
Bank-aware event handling
Pass: Every account, transaction, entry and block-meta update is keyed on (slot, bank_id). FIRST_SHRED_RECEIVED and COMPLETED are allowed to omit bank_id. You never merge two banks of the same slot.
Fail: A HashMap<u64, …> keyed only on slot. That silently corrupts state the first time a slot has two candidate banks.
Block reconstruction
Pass: You seal a bank only when buffered tx + entry counts match block meta, then emit in order: data, block meta, slot status. Abandoned banks are dropped on Confirmed of the winner, or on UpdateParent.
Fail: You emit a 'block' as soon as the slot number ticks, or you reconcile two unsealed banks by bank_id across providers (bank_id is node-local; unsealed banks both have an empty blockhash).
Reconnect behaviour
Pass: You call subscribe_with_reconnect (or equivalent), require processed commitment, skip the startup snapshot, handle DiscardBanks, and deduplicate by signature before acting. A read-idle timeout still detects silent stalls.
Fail: You still call subscribe() and expect the client to reconnect, or you resume at the live head and silently skip the outage window.
Confirmed / finalized streams
Pass: You can consume a confirmed stream through the switch without flipping to finalized first. After activation you treat confirmed and finalized as a near-simultaneous burst, not as two independent clocks. Processed remains unordered and can include abandoned banks.
Fail: You switch the production bot to finalized 'to be safe' before epoch 1064, or you assume confirmed still means a 32-deep TowerBFT vote stack.
What trading bots must change — and what they must not
- Any in-memory buffer, dedupe set or 'have we seen this slot' flag keyed only on slot — key on (slot, bank_id) or on sealed blockhash.
- Reconnect that assumed subscribe() retries — use subscribe_with_reconnect and handle DiscardBanks.
- Logic that counted vote transactions, ticks-per-slot (was 64), or used vote filters as a heartbeat.
- Code that treated confirmed and finalized as seconds apart and used that gap as a staging window.
- Yellowstone filter syntax for accounts, transactions, blocks and slots.
- JSON-RPC methods, WebSocket subscriptions, sendTransaction, Jito bundles.
- Commitment enum: there is no new notarized level. confirmed stays until it is later deprecated.
- Client libraries, as long as they speak proto 14.0.1 / client 15.0.0 / TS v9.0.0.
The April version of this page said "zero code changes if you use Yellowstone." That was wrong. The subscribe filters stay. The slot-keyed buffer, the reconnect call, and anything that counted votes or ticks do not.
Frequently asked questions
When does Solana Alpenglow activate on mainnet?
Epoch 1064, Wednesday 21 October 2026 around 15:00 UTC (Anza quoted ~14:50 UTC). TowerBFT runs about 5,000 more slots (~18 minutes). Alpenglow consensus begins at slot 459,653,000. Feature gate A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS. Devnet activated epoch 1167 on 25 September 2026; testnet on 24 September. This is a breaking change and indexing changes are required.
Does Alpenglow mean 150ms slot time?
No. Slot time is already 200ms (cut from 400ms in four stages, 200ms from epoch 1053). Alpenglow's ~150ms figure is expected finality under Votor, down from ~12.8s under TowerBFT. It is an expectation, not a constant. Older write-ups that say 'slot time stays 400ms' or '250ms slots' are wrong.
Do I need to change my Yellowstone gRPC subscribe call?
The filter language is the same. What you must change is version and reconnect: proto 14.0.1, geyser 16.1.x, rust client 15.0.0, @triton-one/yellowstone-grpc v9.0.0. subscribe() no longer reconnects. Use subscribe_with_reconnect, processed commitment, no startup snapshot, and handle DiscardBanks. If your bot buffers by slot instead of (slot, bank_id), that is a logic change, not a subscribe-call change.
What is bank_id and is it globally unique?
bank_id identifies a candidate bank on a single node. A slot can have more than one bank (equivocation in 4.3; fast leader handoff in Agave 4.4, planned November, <1% of slots). bank_id is node-local — do not join streams from two providers on bank_id. Reconcile on blockhash, and only after the bank is sealed; unsealed banks both carry an empty blockhash.
Should I switch my bot from confirmed to finalized for Alpenglow?
Not before activation. After Votor, confirmed and finalized converge and arrive back-to-back. Switching to finalized early does not buy safety and can hide bugs that only show on processed/confirmed. confirmed will be deprecated and removed later; that is a later migration, not a 21 October one. Anza did not redefine confirmed as 60% notarization.
Is Subglow Alpenglow-ready?
Yes. Subglow's Yellowstone gRPC is Alpenglow-ready for trading workloads: the gateway runs proto 14.0.1 and forwards bank_id, block_footer and entry_update_parent unchanged, so reconstruction keyed on (slot, bank_id) and client 15's subscribe_with_reconnect (with DiscardBanks) work through it, and we do not tell you to flip to finalized before epoch 1064. Call GetVersion with your key to see the upstream plugin and proto versions yourself. JSON-RPC is unchanged. We do not offer historical replay — if a gap is permanent data loss, use Helius LaserStream or Triton Fumarole. Measured confirmed→finalized timings will be published after activation from our own logs, not before.
Will vote transactions still show up in Yellowstone?
No. Votes leave the block, so TPS and tx counts drop sharply. Vote filters become no-ops. Validator participation moves to footer certificates (notar_reward_cert, skip_reward_cert, block_final_cert) when the block_footer filter sets include_certificates. Ticks are gone too — previously 64 per slot; use block meta plus the footer for completeness.
How do I detect that a node is on Alpenglow?
getAgGenesisCert returns null on TowerBFT and -32601 on pre-4.3 nodes. CLI: solana alpenglow-genesis-info. @solana/kit 8.3.0+ exposes rpc.getAgGenesisCert(). During the switch, two vote-only slots are deleted — treat processed data in that window as temporary.
Continue reading
Reconnect benchmark
What a dropped stream actually costs. Naive reconnect discards the outage window; resume needs signature dedupe.
Yellowstone filters
Account, transaction, slot, block — and after Alpenglow, block_footer plus include_update_parent.
Geyser plugin guide
How Geyser callbacks map onto the bank-aware replacements in Agave 4.3.
Provider matrix
Sourced comparison. We still do not offer replay; Helius and Triton Fumarole win that axis.
gRPC docs
grpc.subglow.io:443, x-api-key, Yellowstone clients in every major language.
Pricing
Flat-rate plans. Alpenglow does not change the bill.
Epoch 1064 is Wednesday 21 October 2026.
Subglow is Alpenglow-ready.
Bank-aware Yellowstone gRPC. Pre-parsed JSON. Same API key as JSON-RPC. Run the four readiness checks against your bot, then point it at grpc.subglow.io.
Path /alpenglow-solana-grpc · facts verified 2026-10-19.