# Alpenglow is live on Solana mainnet: what block consumers and dashboards need to change

> Anza says finality dropped from 12.8 seconds to about 150 milliseconds. The claim is vendor-reported; the changes to votes, commitment and block streams are what your code will actually meet.

- Canonical: https://triport.io/blog/news-solana-alpenglow-votor-live-2026-10
- Published: 2026-11-02
- Updated: 2026-11-02
- Author: Triport Engineering
- Category: Engineering
- Networks: Solana

## TL;DR

- On 2026-10-21 Solana validators switched from TowerBFT to Alpenglow's Votor at slot 459,653,000 in epoch 1064. Anza's own release states finality of about 150 ms against 12.8 s before; we found no independent post-switch measurement of that figure.
- Votes are no longer transactions and no longer sit in blocks, so raw transactions-per-block and TPS dashboards drop on their own. Triton's worked example is a block of 1,200 transactions becoming about 400. Reset baselines and alert thresholds before you page someone.
- Block builders must key buffers on slot and bank_id, not slot alone, and code that waited out the old 12.8 s at the finalized level can now shorten its timeouts. Detect the switch with getAgGenesisCert on your own node rather than by date. We have not yet published our own verification of any of this.

Solana changed its consensus protocol on a Wednesday afternoon without stopping the chain. On 2026-10-21, at slot 459,653,000 in epoch 1064, validators retired TowerBFT, which had run since the March 2020 launch, and began using Votor, the first component of Alpenglow. Anza announced the handoff at about 13:54 UTC. Rotor, the replacement for the block-propagation layer, was not part of it and has no date.

Most coverage is about the headline number. For anyone reading chain data the interesting part is smaller and more mechanical: what stops being in a block, what two words now mean the same thing, and which assumptions in your code were really assumptions about TowerBFT.

## What changed, from the people who shipped it

Anza's press release of 2026-10-21 says transactions "now become irreversible in about 150 milliseconds, down from 12.8 seconds." It also says the migration happened on the live network without a reset, after red teaming, penetration testing, repeated rehearsals and a security competition. The 150 ms figure is Anza's claim. Solana Compass noted in its own report that no independent post-switch measurement had been published, and, per the same report, Anza's lead economist told Decrypt that users should first notice latency of about 150 to 200 ms. Treat the number as a design target that the vendor says is met, until someone outside measures it.

The software side is on GitHub. Agave v4.3.2 was published on 2026-10-15 as "a stable release suitable for Testnet, Devnet and Mainnet Beta" and includes Alpenglow slot-timing fixes and a BLS certificate verification change. Reports around the switch said validators needed Agave 4.3.2 or a compatible Agave-based client, a registered BLS key and a 0.8 SOL per-epoch admission ticket in place of per-vote fees, and that Firedancer and Frankendancer were not supported during the migration. We take the client list from the Solana Compass and SolCard write-ups of the Foundation guide, because the Foundation's own upgrade page returned HTTP 429 to our fetcher on 2026-11-01. Treat those specifics as reported, not confirmed by us.

## Four changes your code will meet

**Votes left the blocks.** Under TowerBFT every validator vote was a transaction. Under Votor they are not, and they do not appear in blocks. Triton One's integrator guide, updated 2026-10-20, gives the example that a block that held 1,200 transactions before the switch might hold 400 after. That is a drop of two thirds with no change in user activity. Any alert such as "transactions per block below N" or "TPS fell 50 percent in an hour" will now fire on 2026-10-21 data and keep firing, and any month-over-month chart has a step in it on that date. Our own [voteSubscribe reference](https://triport.io/docs/sol/json-rpc/voteSubscribe) says votes were "the majority of all Solana transactions," which is the same fact seen from the stream side.

**Two commitment levels collapsed.** Triton's guide says `confirmed` and `finalized` "become the same thing" and recommends moving to `finalized`, with a warning that is easy to miss: do not switch before Alpenglow is live "otherwise you'll wait for 12.8 seconds." Work the timeout arithmetic once. A client that waits on `finalized` with a 15-second timeout had 2.2 seconds of margin under TowerBFT (15 minus 12.8). With finality near 150 ms the margin is about 14.85 seconds, so a retry loop tuned to the old delay can be shortened by an order of magnitude. Do that only after the switch is confirmed on the node you read from, and keep a ceiling in case the figure is not met on a bad day. The Foundation guide, as relayed by Solana Compass, says all three levels keep working on activation day.

