Solana Alpenglow is live: 150ms finality, Votor, and RPC changes

Solana activated Alpenglow’s Votor consensus on October 21, 2026, replacing TowerBFT at slot 459,653,000. The protocol targets roughly 150ms block finality. That is a consensus target—not a guarantee that a transaction lands, executes, and reaches an RPC client within 150ms. 

For HFT and MEV systems, RPC developers, indexers, and validator operators, the useful questions are narrower: What went live, what changed in the data model, and what must be measured again? Rotor, the proposed replacement for Turbine block propagation, remains a future phase. Solana’s separate 200ms-slot rollout completed before Votor activated. 

• RPC Fast remained fully operational during the update, with no impact from Alpenglow so far.
• Votor is live; Rotor is not. Alpenglow now finalizes blocks with direct validator votes and aggregate certificates, while Turbine still moves block data.
• ~150ms means target consensus finality, not end-to-end trading latency, API latency, or a fixed p95/p99 production result. 
• The commitment API still exposes three options. Under Votor, confirmed and finalized reflect the same consensus state; processed remains speculative.
• Geyser and Yellowstone consumers must treat banks explicitly. Buffer candidate updates per (slot, bank_id); do not merge bank IDs across providers. 
• 200ms slots were a different upgrade. They shortened a ~150-block recent-blockhash window to roughly 30 seconds and reduced the wall-clock duration of leader control.

Solana 200ms Slots: How to retune your trading bot for profitability

Market insights

Written by:

Olha Diachuk

Date:

19 Oct 26

15

min read

• Vote transactions disappear from block statistics; transaction-count and TPS charts need a new baseline. That does not establish a 75% increase in user transaction capacity. 

For production testing: compare block freshness, commitment notification lag, end-to-end transaction landing, and p95/p99 under a fixed region and workload. Do not use nominal finality as a substitute for those measurements.

What went live on October 21, 2026?

The Alpenglow feature gate activated at the beginning of epoch 1064, around 13:36 UTC on October 21. Mainnet then continued with TowerBFT for 5,000 slots. The final TowerBFT block, slot 459,652,999, became the Alpenglow genesis block; Votor took over at slot 459,653,000, roughly 18 minutes into the epoch. The handoff itself was reported at about 900ms. 

The deployment changed the consensus path, not Solana’s runtime. Votor did not change the SVM, transaction format, transaction submission mechanism, priority-fee rules, or application instruction execution. Wallets using standard JSON-RPC generally didn't need to migrate just because Alpenglow activated. 

Votor replaces TowerBFT; Rotor remains a separate phase

TowerBFT achieved finality by building lockouts from successive stake-weighted validator votes. The commonly quoted 12.8 seconds corresponds to 32 slots at the former 400ms target. Validator votes also appeared as on-chain transactions, consuming resources and inflating transaction counts. 

Votor replaces this mechanism with direct validator vote messages and BLS-based aggregated certificates. A block reaches fast-path finalization when at least 80% of stake votes to notarize it in the first round. Other cases proceed through a second-round path using 60% stake certificate thresholds to finalize, notarize, or skip a candidate. These are quorum rules, not guaranteed 100ms and 150ms wall-clock deadlines. 

Alpenglow’s specified resilience model combines 20% adversarial stake with 20% offline stake under the protocol’s assumptions. This does not mean any arbitrary 40% Byzantine failure pattern is safe. See the formal protocol specification for the underlying safety and liveness conditions. 

Rotor addresses a different bottleneck: Turbine’s tree-based block propagation. Its proposed single-relay-layer design is not deployed on mainnet. Claims about modeled Rotor fanout or shred-transfer timing belong to future architecture discussion, not current production benchmarks. 

150ms finality and 200ms slots measure different things

Finality is the consensus decision that a block belongs to the canonical chain. Slot time is the target cadence for giving a scheduled leader the opportunity to produce a block. The two intervals start at different points, and neither tells you when an API request returns or a response transaction lands.

Solana completed the separate slot-time reduction on October 9, 2026, reaching a 200ms target after four 50ms steps. Thus, before Votor went live, the 32-slot TowerBFT lockout translated to approximately 32 × 200ms = 6.4 seconds at the new target cadence, rather than the historical 12.8 seconds. That 6.4-second value is a transparent slot-time calculation, not an independently measured finality percentile.

