Alpenglow: app and indexer readiness checklist

Alpenglow is Solana's next consensus protocol. Votor, the voting layer, ships in Agave 4.3. Rotor, the later Turbine replacement, still has no date.

The SVM, fees, account model, and transaction format stay put. What changes is how a block is agreed on, streamed, and marked final.

If you only sign and send, you can wait. If you stream Geyser or gRPC, merge more than one provider, count transactions in a block, or treat confirmed as a weaker commitment than finalized, work through this list before the cluster flips.

The consensus primer is Alpenglow: Solana's new consensus. This piece is the migration work. Official source of truth: solana.com/upgrades/alpenglow, updated September 2026.

What you actually have to change

Sending a transaction does not need a new SDK. Reading the chain through a stream does. The Foundation page splits the work by job. Use that split, then the sections below for the wiring.

JSON-RPC and WebSocket methods do not expose banks. If that is your only surface, you do not need a bank_id SDK bump. You still need the genesis-cert check if any code path cares that Alpenglow is on.

Ask the cluster, not the calendar

There is no fixed activation slot. Devnet, testnet, and mainnet each flip on their own. Agave 4.3 adds getAgGenesisCert. It takes no parameters and reads the finalized bank.

null means the node speaks 4.3 and the cluster is still on TowerBFT. A certificate object means Alpenglow has started, and block.slot is the first Alpenglow slot. An older node answers Method not found (-32601). Treat that as "upgrade the RPC", not as "still TowerBFT".

As of 15 Sep 2026, both api.mainnet-beta.solana.com and api.devnet.solana.com return null. Gate Alpenglow-specific behavior on this call, not on a date or a version string.

curl https://api.mainnet-beta.solana.com -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'

The Solana CLI wraps the same call from 4.3: solana alpenglow-genesis-info. Before the migration it prints still running tower. After, it prints the feature epoch, genesis slot, block id, and how many validators signed. Both ends have to be on 4.3. Check with solana --version and solana cluster-version.

@solana/kit 8.3.0 (9 Sep 2026) exposes the method on the default RPC API. Other SDKs still want a raw JSON-RPC request.

import { createSolanaRpc } from "@solana/kit"

const rpc = createSolanaRpc("https://api.mainnet-beta.solana.com")
const cert = await rpc.getAgGenesisCert().send()

if (cert === null) {
  // Cluster still on TowerBFT.
} else {
  console.log(`Alpenglow active since slot ${cert.block.slot}`)
}

Streamers: one slot can hold more than one bank

A slot is a window of time. A block is what fills it. A bank is the validator's in-progress state for one candidate block. Production code has treated those three words as synonyms for a long time. Votor makes the difference show up in your stream.

Agave 4.3 tags every Geyser event with bank_id so you can tell which candidate a transaction, account update, or block-meta message belongs to. Yellowstone forwards the field. Fast leader handoff in Agave 4.4 is what makes multiple banks per slot routine. 4.3 is the window to adopt the field while the edge case is still rare.

You do not pick the winner. Votor does. By the time Confirmed reaches the stream, the race is over. Your job is to have kept the losing candidate separate:

1. Regenerate protobuf stubs from the 4.3-transition geyser.proto. bank_id is a plain uint64 on transaction, entry, block-meta, and block updates. It is optional on slot and account messages, so those arrive as Option<u64>.
2. Key buffers on (slot, bank_id), not on slot alone.
3. Promote the first bank to reach Confirmed. Drop the rest for that slot.
4. Seal a bank only when the buffer matches executed_transaction_count and entries_count in its block meta and the sysvar account updates you expect have arrived. A status update alone does not mean the bank is complete. If those counts never arrive, you connected mid-block.

If you already subscribe to Yellowstone blocks rather than rebuilding them from individual updates, upgrading the plugin is the whole migration. The provider buffers for you. Watch Yellowstone releases for the first +solana.4.3.x build. As of 15 Sep 2026 none is tagged. Latest is v15.2.1+solana.4.2.2 (10 Sep 2026). Generate from the 4.3-transition branch until that tag lands. The reference state machine is block_reconstruction_v2.rs, also packaged as yellowstone-block-machine.

Ordering depends on the commitment you subscribe at. At confirmed or finalized, Yellowstone reorders and delays block meta if it would arrive early. At processed, Geyser has never promised order: block meta can beat the last transactions of its own block. processed is no less reliable than before. What is new is the reorder at confirmed and finalized.

Multi-provider merge: never join on bank_id

