Alpenglow

Nothing about signing, sending, or approving a transaction changes. Wallets and applications keep working exactly as they do today.

Sub-second finality enables new use cases from the teams you already use, like a seemingly instant confirmation at the point of sale, with no change on your side.

Alpenglow does not touch the SVM, transaction formats, fees, or the account model. If your application only sends transactions and reads account state, there is nothing to migrate. The changes are in how blocks are produced, streamed, and finalized.

If you stream data through Geyser or gRPC — indexers, explorers, trading infrastructure, block builders (details):

• If you subscribe to whole blocks through Yellowstone, upgrade to v16.0.0-rc10+solana.4.3.0 and you are done. It buffers for you.
• Otherwise, regenerate your protobuf stubs from that tag's proto, key your buffers on (slot, bank_id) instead of slot, keep the bank that reaches Confirmed, and drop the rest.

If you maintain a Geyser plugin — RPC providers, custom indexers compiled into the validator (details):

• Move off the four legacy callbacks. Agave 4.3 deprecates update_account, notify_transaction, notify_entry, and notify_block_metadata, and slates them for removal in the next major release. The replacements carry a bank_id.
• If you consume entries or deshredded transactions, handle the two new UpdateParent callbacks. They name a bank whose earlier notifications you must discard.
• If you need Alpenglow consensus metadata such as certificates, opt into notify_block_footer.

If you fan in multiple RPC or gRPC providers for redundancy (details):

• Run one buffer per connection. bank_id means nothing outside the stream it arrived on.
• Reconcile across connections on the blockhash and nothing else.
• Audit any existing merge keyed on (slot, bank_id) across streams. It fails silently.

If you read at the confirmed commitment (details):

• Nothing breaks on activation day; all three levels keep working as they do today.
• After Alpenglow is live, point new code at finalized. Do not switch before then: on TowerBFT, finalized still means a 12.8-second wait. Once live, confirmed becomes equivalent to it and is removed in a later release.
• Re-check any timeout, retry, or UX delay tuned around 12.8-second finality.

If you index blocks or report throughput (details):

• Re-baseline transaction counts and TPS dashboards. Vote transactions vanish from blocks, so the number drops sharply without any drop in real activity.
• Replace anything that reads validator participation out of Vote program instructions. It now lives in the block footer's certificates, which reach you through Geyser's footer callback. Yellowstone's gRPC footer message does not forward them yet.

If you read time from the ledger — tick counting in shreds or entries, or Clock.unix_timestamp in a program (details):

• Stop counting ticks. PoH no longer paces block production, so tick entries leave the shred stream. If you used ticks to judge how far into a slot the leader is (for example, to decide when to start routing to the next leader), keep a local slot clock instead: track the slot cadence as seen from your node and correct for your latency to the leader, rather than timing from first-shred arrival, which lags the real slot start.
• If a program or indexer depends on how closely Clock.unix_timestamp tracks real time, re-read how it is now set. The leader sets it between the parent's timestamp and the parent's plus twice the elapsed slot duration, so the room for a dishonest leader to run it ahead grows with skipped slots rather than being a fixed number. Reading it needs no code change.

To find out when a cluster has actually migrated (details):

• Call the new getAgGenesisCert RPC method, or run solana alpenglow-genesis-info. It returns null while the cluster is still on TowerBFT and the Alpenglow genesis certificate once it has migrated.
• Gate feature detection on that call rather than on a date or a version string; devnet, testnet, and mainnet each flip at their own slot.

Test against the Alpenglow community cluster.

Anza's own Alpenglow operator changes are the authoritative checklist. In short:

• Register a BLS pubkey on your vote account if you have not already. The Validator Admission Ticket (SIMD-0357) activated on mainnet July 22, 2026, and operators without a registered BLS pubkey are excluded from the admitted validator set and stop participating in consensus. See BLS Pubkeys and the Validator Admission Ticket.
• Upgrade to Agave 4.3 on Anza's v4.3 release schedule.
• Confirm the cluster's consensus state with solana alpenglow-genesis-info (details).
• Budget for the loss of vote transaction traffic in any capacity planning that assumed it, and expect vote costs to move off the ledger entirely.
• If you run a hot spare alongside your primary, make sure only one of them is ever active. Accidental double block production is the most common source of equivocation on mainnet today.