The table deliberately excludes forecasts such as 65,000 → 107,000 TPS, a universal 75% block-space gain, or a 90% validator profitability improvement. Those figures are not established by a comparable post-activation production benchmark.

Commitment levels: simpler consensus, familiar API

The processed commitment remains the earliest and least secure observation point. It indicates that a node executed a candidate bank; that bank might still be abandoned. Under Votor, confirmed and finalized now identify the same final consensus state, though both options remain exposed to callers. Solana advises new code to target finalized; it plans to remove confirmed later.

This improves certainty sooner after a block is produced. It does not mean all transaction failures vanish. Transactions still fail execution, expire before inclusion, or arrive through delayed providers. Deposit crediting, bridge settlement, and payment systems still have application rules and, where relevant, counterpart-chain finality to consider.

Breaking changes for Geyser, Yellowstone gRPC, and multi-provider ingestion

A slot is not always one block. Agave 4.3 introduced bank_id on Geyser and related Yellowstone updates so clients can distinguish candidate banks competing within the same slot. A consumer keyed only on slot risks splicing transactions and accounts from different candidates into one invalid reconstructed block. Fast leader handoff in the planned Agave 4.4 release makes multiple-bank handling more relevant, although Solana expects such slots to remain uncommon.

• Within one stream: buffer by (slot, bank_id); promote the candidate that reaches confirmed/finalized status and discard losing banks. For manual reconstruction, seal a block only after its expected transactions, entries, and metadata arrive.
• Across provider streams: keep separate buffers for each connection. bank_id is node-local and carries no global order. Reconcile sealed blocks by blockhash; unsealed candidates lack a usable blockhash comparison.
• For Yellowstone block subscriptions: an updated provider/plugin handles the reconstruction layer. Consumers parsing raw transactions, entries, or account updates still need to check the subscription schema and their own merge/deduplication logic.

The Yellowstone gRPC changelog documents October 2026 fixes for status events overtaking bank data, potentially dropping a slot or producing a duplicate confirmed block. This makes bank-aware ordering and replay correctness measurable production concerns rather than theoretical fork-handling details.

PoH retirement changes clocks and block boundaries

Alpenglow retires Proof of History as Solana’s continuous network clock. PoH tick entries disappear from shreds and entries, so systems estimating intra-slot progress from tick counts need a different approach.

Use block metadata and the Alpenglow block footer for block boundaries, and treat elapsed slot progress as an estimate informed by observed propagation, not as a precise tick count.

Clock.unix_timestamp also has a different trust model: it is derived from a bounded leader-supplied timestamp, not the previous stake-weighted median of vote timestamps. The value remains a coarse, monotonic clock. Programs and off-chain analytics that infer precise real time from it should revisit those assumptions, especially after skipped slots.

Vote transactions disappear; user throughput needs its own benchmark

Votor moves validator voting out of regular block transactions. As a result, historical total TPS charts containing vote transactions are no longer directly comparable with post-Alpenglow counts. For analytics, retain a separate series for user transactions and re-baseline totals from the activation slot.

Vote removal reduces consensus-related on-chain traffic, but it does not by itself prove a 75% increase in useful compute capacity or a jump to 107,000 TPS. Real throughput depends on compute limits, account contention, network propagation, transaction mix, and execution. The defensible metric is non-vote throughput on a matched workload, measured before and after with conditions stated.

What changes for HFT, DeFi, and MEV strategies?

Votor shortens the interval from block proposal to finality. It does not choose execution order, rewrite priority-fee rules, or guarantee leader access. Therefore, claims that Alpenglow automatically eliminates sandwich attacks or flattens priority-fee markets overstate what consensus alone changes.

A separate, measurable market-structure effect comes from shorter slots. Solana’s four-slot leader span shrank from a 1.6-second target at 400ms slots to 0.8 seconds at 200ms slots. In a September 28 analysis of the staged rollout, Solana Foundation researchers reported that the p99 maximal contiguous leadership interval fell from roughly 3 seconds to 2 seconds. That is a slot-time observation—not a Votor finality benchmark. The effect on sandwich profitability remains workload- and strategy-dependent.