bank_id is a locally assigned atomic counter, the same idea as write_version on account updates. Connection A's bank_id = 7 and connection B's bank_id = 7 are almost certainly two unrelated banks. One real bank can show up as 7 on one stream and 12 on the other.

Keep one buffer per physical connection, keyed on that connection's own (slot, bank_id). Reconcile afterwards on the blockhash from SubscribeUpdateBlockMeta, and only after both sides are sealed. Two unsealed banks both carry an empty blockhash and would compare equal. yellowstone-block-machine handles one Geyser stream. Merging two connections is still yours.

If you cannot wait for block meta, pick one stream as authoritative per slot and use the others for liveness. A fused buffer keyed on (slot, bank_id) across providers fails silently.

Confirmed and finalized collapse after the flip

processed, confirmed, and finalized all still exist under Alpenglow, and they still mean what they mean today. Nothing breaks on activation day.

Under TowerBFT, confirmed is about one slot out and finalized is about 12.8 seconds of lockout. Under Votor a block is final once a finalization certificate exists, roughly 150ms after it was proposed. confirmed and finalized describe the same state. Anza did not redefine confirmed as first-round notarization (60% of stake). That would let a client observe finalized before confirmed for the same transaction.

After the cluster has migrated, point new code at finalized and migrate the rest. confirmed will be deprecated and removed in a later release. Do not switch before activation: on TowerBFT, finalized still means waiting 12.8 seconds. Re-check any timeout, retry, or UX delay tuned around that wait. 150ms is finality time, not slot time. Slot time is a separate cut, 400ms toward 200ms.

Indexers: votes leave the block

Validators send votes to each other and aggregate them into certificates. Votes are no longer transactions, so they no longer appear in blocks. That is an accounting change, not a throughput crash, but every dashboard whose baseline included vote traffic will drop hard.

Pipelines that filter the Vote program, or set Geyser's vote filter, keep working. They have nothing left to filter. Anything that measured which validators voted by parsing Vote program instructions goes quiet. That information now lives in the Alpenglow block footer: notar_reward_cert and skip_reward_cert each carry an aggregate BLS signature plus a bitmap of the validators it covers.

Geyser exposes the footer through notify_block_footer. Opt in with block_footer_notifications_enabled(). BlockFooterV1 carries bank hash, block production time, the producer's user agent, and up to three optional certificates: block_final_cert, plus the two reward certs. A footer without a certificate is normal. block_final_cert carries its own slot and block id. They are the latest certificate the leader held while building, not necessarily this block. A leader cannot know its own block is final yet.

The 4.3 window, as of 15 Sep 2026

Anza's v4.3 wiki is informational. Dates move. Wait for Discord before you upgrade or downgrade a box. The Foundation page still says expected mainnet activation in Q3 2026, on that same schedule.

• v4.3 branch cut 11 Aug 2026. Devnet on 4.3 since 25 Aug.
• Mainnet upgrade candidate tagged 4 Sep. Volunteer 10% of stake asked 8 Sep.
• Volunteer 25% targeted 14 Sep. The wiki has no delivery date yet.
• Recommend general adoption 21 Sep. Resume feature activation 28 Sep.

Test against the Alpenglow community cluster explorer. It goes offline on purpose. Taking it down and bringing it back is how the TowerBFT to Alpenglow switch gets rehearsed.

Validators, in one pass

App teams can skip this if they do not run a vote account. Operators already needed a BLS pubkey. SIMD-0387 activated on mainnet 8 Jul 2026. The Validator Admission Ticket (SIMD-0357) activated 22 Jul 2026. Without a registered BLS pubkey you are already out of the admitted set and not earning inflation. VAT does not turn Alpenglow on. That switch is Agave 4.3.

After both VAT and Alpenglow are on, each admitted vote account is charged 1.6 SOL per epoch, burned. Votes are no longer on-chain transactions. If you run a hot spare next to a primary, only one of them should ever be active. Accidental double block production is the usual source of equivocation, and bank_id now makes it visible to everyone downstream. Registration is solana-keygen bls_pubkey then solana vote-authorize-voter-checked on CLI 4.1.0 or higher. Full steps live on the BLS page, not here.

What stays the same

Programs, fees, ALTs, compute budget, and versioned transactions do not get a new opcode. Pre-confirmation streaming (Geyser processed, Whirligig-style) still sees execution as the bank is built. The difference starts after voting.

Firedancer is a different client calendar. Firedancer for app teams is packing and RPC shape. Alpenglow is how the cluster agrees. Do not mix the two upgrade checklists.

People and links