Infrastructure

Alpenglow is planned for mainnet on 21 October

Alpenglow is planned for epoch 1064 on 21 October. Triton describes two slots with no user transactions. The preconf window is open.

SOLANA·HUB Editorial

Planned start in epoch 1064

On 13 October, Anza named a date for Alpenglow on mainnet-beta. The switch is planned for Wednesday, 21 October, at the start of epoch 1064. Anza says the migration happens in one slot, after 18 months of work.

Anza puts the time at about 14:50 UTC. Solana Developers names the same time and the same epoch. The Solana Foundation says about 15:00 UTC.

In Berlin that is about 4:50 p.m. to 5:00 p.m. Summer time still applies that day. The Foundation calls the clock time an estimate, because the epoch start drifts with slot timing.

Feature gate SIMD-0384 turns on at the epoch boundary. TowerBFT keeps running for another 5,000 slots, about 18 minutes. Votor takes over at slot 459,653,000.

During that window, getAgGenesisCert still returns null. A query of the public mainnet RPC on 13 October showed epoch 1056. The same query returned null for getAgGenesisCert.

The Foundation says finality takes about 12.8 seconds today. Alpenglow targets roughly 150 milliseconds. That figure is an expectation, not a fixed value.

The Foundation says it was measured against the stake distribution at the time of testing, and that it moves when the distribution changes. A block that finalizes in one round lands under it. A block that needs two rounds lands over it.

Rotor is the second phase and is meant to replace Turbine. The Foundation places it in a later release, once Votor is in use. The page does not set a calendar date.

The finished testnet migration is in the activation report. The overview page, which had no mainnet date, is in the report on that page. Jito’s notes on clients and the BAM maintenance window are in the 10 October report.

Validators and the VAT

Nothing changes for users when they sign, send, or approve a transaction. Wallets and apps keep working as they do now. The Foundation says the SVM, the transaction format, and fees stay the same.

Before epoch 1064, validators need a client built on Agave 4.3.0. The Foundation names Agave, Jito-Solana, and Harmonic Salsa. Firedancer and Frankendancer are not supported during the migration.

Firedancer v26.10.2, published on 14 October, supports Alpenglow in operation. It does not support the switch off TowerBFT. The report on v26.10.2 sums up the release notes.

The new charge is the validator admission ticket, VAT, under SIMD-0357. It is 0.8 SOL per epoch. The vote account pays it, and the protocol burns it.

The 0.8 SOL sits above the rent-exempt minimum. The first charge is at the start of epoch 1064 and covers participation in epoch 1065. If the balance is short, the validator does not vote or produce blocks in the following epoch.

ashwin.sol wrote on X that the vote account should hold at least 0.83 SOL, to pay the VAT and stay rent-exempt. The Foundation and the Anza docs say 0.8 SOL above the rent-exempt minimum.

Under TowerBFT, the Foundation says votes cost about 1 SOL per epoch, paid from the identity account. Under Alpenglow, votes are no longer transactions. The VAT from the vote account takes that place.

Blocks, finality, and timestamps

Vote transactions leave the blocks. Metrics that counted them drop. The number of user transactions does not change because of that.

After the switch, confirmed and finalized mean the same state. Until then, finalized is still the wait of about 12.8 seconds. The Foundation says new code should use finalized only after the switch.

Proof of History no longer paces block production. Tick entries leave the shred stream. The leader sets Clock.unix_timestamp, instead of the median of vote timestamps.

From Agave 4.3, Geyser adds a bank_id field. A slot can carry more than one candidate block. A pipeline that buffers on the slot number alone mixes those candidates.

Two slots without user transactions

On 14 October, Triton One describes on X what happens in the slots on switch day. Triton runs RPC and streaming. The times are that provider’s figures.

The start is still epoch 1064 on 21 October. Triton puts the clock at about 14:50 UTC. After that, 5,000 slots run, about 17 minutes, with nothing changing for users. The Foundation puts the same countdown at about 18 minutes and the clock at about 15:00 UTC.

User transactions then pause for two slots, Triton says, about 400 milliseconds. Validators wait until 82 percent of stake has voted. Once that lands, Triton says Alpenglow is live. Blocks then finalize in about 150 milliseconds.

On its migration page, Anza describes blocks at the boundary that carry only votes. As a rule, one more TowerBFT block follows. Anza explains that with a block usually receiving more than 95 percent of stake. The handoff takes hundreds of milliseconds, Anza says.

Triton says the network does not reject transactions sent in those slots. A retry uses backoff and a fresh blockhash taken at confirmed. Code should use finalized only once getAgGenesisCert returns a certificate.

Anything that reached confirmed before the gap stays as it was, Triton says. The blocks in the gap hold only votes. The Triton blog, updated on 14 October, gives the same figure of two slots.

Harmonic’s block packing and preconfs pause for about ten minutes, Triton says. Jito BAM preconfs pause in that window as well. During the pause, the break is only from the preconf streams. Triton says there is no billing while they are off.

Anyone streaming or indexing blocks installs the Alpenglow release of Yellowstone gRPC before the day. Only what reaches confirmed is kept. Without vote transactions, per-block counts and TPS fall. User activity stays the same.

Note: This is reporting, not investment advice.

What to watch

  • Whether epoch 1064 starts on 21 October inside the stated window
  • Whether the gap lasts two slots, as Triton writes, or typically one more block, as Anza writes
  • The exact window for the Harmonic and Jito BAM preconf pause
  • Whether mainnet finality lands near 150 milliseconds
  • Whether the Foundation clears Firedancer and Frankendancer for the migration
  • Whether Rotor gets a date

Sources

#alpenglow #mainnet #validator #infrastructure