Solana switches mainnet consensus to Alpenglow with a target block-finalisation time of about 150 milliseconds

The network changed consensus after a short transition window

Epoch 1064 began at about 13:36 UTC on October 21. The network activation flag became active at the start of the epoch, but the network continued to use TowerBFT for the first 5,000 slots. That transition window lasted about 18 minutes.

Alpenglow took control at about 13:54 UTC from slot 459,653,000. Solana reported that 446 of 654 validators certified the transition block. The delay was planned and gave operators a clear point at which to check whether the new consensus system had started.

Votor replaces vote transactions with direct validator messages

Under TowerBFT, validators placed votes inside transactions and block finalisation depended on votes accumulating across 32 slots. Alpenglow‘s Votor system sends votes directly between validators and combines them into certificates. A block can become final after one or two voting rounds.

Wallets and ordinary programs do not need a new transaction format. The Solana Virtual Machine, accounts and fee model remain in place. The practical benefit is faster certainty that a confirmed transfer or an action inside an application cannot be reversed.

The 200-millisecond slot time is a separate change

Solana reduced its slot time from 400 to 200 milliseconds in a separate October update. Slot time describes how often the network can produce a new slot. Alpenglow‘s roughly 150-millisecond figure describes the target time to finalise a block. The two figures measure different parts of the system.

The target is not a fixed result: block finalisation time can vary with network conditions and validator location. Exchanges and applications should measure real behaviour instead of treating 150 milliseconds as a promise for every transfer.

Data services must distinguish several versions of one slot

A slot can temporarily have more than one candidate block, which Solana calls candidate banks. A bank_id identifies a candidate inside one data connection. Indexers must keep those versions separate until one becomes confirmed. When comparing data from different providers, they should use the block hash because bank_id values are local to each connection.

Vote transactions no longer appear inside blocks. Dashboards that previously counted those votes as transactions may therefore show a sudden fall in displayed TPS even when user activity is unchanged. This is an accounting change, not proof that the network has lost traffic.

Validators need compatible software and funds for the admission ticket

Mainnet validators must run compatible releases of Agave, Jito-Solana or Harmonic Salsa. They also need at least 0.8 SOL above the rent-exempt minimum in the vote account. That amount funds the Validator Admission Ticket, identified in the documentation by the English abbreviation V-A-T, for the next epoch.

The Validator Admission Ticket replaces the recurring cost of sending vote transactions. If the vote account cannot pay for the ticket, the validator cannot vote or produce blocks in the following epoch. Operators can direct future block revenue to the account, but they still need a starting buffer.

Rotor will be introduced later

The live mainnet release includes Votor. Rotor, the planned replacement for Turbine block-data distribution, will arrive later and has no confirmed activation date. The consensus switch is complete, but the wider Alpenglow networking plan is not yet fully deployed.

For users, the immediate improvement is faster final confirmation. Exchanges, explorers and data providers must now handle candidate banks and the revised transaction count correctly so that their services display the network’s activity accurately.

This article is for information only and is not investment advice.

admin_wcContributor · World-CryptMore from