Breaking Change: One Slot Can Contain More Than One Bank

A slot can carry more than one candidate block. Inside the validator each candidate is a separate bank (why). Starting with Agave 4.3, every event from Geyser, and from gRPC providers built on it such as Yellowstone, carries a bank_id that says which candidate it belongs to. A pipeline keyed on slot alone fuses two competing candidates into one block and never notices.

What to do:

1. Upgrade or regenerate. If you subscribe to whole blocks through Yellowstone, upgrade to v16.0.0-rc10+solana.4.3.0 and you are done; the provider does the buffering. Otherwise regenerate your stubs from that tag's proto so bank_id appears on transaction, account, slot, entry, and block-meta updates.
2. Buffer per (slot, bank_id), never per slot.
3. Seal a bank only when your buffer matches the executed_transaction_count and entries_count in its block meta and the sysvar account updates you expect have arrived. If they never arrive, you connected in the middle of a block.
4. Keep the bank that reaches Confirmed and drop whatever you buffered under other bank_id values for that slot. Votor picks the winner; you never arbitrate.

Good to know:

• At confirmed and finalized, Yellowstone emits each sealed bank in a fixed order: its data, then block meta, then the slot status. At processed there is no ordering guarantee, as before, and you may also see events from a bank the leader later abandons through an UpdateParent marker. That bank never reaches Confirmed. Per-bank_id buffering handles both cases.
• bank_id is optional on slot and account updates and a plain uint64 everywhere else. It exists only on Geyser and gRPC. JSON-RPC and WebSocket are unchanged.
• Yellowstone rc9 (September 17, 2026) added the block footer message and rc10 (September 22) pinned the build to Agave 4.3.0. Both are release candidates; watch the releases page for the final v16.0.0.
• Reference code: Yellowstone's block_reconstruction_v2.rs at the rc10 tag, and yellowstone-block-machine, which packages the same state machine as a library with a runnable example. The doc comments spell out the sealing rules.

Breaking Change: Geyser Callbacks Become Bank-Aware

This section is for anyone who compiles a plugin against the validator's Geyser interface. If you consume Yellowstone or another gRPC provider, the provider's plugin does this work for you, and the streaming section above is what applies.

Agave 4.3 adds bank-aware versions of the data callbacks and deprecates the old ones. The legacy methods still fire in 4.3, but the 4.3.0 changelog slates them for removal in the next major release.

update_slot_status stays. update_bank_status joins it for the statuses that belong to one bank: CreatedBank, Processed, Confirmed, and Rooted.

Two callbacks are new rather than replacements:

• UpdateParent. Under fast leader handoff, a leader can start building on one parent and then switch, emitting an UpdateParent marker that clears the bank it had started. notify_entry_update_parent fires when that happens and names the cleared bank ID. notify_deshred_update_parent does the same for deshredded transactions, ahead of the data set that begins at the marker. Entry notifications can race the callback, so reconcile on the cleared bank ID rather than assuming everything you already hold for that bank is valid. If you buffer per bank_id, this is one buffer drop.
• Block footer. notify_block_footer delivers the complete versioned Alpenglow footer with its slot and bank ID, ordered relative to entry notifications. It is off by default; return true from block_footer_notifications_enabled to receive it. This is where the certificates described under Finality Under Votor come from.

For reference, Yellowstone's own plugin at v16.0.0-rc10+solana.4.3.0 implements the bank-aware callbacks and the footer callback but not the two UpdateParent callbacks. It relies on per-bank_id buffering and on the fact that only the confirmed bank is ever sealed. Its gRPC footer message, SubscribeUpdateBlockFooter, forwards the slot, bank_id, bank hash, producer time, and user agent, but not the certificates. If you need certificates over gRPC today, that still takes a plugin of your own.

Breaking Change: Merging Streams From Multiple Providers

