Solana's Alpenglow consensus upgrade is live on mainnet-beta, replacing TowerBFT with a voting system that brings finality to roughly 150 milliseconds, down from the previous protocol's approximately 12.8 seconds.
Validators completed the switch on the running network at slot 459,653,000, with 654 validators participating in the genesis vote and a handoff that took 900 milliseconds. Anza developed Alpenglow and implemented it in the Agave validator client.
Anza | X
The upgrade shortens the wait for a transaction to become irreversible. Exchanges, merchants, and trading applications rely on that settlement assurance before treating funds as transferred. Wallet users do not need to migrate, and the Solana Virtual Machine, programs, transaction formats, and user fee mechanics remain unchanged.
How Validators Made the Switch
The migration began with a feature-gate activation at the start of epoch 1064. TowerBFT continued for another 5,000 slots before the handoff boundary. Blocks around that boundary temporarily carried only votes so validators could roll back the transition's trailing blocks without discarding user transactions.
Validators then signed a shared Alpenglow genesis block using BLS signatures, which can be combined into an aggregate signature. Once votes representing 82% of stake formed a genesis certificate, the network handed consensus to Votor, Alpenglow's voting protocol, and resumed including user transactions. The network recorded the certificate onchain so nodes could identify the completed migration. Anza's migration overview now marks mainnet-beta, testnet, devnet, and the community cluster as completed.
The rollout followed repeated migration rehearsals, red teaming, penetration testing, and a security competition. Anza completed nine successful migrations at scale and ran simulations across 1,500 nodes. Its research team published the protocol design in May 2025.
How Votor Reaches Finality
TowerBFT placed validator votes into transactions and accumulated voting lockouts across slots. Votor instead sends signed votes directly between validators and aggregates them into compact certificates. Finality follows after one or two rounds rather than a sequence of vote transactions stacked across blocks.
Two voting paths run concurrently. A block can finalize in one round when at least 80% of stake votes to notarize it, meaning validators accept the block as valid and suitable for adoption. A second path uses 60% stake thresholds across two rounds. The network uses whichever path reaches finality first, since a nearby group holding 60% of stake can sometimes complete two rounds faster than a geographically dispersed 80% completes one.
The roughly 150ms expected finality latency is based on testing and stake distribution and varies with conditions. It measures the time from a block's proposal to finalization; the interval between blocks is a separate measure.
Proof of History no longer paces block production. Validators use local timers to identify an unresponsive leader, then vote to skip it; a skip certificate lets the network move forward. The protocol can keep reaching consensus with 20% adversarial stake and another 20% offline simultaneously.
Removing vote transactions also frees the block capacity they previously consumed. Transaction counts and TPS metrics that included votes will fall mechanically, so comparisons with pre-upgrade totals need a new baseline. Validator participation data now comes from certificates rather than Vote program instructions inside blocks.
What Builders Need to Change
Applications that only send transactions and read account state do not need an execution migration. Builders primarily need to update how they handle commitment levels, process data, and read time from the ledger.
Finality and Streaming
Under Votor, confirmed and finalized describe the same state. Both remain available at activation, but developers should use finalized in new code and migrate existing code before confirmed is removed. Teams should also revisit timeouts, retries, and interface delays built around TowerBFT's longer finality wait.
Geyser and gRPC consumers need to distinguish candidate blocks within a slot. Agave 4.3 adds bank_id to identify the validator's working state, or bank, for each candidate. Pipelines should buffer by (slot, bank_id), retain the bank that reaches confirmation, and discard competing candidates rather than merging their events.
Those identifiers are local to each node. Services combining providers need separate buffers per connection and must reconcile completed blocks by blockhash, not by matching bank_id values across streams. Whole-block Yellowstone subscribers can use v16.0.0-rc10+solana.4.3.0, which performs the buffering; custom consumers should follow the Foundation's streaming migration checklist.
Ledger Time and Activation Detection
Tick entries leave the ledger with Proof of History's timing role. Infrastructure that counted ticks to locate block boundaries should use block metadata and footers instead.
The source of Clock.unix_timestamp also changes from a stake-weighted median of validator vote timestamps to a timestamp chosen by the block leader within protocol bounds. It cannot precede the parent's timestamp or exceed it by more than twice the elapsed slot duration. Programs can keep reading the same field, but timing-sensitive logic needs review because the permitted range grows after skipped slots.
Developers can check whether a cluster has migrated by calling getAgGenesisCert, using solana alpenglow-genesis-info, or accessing the RPC through @solana/kit 8.3.0 or later. A certificate identifies a migrated cluster; null identifies one still on TowerBFT. An older endpoint's method-not-found error is a separate result.
Validator Fees and the Next Releases
Validators migrated using Agave v4.3.2, Jito-Solana v4.3.2-jito, or Harmonic Salsa v4.3.2-harmonic. The transition did not support Firedancer or Frankendancer.
Voting validators now pay a flat Validator Admission Ticket fee of 0.8 SOL per epoch in place of vote-transaction fees. The protocol burns the fee from the vote account. TowerBFT voting previously cost about 1 SOL per epoch.
The charge pays for participation one epoch ahead, so the first deduction at epoch 1064 covers epoch 1065. Operators must maintain at least 0.8 SOL above the vote account's rent-exempt minimum at each admission check. An account that cannot pay leaves its validator unable to vote or produce blocks in the next epoch; funding the identity account does not cover the charge.
Alpenglow's live phase is Votor. Rotor, the later block-distribution upgrade, would replace Turbine's multilayer propagation tree with a single relay layer. Fast leader handoff, planned for Agave 4.4, would let leaders begin building before the parent has finalized.
Anza is also pursuing geographically aware leader handoffs and Quantumglow, a post-quantum research design using hash-based signatures. These follow-on developments have no committed launch dates in Anza's mainnet announcement.
