Anza set the switch for epoch 1064, which the Solana Foundation puts at about 15:00 UTC, with TowerBFT running for the first 5,000 slots and the handoff at slot 459,653,000. Firedancer and Frankendancer are not supported during the migration.
Anza said on October 13 that Alpenglow, the rewrite of Solana's consensus rules, goes live on mainnet-beta on Wednesday, October 21. Its post put the time at about 14:50 UTC. The Solana Foundation's upgrade page places the activation in epoch 1064, which it says starts at approximately 15:00 UTC, and tells operators to track the epoch rather than the clock because epoch start times drift with slot timing.
Anza's post described “18 months of work for a migration that happens in one slot” and said finality drops “from seconds to ~150ms.”
The handoff is not instantaneous for the network as a whole. The feature gate activates at the start of epoch 1064, but the cluster keeps running TowerBFT for the first 5,000 slots of the epoch, which the Foundation describes as about 18 minutes in. Alpenglow consensus takes over at slot 459,653,000. Eighteen minutes spread across 5,000 slots works out to about 216 milliseconds a slot, against a nominal target of 200, which is close to the roughly 16 milliseconds of overhead above target that network-reported block times carried at each earlier step of Solana's slot-time schedule.
Votor is the component activating here. Under TowerBFT, validators accumulated votes on chain across 32 slots before a block became irreversible. Votor has them send votes directly to each other and aggregate them into certificates, and a block finalizes in one round or two. Rotor, the block propagation half of the Alpenglow design that would replace Turbine, is planned for a later release once Votor is adopted and has no schedule.
The Foundation attaches its own caveat to the finality number. It calls 150 milliseconds “an expectation, not a constant: it was measured against the stake distribution at the time of testing, moves as that distribution changes, and is lower when a block finalizes in one round than in two.” The page sets that target against 12.8 seconds today and calls the result 99 percent faster. The 12.8-second baseline is 32 slots at the 400-millisecond slot target Solana ran on when the figure was set. At the 200-millisecond target the same page says the network reached in four stages during October, 32 slots comes to 6.4 seconds. The comparison is drawn against the older slot schedule.
Client support is still the narrow part of the rollout. Validators must run an Agave-based client, meaning Agave, Jito-Solana or Harmonic Salsa, on a release built on Agave 4.3.0, and the Foundation says Firedancer and Frankendancer are not supported during the migration. That is the same restriction that applied when Alpenglow reached the public testnet in September, and it has not been lifted for mainnet.
How much stake that strands is an open question. Solana Compass, reading the migration proposal SIMD-0384, says validators wait for 82 percent of stake to sign a certificate over the genesis block before consensus hands over. From client labels among the 500 largest validators on October 13, it estimated Firedancer-family software at about 15.8 percent of stake, leaving roughly 84 percent, about two points above that threshold before counting any validator that is simply offline. Compass notes that client labels can lag the switches operators have actually made, so the margin is an estimate rather than a measurement.
Operators also have a new per-epoch cost. The Validator Admission Ticket takes a flat 0.8 SOL per epoch from the vote account and burns it, on top of the rent-exempt minimum, and the first charge lands at the start of epoch 1064 to pay for epoch 1065. A validator that does not pay does not vote or produce blocks in the following epoch.
Outside the validator set, the visible change is what happens to vote transactions. They no longer appear in blocks, so transaction counts and TPS readings fall sharply. The Foundation calls that an accounting change rather than a throughput regression and says dashboards need re-baselining, with validator participation moving into the certificates in the block footer. Anza's guidance in September put vote transactions at about 59 percent of all transactions on the network. Compass's figures for October 10 to 12 put votes at roughly 3,060 a second against about 1,780 user transactions, or about 63 percent.
Applications have two smaller adjustments. The confirmed and finalized commitment levels become the same state once Alpenglow is live, and the Foundation says confirmed will be deprecated and removed in a later release; until activation, finalized still means the 12.8-second wait. For detecting the switch, Agave v4.3 adds a getAgGenesisCert call that returns null while the cluster is on TowerBFT and the genesis certificate afterward, and the Foundation advises gating Alpenglow-specific logic on that call rather than on a date or a version string.
On October 14 the Foundation's page still listed the mainnet feature gate as not activated.