Latency-sensitive consumers often subscribe to several providers and deduplicate locally, because an update can reach provider A first on one slot and provider B first on the next. bank_id does not help with that merge. Each validator assigns its own counter as it creates banks, so the number means something inside one connection and nothing across connections. Connection A's bank_id = 7 and connection B's bank_id = 7 are almost certainly different banks, and one real bank can be 7 on one connection and 12 on another. It also carries no order: two ids from the same stream only tell you whether they differ.

What to do:

1. Keep one buffer per connection, keyed on that connection's own (slot, bank_id), and tag each connection so that mixing them is an error your code catches. Feeding two streams into one buffer runs without complaint and hands back blocks fused from unrelated banks.
2. Reconcile on the blockhash, which arrives in block meta, and only once both sides are sealed. Two unsealed banks both carry an empty blockhash and would compare equal.
3. If you cannot wait for block meta, treat one stream as authoritative per slot and use the others for liveness only. A merged view that stays correct under forks has to wait for the blockhash.

yellowstone-block-machine handles the per-connection half: out-of-order events, forks, dead slots, and commitment ordering for one stream. Reconciling across connections is still yours to write.

Commitment Levels: Confirmed and Finalized Converge

processed, confirmed, and finalized all still exist under Alpenglow and still mean what they mean today. No code change is required on activation day.

In production almost everyone reads at confirmed, which lands in about one slot, and there has never been a confirmed block that did not finalize. The guarantee was weaker than that record: a confirmed block could in principle still be dropped, and ruling that out meant waiting the 12.8 seconds TowerBFT needed to finalize. Under Alpenglow finality arrives in roughly 150ms, so you can listen for finalized directly and take the stronger guarantee at no cost in latency (how). Once Alpenglow is live, 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, and your app will wait way too long for finality.