For trading infrastructure, distinguish signal arrival → decision → submission → inclusion → finality notification.

Relevant production measurements include first-byte or decoded-message delivery, decision latency, blockhash freshness, transaction landing rate, inclusion latency, finality-observation lag, and p95/p99 variation by region and route. Some stages overlap, so use transaction traces instead of summing nominal API timings.

The 30-second blockhash window deserves attention

The separate 200ms-slot rollout shortened the approximate wall-clock lifetime of the usual 150-block recent-blockhash window from around 60 seconds to 30 seconds, without changing its block-height accounting model. Long signing flows, mobile wallets, retries, and failover have less wall-clock headroom. Track the lastValidBlockHeight returned with getLatestBlockhash and distinguish expiration from a confirmed execution failure. 

Validator economics: Lower vote overhead, a recurring admission ticket

Under TowerBFT, validators paid for frequent on-chain vote transactions. Alpenglow removes that cost and uses a Validator Admission Ticket (VAT). At the live 200ms-slot configuration, it charges 0.8 SOL per epoch (about every 24 hours) from the vote account, above its rent-exempt minimum. The charge for epoch E covers admission in epoch E+1; an underfunded validator cannot vote or produce blocks in the following epoch. 

The admitted set is capped at 2,000 validators, and validators need a registered BLS vote key. The original VAT proposal’s 1.6 SOL figure applies to the former 400ms target; SIMD-0525 scales the fee with slot duration. Neither fee reduction nor removing vote transactions creates a universal 90% drop in profitable stake: stake rewards, hosting, hardware, leader revenue, and operating costs still determine the break-even point.

For the October mainnet handoff, supported validator clients were Agave v4.3.2, Jito-Solana v4.3.2-jito, and Harmonic Salsa v4.3.2-harmonic. Firedancer and Frankendancer were not supported for that migration. Treat this as a dated compatibility snapshot, not an instruction to freeze future validator upgrades.

What infrastructure teams should benchmark now

A useful post-activation review separates protocol timing from infrastructure behavior. Use one workload and consumer region for before/after comparisons, keep provider and commitment settings explicit, and inspect tails rather than a single average.

• Block and status data: latest seen slot; delivered and finalized slot; last finalized blockhash; missing, duplicate, and reverted candidate-bank events.
• Geyser/gRPC correctness: (slot, bank_id) buffer integrity; sealed-block counts; reconnection replay; cross-provider blockhash reconciliation.
• Delivery: first signal, complete payload, decoded payload, p50/p95/p99 and consumer lag; reconnections and stream gaps.
• Transaction results: send timestamp, inclusion and finality-notification times, landing rate, route, retry count, and blockhash expiry.
• Analytics: non-vote transaction count, true user throughput, observed slot-duration distribution, and explicit pre/post-activation baselines.

The protocol’s target is a useful design input; observed p95/p99 and correctness under reconnects determine whether a production system benefits. Solana also publishes a consensus transition dashboard, but check its selected cluster and measurement definition before citing a value as mainnet performance. 

A short RPC Fast product note: Aperture gRPC is now TxStream

RPC Fast deprecated its older Aperture gRPC interface in September 2026 and replaced it with Aperture TxStream. TxStream supplies shred-derived, reconstructed, and decoded transaction data, Address Lookup Table resolution, filtering, and optional simulation. Yellowstone gRPC remains the structured event-ingestion layer; Shredstream gRPC remains an earlier shred-derived feed.

For readers evaluating infrastructure, compare the interfaces against the workload: targeted JSON-RPC reads, filtered Yellowstone subscriptions, shred-level visibility, or decoded transaction signals. Keep latency and landing comparisons provider-neutral and repeatable.

Alpenglow hasn’t affected RPC Fast performance so far. Explore the latest benchmarks.

Things to do first after Alpenglow update

Alpenglow’s deployed achievement is faster consensus finality through Votor. Rotor remains future work, while shorter slots came from a separate rollout. 

Most ordinary Solana applications continue working; teams consuming Geyser data, merging gRPC feeds, tracking vote-inclusive TPS, or relying on PoH ticks have concrete integration checks to perform.