Solana Alpenglow on October 21: what changes for bots, RPC and indexers

Alpenglow is Solana's new consensus protocol, and it goes live on mainnet at epoch 1064, on Wednesday October 21, 2026 at about 15:00 UTC. Its voting part, Votor, replaces TowerBFT: validators stop voting with transactions, and a block becomes final in a target of about 150 ms instead of about 12.8 seconds. Sending transactions does not change. Reading them does, in four places: commitment levels, vote transactions, bank_id in gRPC, and how you detect the switch.

Everything here comes from the Solana and Anza pages for the upgrade, Triton's integrator guide and calls I made to a public mainnet RPC node. This is what happens on the day, in order.

Until Oct 21TowerBFT, as today
Epoch 1064 · about 15:00 UTCThe feature gate turns on
Slot 459,653,000Vote-only blocks
82% of stake signsThe genesis certificate
Hundreds of millisecondsHandoff to Votor
AfterAlpenglow

Explainer · The switch on October 21, 2026

Moment 01TowerBFT, as today
Validators vote by sending transactions, and a block is finalized about 12.8 seconds after it is produced. getAgGenesisCert returns null.
Moment 02The feature gate turns on
Nothing changes yet. TowerBFT keeps running for the first 5,000 slots of the epoch, about 18 minutes at today's slot length.
Moment 03Vote-only blocks
From this boundary, blocks carry only validator votes. Your transactions wait. Validators vote on one genesis block for the new protocol.
Moment 04The genesis certificate
Once validators holding 82% of stake have signed the genesis block, the certificate exists and the switch can happen.
Moment 05Handoff to Votor
Blocks after the genesis block are rolled back and Votor takes over. Anza says nothing a user signed is lost. User transactions resume. Treat processed data from the window as temporary.
Moment 06Alpenglow
Votes are no longer transactions. confirmed and finalized mean the same thing, at a target of about 150 ms. gRPC updates carry a bank_id. getAgGenesisCert returns the certificate.

What is Alpenglow?

A new consensus protocol for Solana, shipped in Agave 4.3. It comes in two parts. Votor, the voting part, goes live on October 21. Rotor, which would replace Turbine for spreading blocks, is not scheduled yet, so the shred path in how a Solana transaction lands stays as it is for now.

Under TowerBFT a validator votes by sending a vote transaction, and those votes fill a large part of every block. Under Votor validators send votes straight to each other and combine them into certificates: one aggregate signature plus a bitmap of who signed. A certificate is the proof that enough stake agreed.

Do not confuse the 150 ms with the slot. The slot, the time a leader has to produce a block, is a separate change that went from 400 ms to 200 ms and averaged 218 ms on chain in its first four epochs. The 150 ms is how long a block takes to become final after it is produced.

How does Votor finalize a block?

By stake thresholds. If at least 80% of stake votes for a block in the first round, it is final after that round. Otherwise a block needs two rounds of 60% certificates. A block that cannot reach 60% is skipped with a skip certificate.

Stake voting for the block97%

Under 60% · skip2 rounds80%+

Outcome: Final in one round
Offline · voting against: 3% · 0%

Try it · How Votor finalizes a block97%

Final in one round

At least 80% of stake voted for the block in the first round, so it is final after one round.

Anza says Alpenglow keeps working with 20% of stake malicious and another 20% offline at the same time. Set both to 20 and 60% is left, exactly the second-round threshold.

Offline stakeStake voting against

Those thresholds are why Anza says Alpenglow tolerates 20% malicious stake and 20% offline stake at the same time: what is left is 60%. The switch itself has its own, higher bar. The genesis certificate needs 82% of stake, and Anza expects blocks to typically get over 95%.

What changes for my bot or app?

Commitment. processed is unchanged. confirmed and finalized describe the same state, and confirmed is deprecated and will be removed in a later release. Switch your code to finalized after October 21, not before.
Timeouts. Anything sized around a 12.8 second wait for finality can be shortened.
Duplicate bursts. If you subscribe at both confirmed and finalized, the two updates for a block now arrive back to back instead of 12.8 seconds apart.
The switch window. Between slot 459,653,000 and the handoff, blocks hold only votes and your transactions wait. Blocks after the genesis block are rolled back. Treat processed data from that window as temporary and trust what reaches finalized.
Sending. Nothing changes. Same transaction formats, including the new v1 format, same fees.