Pre-confirmation streaming is unaffected. Alpenglow does not touch execution, so anything that watches transactions as a block is being built (Geyser processed notifications, Triton's Whirligig-style streams) sees the same data at the same point in the pipeline. The difference starts after voting.

Breaking Change: Vote Transactions Leave the Block

Alpenglow validators send votes directly to each other and aggregate them into certificates. Votes are no longer transactions, so they no longer appear in blocks. For anything that reads blocks:

• Transaction counts and TPS drop sharply. Vote traffic has been a large share of the transactions in a block. Removing it is an accounting change, not a throughput regression, but every dashboard, benchmark, alert threshold, and historical comparison whose baseline included votes needs re-baselining. Benchmarking tools that have not been updated will report the change as a collapse in network activity.
• Vote filtering becomes a no-op. Pipelines that filter out the Vote program or set Geyser's vote filter keep working; they have nothing left to filter.
• Validator participation needs a new source. Anything that measures which validators voted, or how, by parsing Vote program instructions out of blocks stops seeing data. That information now lives in the certificates in the Alpenglow block footer: notar_reward_cert and skip_reward_cert each carry an aggregate BLS signature plus the bitmap of the validators it covers (details).

Breaking Change: Ticks Leave the Ledger

Today a leader's Proof of History stream emits 64 tick entries per slot, spaced evenly through it, and the tick count in each shred tells anyone watching the stream how far into the slot the leader is. Under Alpenglow, Votor's timeouts and certificates pace block production instead of PoH, so leaders stop emitting ticks. The ledger keeps its slot-level notion of time and loses the sub-slot one.

Who is affected: anyone who read ticks as a finer clock than the slot. The common case is transaction routing. With 200ms slots, a sender that knows it is 100ms away from the current leader, sees the leader's last slot, and sees a shred at tick 32 of 64 can infer there are only 100ms left and start routing to the next leader. That inference has nothing to read after activation. Anything else that treated an entry with no transactions as a tick, or waited for a final tick to consider a block complete, is affected the same way.

What to do instead:

• For block completeness, use the block footer and block meta's entries_count and executed_transaction_count (details).
• For time inside a slot, keep your own slot clock. Slots start on a fixed cadence, so track when successive slots begin as seen from your node, correct for your measured one-way latency to the leader (the shreds you see were produced that long ago), and derive slot boundaries from the corrected cadence rather than from the arrival of any single shred. Timing a full slot from first-shred arrival alone is late by production plus propagation delay, which on 200ms slots is a material fraction of the slot. There is no replacement signal in the ledger; the block footer's production time is set once per block, not as the block fills.

The Clock Sysvar Has a New Source

Programs read wall-clock time from Clock.unix_timestamp. Today that value is the stake-weighted median of the timestamps validators attach to their vote transactions. Vote transactions leave the ledger under Alpenglow (why), so that input disappears with them.

Under Alpenglow the leader sets the timestamp for its block directly, within a range that depends on how much slot time has passed since the parent. The lower bound is the parent's timestamp. The upper bound is the parent's timestamp plus twice the elapsed slot duration: for a block directly after its parent on 200ms slots that is parent + 400ms, and if four slots were skipped in between it is parent + 2s. Validators reject a block whose timestamp falls outside that range. The rule is specified in SIMD PR #363; check it before hard-coding any number. The value lands in the block footer for indexers and in the same Clock sysvar programs already read, so no code change is needed to keep reading it.

Who is affected: programs and indexers that depend on how closely the timestamp tracks real time, not on the fact that it exists. The trust model shifts from a stake-weighted median to one leader per block:

• A dishonest leader can push the clock ahead, but only up to the bound, once, in its own block. It cannot move it backwards. Because the bound scales with elapsed slot time, the room to skew is largest right after a run of skipped slots.
• Honest leaders correct for that by setting parent + 0 until real time has caught up, so a run of dishonest leaders can accumulate skew and a run of honest ones bleeds it off. Over an honest majority the clock converges on real time.
• The value stays monotonic, updates once per slot, and remains a coarse clock. There is no fixed drift guarantee to code against; treat the envelope as a function of slot duration and skipped slots, not as a constant. Nothing about Clock.slot, Clock.epoch, or the other fields changes.

Checking Whether Alpenglow Is Active

There is no fixed activation time, and each cluster migrates on its own schedule. Ask the cluster.

Agave v4.3 adds a getAgGenesisCert RPC method that returns Alpenglow's genesis certificate, the certificate covering the first block produced under the new consensus. It takes no parameters and reads from the finalized bank:

• null: the cluster is still running TowerBFT.
• A certificate object: the cluster has migrated, and block.slot is the slot where Alpenglow consensus began.

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

While the cluster is still on TowerBFT, the result is null:

{ "jsonrpc": "2.0", "result": null, "id": 1 }

Once it has migrated, the result carries the certificate:

• block.slot and block.blockId: the slot of the first block produced under Alpenglow, and its block ID as a 32-byte array.
• signature.signature and signature.bitmap: the 192-byte aggregate BLS signature, and the bitmap of the ranks of the validators it covers.

The Solana CLI wraps the same call, from v4.3 onwards:

solana alpenglow-genesis-info

Both ends have to be on 4.3. An older CLI does not have the subcommand, and an RPC node running an earlier version answers getAgGenesisCert with a Method not found error (-32601) rather than with null. Detection code should treat that differently from "still on TowerBFT". Check the two versions with solana --version and solana cluster-version.

Before the migration the command prints still running tower. After it, the epoch the feature gate activated in, the genesis block's slot and block ID, and how many validators signed:

Alpenglow genesis information:
  Feature flag activation: Epoch 987
  Genesis Block - Slot 412300800, Block ID 7Yx3...9Qk2
  Genesis Vote - 1183 validators participated, Signature 8f2a...

@solana/kit exposes it from 8.3.0 onwards, typed and on the default RPC API:

import { createSolanaRpc } from "@solana/kit";

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

if (cert === null) {
  // The cluster is still running TowerBFT.
} else {
  console.log(`Alpenglow has been active since slot ${cert.block.slot}`);
}

Gate any Alpenglow-specific behavior on this call rather than on a date or a client version string. SDKs other than Kit do not expose the method yet, so elsewhere it is a raw JSON-RPC request for now.