Solana’s Alpenglow upgrade is live on mainnet, replacing the previous consensus process with Votor, a system designed to finalize blocks much faster. The Foundation’s roughly 150-millisecond target refers to protocol finality. It does not mean every wallet, exchange or bridge will show a transaction as complete that quickly.
- Votor is live: Solana’s new voting and finality system replaces TowerBFT.
- 150 milliseconds: the Foundation’s target for finalized commitment, not a guarantee users will see.
- Most users: do not need to change how they send transactions.
- Developers and validators: face new data-handling and operating requirements.
- Rotor: the planned block-distribution component is not identified as live in the Foundation guidance discussed here.
What changed when Alpenglow went live?
Solana Foundation migration records place the mainnet transition at slot 459, 653, 000 on October 21, 2026, during epoch 1064. Alpenglow replaces TowerBFT, Solana’s former consensus process, with Votor, which carries validator votes and combines them into certificates that help establish agreement on blocks.
The Foundation sets a new finalized-commitment target of roughly 150 milliseconds. Its migration guidance gives 12.8 seconds as a reference for the previous system. These figures compare protocol-level targets. They are not a controlled comparison of end-to-end transaction times, and they do not promise that every block will finalize in 150 milliseconds.
Finality means the network has agreed to treat a block as settled under its rules. That is stronger than an earlier status such as “processed, ” which can appear before the network reaches its strongest confirmation state. The target is ambitious, but independent measurements over longer periods will be needed to show how consistently it holds across different conditions and observation points. The 150-millisecond claim needs context.
Why a fast network can still feel slow
A transaction’s journey does not end when validators finalize a block. A wallet submits it through an RPC provider, a service that communicates with Solana, and then waits for an update. The application decides which status is safe enough to display or act on.
An exchange may still need to match a deposit to an account, screen it for risk and apply its own crediting policy. A bridge may need to relay a message, apply safeguards and execute a transaction on another chain. Those steps can take longer than consensus, even after the network has finalized the transfer.
Alpenglow gives services the option to act sooner, but it does not require them to change their waiting rules. Whether users see faster deposits, checkouts or bridge transfers depends on how wallets and service providers adapt their systems.
The Foundation says ordinary transaction formats, programs and user fee mechanics have not changed. Most people do not need to change how they sign or send transactions. The biggest adjustments are for validator operators and applications that stream or reconstruct block data.
What developers and data services need to change
A slot can contain more than one candidate bank. A bank is a version of the ledger state associated with that slot. Agave 4.3 adds a bank_id so streaming clients can distinguish between candidates. For a single stream, the Foundation advises buffering by both slot and bank_id, then keeping the bank that reaches confirmation.
According to the Foundation’s migration guidance, “confirmed” and “finalized” describe equivalent states under Alpenglow. Both commitment levels remain available at activation, but the Foundation recommends that new code use finalized. Confirmed is intended to be removed in a later release.
When combining data from different providers, bank_id is not a shared identifier. The Foundation says to reconcile streams using the blockhash instead. For example, two providers might assign different bank IDs to the same slot. Merging their records by slot and bank ID could treat one block as two candidates or fail to match corresponding data, creating duplicate or inconsistent records.
These changes matter most to indexers, explorers, trading systems and other services that build a view of the ledger from streamed data. According to the Foundation, applications that simply send transactions and read account state do not need to migrate. Some streaming interfaces may not forward all certificate metadata, which can limit what outside observers can determine about validator participation.
The Foundation identified Agave 4.3.2, Jito-Solana and Harmonic Salsa as compatible with the migration. Its operator guidance said Firedancer and Frankendancer were not supported for that migration. That describes migration support, not their longer-term role.
More multiple-bank behavior is expected with fast leader handoff in Agave 4.4. Anza expects it to occur in under 1% of slots. That is a forecast, not a post-launch measurement.
Transaction counts and timestamps need context
Alpenglow removes validator vote transactions from ordinary block transaction counts. So a lower headline transaction count after activation does not, by itself, mean user activity has fallen. The metric no longer includes a category of transactions that was counted before. Analysts need to compare like with like.
The Foundation also says tick entries are removed from the shred stream and Proof of History no longer paces block production in the same way. Systems that used ticks to estimate slot timing should not assume the old relationship still holds. For programs and analytics that rely on ledger timestamps, the Foundation says leaders set the timestamp within bounds based on the parent timestamp and elapsed slot duration. Skipped slots can give a timestamp more room to move ahead. Ordinary reads do not need a code change, but applications that treat the ledger clock as a close proxy for wall-clock time should account for the revised behavior.
A recurring cost for validators
The Foundation’s current guidance requires a Validator Admission Ticket costing 0.8 SOL per epoch. The fee comes from the vote account, on top of its rent-exempt minimum. A ticket bought at the start of one epoch admits the validator for the next.
If the required funds are not in the account, the validator may be unable to vote or produce blocks in the following epoch. The charge adds a recurring operating requirement. Its effects on smaller operators, validator participation and stake distribution remain to be measured.
Questions Solana users are likely to ask
-
Does every Solana transfer now finalize in 150 milliseconds?
No. Roughly 150 milliseconds is the Foundation’s protocol target, not a guarantee for every transaction or application.
-
Do I need to change how I send transactions?
No. The Foundation says transaction formats and user fee mechanics did not change.
-
Why might an exchange deposit still take longer?
The exchange may match the deposit, screen it for risk and apply its own crediting policy after the network finalizes the transfer.
-
Could transaction counts fall without user activity falling?
Yes. Validator vote transactions no longer appear in ordinary block counts, so comparisons with earlier totals need to account for the change.
-
Is Rotor live?
Votor is the live voting and finality system. The Foundation guidance discussed here identifies Rotor as planned and gives no activation date.
The next test is measurable user benefit
Alpenglow significantly changes how Solana reaches agreement on blocks. It also creates practical work for validators, streaming services and analysts. Operators need compatible software and funds in their vote accounts, data consumers must track candidate banks correctly, and transaction metrics need a new baseline.
For users, the key test is whether wallets, exchanges, merchants and bridges can safely act on finalized status sooner, and whether they can show that improvement with comparable end-to-end timings. Faster consensus is a real protocol change. On its own, it does not prove that every Solana interaction has become instant.