**Slots can have more than one candidate block.** Yellowstone gRPC events now carry a `bank_id`. Triton's guidance is to buffer per `(slot, bank_id)` and never per slot, and, if you compare blocks across providers, to match them by blockhash only, since `bank_id` is assigned by each node. Competing candidates are expected in under 1 percent of slots. If you only consume complete block updates you do not need the field; if you assemble blocks from account and transaction updates you do. Existing clients keep working because fields were added, but they cannot see `bank_id` or the new block footer until the client library is updated.

**Ticks are gone.** Triton's guide says ticks no longer exist and code that read time from them stops working. Check anything that inferred clock time from tick counts rather than `getBlockTime`.

## Detecting the switch without a calendar

Triton's advice is to base any switch in your code on the new RPC method `getAgGenesisCert`, which returns `null` while TowerBFT runs and a certificate once Alpenglow is live, and returns "Method not found" on a node older than Agave 4.3. That is the right design. A date-based switch breaks the first time you point the same build at a node or a provider that lags. One caveat from our side: `getAgGenesisCert` is not in our documented Solana method list as of 2026-11-01, so do not assume any endpoint serves it until you have called it. Run the call against each provider you use and record which answer you get.

## What we have not checked

We have not measured finality on our infrastructure after the switch, so we publish no figure of our own. Two specifics are open on our side and worth a test in your own environment rather than trusting us. The first is [voteSubscribe](https://triport.io/docs/sol/json-rpc/voteSubscribe), a Pro-tier stream that today relays votes seen in gossip. The Agave 4.5.0 pre-release notes published 2026-10-26 list "Tower-related RPC code cleaned up" covering `voteSubscribe`, and "TPU UDP vote ingest blocked under Alpenglow." Those notes are for a test-only pre-release and not for mainnet, but they are a signal that what the method emits is changing. Subscribe, count frames for a minute, and compare with what you saw last week. The second is gRPC: the Yellowstone endpoint at https://grpc.triport.io streams what upstream emits, and whether your client sees `bank_id` depends on its library version. Update the library, then confirm in your own logs. For the wider picture of how our streaming surfaces differ, see the [streaming overview](https://triport.io/docs/streaming).

## When this is the wrong approach

Much of the work above is unnecessary for many teams. If your service only sends transactions and reads accounts, Triton (as relayed by Solana Compass) says you have nothing to do, and we agree. If you consume complete blocks and never put them together yourself, ignore `bank_id`. If you already poll `finalized` with generous timeouts, the change only makes you faster, and rewriting timeouts for the sake of it is risk without a payoff.

It is also the wrong time to remove safety margins on the strength of one vendor's number. Finality at about 150 ms is a protocol property under normal conditions. Your service still needs a path for a stalled leader, a partitioned node and a provider that lags, and none of those get shorter because the median improved. Compare the median you measure on your own path with the one in the press release before you change anything that can lose money.

## Sources

All fetched 2026-11-01 unless stated.

- Anza press release, "Alpenglow Is Live on Solana", 2026-10-21: https://www.prnewswire.com/news-releases/alpenglow-is-live-on-solana-the-worlds-fastest-finality-on-a-global-network-302915579.html
- Agave release v4.3.2, published 2026-10-15 (GitHub release metadata): https://github.com/anza-xyz/agave/releases/tag/v4.3.2
- Agave release notes v4.4.0 (2026-10-28), v4.4.0-rc.1 and v4.5.0-alpha.4 (2026-10-26), GitHub: https://github.com/anza-xyz/agave/releases
- Triton One, "Alpenglow and your Triton stack", updated 2026-10-20: https://blog.triton.one/alpenglow-and-your-triton-stack-what-to-update-before-mainnet/
- Solana Compass, "Solana Alpenglow Is Live on Mainnet as Anza Retires TowerBFT at Slot 459,653,000" (secondary, relays the Foundation guide and Anza posts): https://solanacompass.com/news/solana-alpenglow-is-live-on-mainnet-as-anza-retires-towerbft-at-slot-459653000
- Solana Foundation upgrade page, https://solana.com/upgrades/alpenglow: returned HTTP 429 on 2026-11-01, not read directly.
- Triport documentation: [voteSubscribe](https://triport.io/docs/sol/json-rpc/voteSubscribe), [streaming overview](https://triport.io/docs/streaming) and [commitment level](https://triport.io/learn/glossary/commitment-level), read 2026-11-01.

## Try it

- Reference: [voteSubscribe on Solana: the stream this change affects most](https://triport.io/docs/sol/json-rpc/voteSubscribe)
- Network: [Solana RPC: one key, JSON-RPC, WebSocket and gRPC](https://triport.io/solana-rpc)