What changes for gRPC and indexers?

bank_id. Agave 4.3 adds it to Geyser and gRPC updates, because one slot can have more than one candidate block. Buffer per (slot, bank_id) and keep the bank that reaches confirmed. Triton expects this in fewer than 1 in 100 slots, more often from Agave 4.4.
Several providers. bank_id is a counter local to each node, so the same block can have different ids on two connections. Keep one buffer per connection and match blocks across providers by blockhash only.
Votes leave blocks. Blocks get smaller, bandwidth drops, and vote: false filters have nothing left to remove. Re-baseline transaction-count dashboards and alerts.
Block footers. A new footer can carry certificates. For now it is available over gRPC only, with JSON-RPC support later.
Ticks are gone. PoH no longer paces blocks and tick entries leave the stream. Code that reads time from ticks needs a local slot clock.
Clock.unix_timestamp. The leader now sets it within bounds of the parent block's time. Re-check logic that assumes it tracks real time closely.
Versions. Triton lists yellowstone-grpc-client 15.0.0, yellowstone-grpc-proto 14.0.1 and @triton-one/yellowstone-grpc 9.0.0 for the new fields. Older clients keep working; they just cannot see bank_id or footers.

How do I know Alpenglow is live?

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

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

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

{"jsonrpc":"2.0","result":{"feature-set":3383571666,"solana-core":"4.3.0"},"id":1}

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

{"jsonrpc":"2.0","result":{"absoluteSlot":456991837,"epoch":1057,"slotIndex":367837,"slotsInEpoch":432000},"id":1}

Explainer · Checking mainnet for Alpenglow

Command 01Ask for the genesis certificate
null means the cluster still runs TowerBFT. After the switch this returns the certificate. A Method not found error (-32601) means the node runs a version older than 4.3. This is the answer mainnet gave on October 14, 2026.
Command 02Check the node's version
getAgGenesisCert exists from Agave 4.3. The public node was already on it.
Command 03Count the epochs
The switch is in epoch 1064. On October 14 mainnet was in epoch 1057, and an epoch takes about 26 hours at the current slot length.

The Solana guide says to gate Alpenglow-specific code on this call rather than on a date or a version string. The CLI has the same check as solana alpenglow-genesis-info.

What does not change?

Program execution, the account model, transaction formats and transaction fees. Wallets sign and send as before. For a user the visible difference is that a transaction is final sooner.

What do the terms mean?

TowerBFT: the consensus Solana used until October 2026. Validators vote with transactions.
Votor: Alpenglow's voting protocol. Validators exchange votes directly and aggregate them into certificates.
Rotor: the planned replacement for Turbine, the block relay. Not scheduled yet.
Certificate: an aggregate BLS signature and a bitmap proving that a share of stake voted for a block or for skipping a slot.
Genesis certificate: the certificate on the first block of the new protocol. It needs 82% of stake.
bank_id: a node-local number that tells apart candidate blocks for the same slot.
Finality: the point after which a block cannot be reverted.

FAQ

When does Alpenglow go live on Solana mainnet?

At epoch 1064, which starts on Wednesday October 21, 2026 at about 15:00 UTC. The feature gate turns on at the epoch boundary, and the switch to Votor happens 5,000 slots later, at slot 459,653,000.

How fast is Solana finality with Alpenglow?

The target is about 150 ms after a block is produced, down from about 12.8 seconds under TowerBFT. The Solana Foundation calls it an expectation that depends on the stake distribution, not a constant.

Should I use confirmed or finalized after Alpenglow?

finalized, once Alpenglow is live. Both describe the same state after the switch, and confirmed is deprecated. Before the switch, finalized still means the old 12.8 second wait.

Why does Solana TPS drop after Alpenglow?

Votes are no longer transactions, so they no longer count in blocks or in transaction totals. User activity does not change, only the accounting.

Is there a new notarized commitment level?

No. You still choose processed, confirmed or finalized. Notarization is an internal step of the protocol.