TriportRPCDashboard

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.

Endpoint and plans: Solana RPC endpoint.

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 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, 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.

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.