Prepare Solana RPC, gRPC, and indexing systems for Alpenglow with a practical readiness worksheet.
Rrpc edge Team·Jul 22, 2026·11 min read
Frequently asked questions
When will Alpenglow launch on Solana mainnet?
Solana's official upgrade page lists expected mainnet activation in Q3 2026. A July 2 changelog said Alpenswitch was expected on Testnet in July and Mainnet in August. These are roadmap dates, not a guarantee, so production teams should follow the feature activation and release notes.
Will Alpenglow remove processed, confirmed, and finalized RPC commitments?
Current public sources do not announce the removal of those application-facing commitment names. They do change the consensus mechanism beneath commitment and finality. Retain the existing API contract until Solana client or provider release notes state otherwise, then test the timing and transition behavior again.
Does Alpenglow replace Turbine and Solana shreds?
Not in the first phase. SIMD-0326 keeps Turbine as the initial data dissemination protocol. Rotor is planned as a later phase with its own protocol work, so builders should not assume the Votor rollout removes today's shred path.
Why does Alpenglow affect Solana indexers?
Alpenglow moves validator votes out of ordinary on-chain vote transactions and introduces certificates and block markers. Indexers that count vote transactions, infer confirmation from them, or assume every slot follows the TowerBFT path need explicit migration tests.
What should a Yellowstone gRPC consumer test before activation?
Test slot-status ordering, duplicate handling, reconnect and replay, quiet-period alerts, commitment transition timing, fork reconciliation, and behavior around the migration boundary. Tie application decisions to observed status rather than fixed delays.
The protocol replaces Solana's TowerBFT consensus path. It does not replace every RPC method, every
stream filter, or Turbine on day one.
For builders, the useful distinction is scope. The consensus mechanism is changing first. The
application contract should be treated as stable only where current client and provider releases
say it is stable.
We separate three states: what official sources define, what builders should test, and
what remains unknown before activation.
Solana's official Alpenglow upgrade page describes a phased
rollout. Phase 1 introduces Votor, the voting and finalization part of Alpenglow. Phase 2 is expected
to replace Turbine with Rotor later.
The first phase changes how validators decide a block:
TowerBFT path
Alpenglow Votor path
Validators submit vote transactions on-chain
Validators send signed votes directly to peers
Lockouts and roots drive finality
Stake-weighted certificates decide notarization, finalization, or skip
Optimistic confirmation precedes rooted finality
Fast finalization can complete after one voting round
Turbine propagates block shreds
Turbine remains the initial data dissemination protocol
SIMD-0326
defines two finalization paths. A fast-finalization certificate requires votes from at least 80% of
stake in the first round. The slower path uses certificates built from 60% stake thresholds across
two rounds.
The same proposal says optimistic confirmation is superseded by faster actual finality. The 150 ms
target comes from this design, but it does not mean every application will observe a finalized update
150 ms after first seeing a transaction. Provider processing, network distance, serialization,
consumer queues, and application work remain in the path.
Consensus finality can get shorter while application tail latency stays long. Measure both clocks.
TowerBFT votes appear as transactions. Indexers can count them, attribute them to vote accounts, and
use them as one input into cluster analysis.
Under Alpenglow, ordinary votes move off-chain. Validators broadcast signed vote messages and
aggregate them into certificates. The proposal describes later on-chain aggregates for reward
accounting, but those are not a one-for-one replacement for today's vote-transaction stream.
Audit any system that uses the vote program for more than validator economics. Common dependencies
include:
Counting vote transactions as a proxy for cluster activity.
Inferring confirmation from observed on-chain votes.
Estimating validator responsiveness from vote-transaction arrival.
Filtering vote traffic out of bandwidth or transaction-rate calculations.
Alerting when a vote account stops producing its familiar transaction pattern.
The fix is not to rename a filter. The system needs a new source for consensus evidence and a clear
definition of what each metric means after Votor starts.
Application indexers that ignore vote transactions face a smaller change, but it still deserves a
regression test. Removing a large transaction class changes volume, block composition, and some
historical baselines.
Applications currently request processed, confirmed, or finalized state. Our
commitment-level guide explains the live TowerBFT model.
Current public Alpenglow material does not define a replacement set of application-facing RPC
commitment strings. Builders should not pre-emptively rename them or ship a guessed mapping.
The safer change is internal: stop treating commitment as a fixed wall-clock delay.
commitment-distance.ts
import { Connection, type Commitment } from "@solana/web3.js";const rpc = new Connection(process.env.SOLANA_RPC_URL!, "confirmed");const commitments = ["processed", "confirmed", "finalized"] as const satisfies readonly Commitment[];async function sampleCommitmentDistance() { const [processed, confirmed, finalized] = await Promise.all( commitments.map((commitment) => rpc.getSlot(commitment)), ); return {
The sample measures slot distance, not finality latency. Keep receive timestamps on stream events
as well. After activation, compare both the slot gap and elapsed time for the same workload.
Do not hard-code today's expected number of slots between states into trading, accounting, or user
balance logic. Act on the status the node reports, then record when each transition arrived.
The migration needs a specific handoff from TowerBFT.
SIMD-0384
is still marked Review, so treat its details as the current proposal rather than an immutable
mainnet contract.
The proposal defines a migration boundary where validators temporarily stop packing ordinary user
transactions, stop TowerBFT rooting, and stop sending optimistic commitment updates to RPC services.
After validators agree on an Alpenglow genesis block, user transactions and RPC commitment reporting
resume under Alpenglow.
A planned consensus handoff is not an ordinary quiet slot. Monitoring should distinguish it from:
A dead stream connection.
A provider that has fallen behind the cluster.
A consumer queue that stopped draining.
A genuine cluster stall.
Do not suppress alerts for an arbitrary time window. Key the exception to official activation data,
observe multiple independent endpoints, and keep a hard timeout. If the handoff does not match the
published activation path, fail over or pause irreversible application actions according to your
existing incident policy.
A Yellowstone gRPC subscription may keep the same filter shape through the Votor rollout. The data
behind slot and commitment updates will come from different consensus machinery.
Production consumers should test these behaviors on the relevant pre-production cluster:
Record every slot update with status, receive time, endpoint, and reconnect generation.
Verify that status transitions remain monotonic inside one observed fork.
Force a disconnect and confirm replay does not create duplicate business actions.
Compare processed, confirmed, and finalized arrival for the same slots.
Trigger the quiet-period alarm and verify it distinguishes socket health from chain freshness.
Reconcile transaction and account updates against finalized state after the test.
The reconnect mechanics are covered in our
Yellowstone gRPC reconnect and replay guide.
The upgrade adds a new cluster transition to that existing recovery problem. It does not remove the
need for cursors, idempotency, or reconciliation.
Streaming and finality answer different questions.
Streaming tells an application that relevant state moved. Consensus tells it how much confidence to
place in the result. Faster finality can shorten the period between first observation and settlement,
but an application still needs a low-overhead way to receive transactions, accounts, blocks, and
slot status.
Trading systems may carry less reconciliation debt when the settlement window shrinks. That does not make
network placement, consumer queue age, filter quality, or transaction delivery irrelevant. A bot
can still lose its usable window before a finalized notification reaches its strategy loop.
App teams may get simpler state progression. A wallet or payment service could spend less
time showing provisional state if the target survives real network conditions. Any benefit must be
measured after activation rather than inferred from the protocol target.
The consensus proposal explicitly leaves Rotor out of the initial phase. The upgrade page also
describes Rotor as a later phase.
Builders should therefore keep two migrations separate:
Votor: new voting, certificates, finalization, and consensus handoff.
Rotor: a later block-propagation change expected to replace Turbine.
Do not remove shred ingestion or rewrite a Turbine-dependent pipeline because Votor activates. Our
Turbine explainer remains the relevant model for phase 1.
When Rotor has an accepted specification, client release, and activation schedule, it deserves a
separate migration plan.
Run this worksheet once before cluster testing, again after the first supported test release, and a
third time after mainnet activation.
Area
Question
Evidence to retain
Dependencies
Inventory metrics, alerts, and product features that consume vote transactions
Query, filter, dashboard, and owner
Commitment
Find code that assumes a fixed time or slot gap between states
Source location and replacement rule
Streaming
Prove reconnect, replay, and deduplication cannot repeat a business action
Test trace and duplicate count
Freshness
Separate socket health from latest observed cluster slot
Endpoint comparison and alert output
Migration
Set a bounded policy for the activation handoff
Activation source, timeout, and operator action
Settlement
Reconcile provisional state against finalized state
Reconciliation log and mismatch result
Rollback
Return to the previous provider or pause writes safely
Tested command and responsible operator
Use a captured production-shaped workload. Record the current baseline before changing a client or
provider. A result without the software version, region, filter, and sampling window cannot explain
a regression later.
As of July 22, 2026, builders should leave these questions open:
The final activation slot and whether the current Q3 schedule moves.
The exact application-facing commitment behavior in every validator and RPC release.
How each hosted provider exposes Alpenglow-specific certificate or migration telemetry.
The observed distribution of mainnet finality, including p50 and tail latency.
The accepted specification and activation path for Rotor.
The July 2 Solana engineering changelog
said Votor work begins in Agave v4.3, with Alpenswitch expected on Testnet in July and Mainnet in
August. Its upgrade page gives the broader Q3 window. Track both, then defer to the actual
feature activation and supported client release.
The 150 ms target explains why Alpenglow matters. It is not the migration plan.
The operational work is more concrete: find vote-transaction dependencies, measure commitment
transitions, test stream recovery, add a migration-boundary alarm, and retain a rollback path. Once
mainnet activation occurs, replace targets with observed distributions from the workload your
application runs.
A measured migration turns a consensus upgrade into a controlled application change instead of a surprise in
production.
Run the readiness worksheet against one production-shaped filter. If you need a second endpoint for
the comparison, review the RPCEdge plans.