Alpenglow Finality in Numbers: 60%, 80%, 250 ms, 800 ms

Ask five Solana traders how long a transaction takes to become final and you will get five answers, all of them "about a second" and none of them a definition. Until 21 October 2026 "confirmed" meant two-thirds of stake voted on the block at least once, and "finalized" meant 32 blocks were built on top of it — a depth, not a time. A wallet turned the tick green somewhere in between and nobody checked which.

Alpenglow replaced that whole arrangement. Votes stop being transactions, finality becomes a certificate, and every threshold and timer that decides it is a named constant in the validator source. This post is those constants, read from the code, with what each one means for the moment your fill counts.

Six Certificates, Three Percentages

Under Alpenglow a block does not get "confirmed" by accumulating votes over time. Validators sign one of a small set of messages about each slot, the signatures are aggregated (they are BLS signatures, so thousands compress into one), and a certificate exists the moment enough stake has signed the same thing. The thresholds:

Two of these are the ones you care about. A notarize certificate at 60% says "enough of the network has this block and it is well-formed". A finalize certificate at 60% on top of that says it will never be reverted. And if 80% of stake notarizes in the first round, the block is fast-finalized in one step — no second round.

Worth knowing: 60% is lower than TowerBFT's two-thirds because Alpenglow's safety budget is split differently — 20% of stake can be Byzantine and a further 20% can be offline, and the protocol still makes progress. The 82% genesis threshold is derived from that: 38% (TowerBFT's fork-switch threshold) minus the 18% the migration tolerates as malicious.

Two Timers That Decide How Long "Final" Takes

Every timing in Alpenglow hangs off one assumption: that a message crosses the network in at most 250 milliseconds during normal operation. The source calls it DELTA. The second constant, DELTA_TIMEOUT, is 400 ms — the time after a validator sees a parent block become ready before it expects the next leader's first shreds.

Those two add up to the number that matters: a leader who produces nothing is skipped 800 ms after their window should have begun. That figure was 1.4 seconds until 29 June 2026, when the team cut it almost in half. Any explainer quoting 1.4 s is describing a version that no longer exists.

For a healthy leader, the happy path is: block broadcast, 60% notarize within roughly one DELTA, finalize certificate within roughly another. The protocol's own design target is finality in about two network round trips — hundreds of milliseconds, not the roughly seven seconds that 32 confirmations took at the ~215 ms slots mainnet was running when Alpenglow switched on. Whether mainnet hits that depends on real propagation, which is exactly the number the design constants cannot tell you; the first reading we took is in section 05.

What Happens When a Leader Goes Quiet

The part most explainers skip is the failure path, and it is where the 60% numbers earn their keep.

If a validator has already voted in a slot and then sees the block go stale, it may cast a notarize-fallback or a skip vote — but only under rules the code spells out. It is "safe to notarize" a block when at least 40% of stake already notarized it, or when at least 20% did and skip-plus-notarize votes together reach 60%. It is "safe to skip" when skip votes plus every notarize vote except the leading block's reach 40%. A validator may issue at most four notarize-fallback votes per slot; the sigverify stage caps it at three per validator per slot — two ceilings that are often confused when reading the code.

Leader windows stay four slots long. Timers only fire on the first slot of a window, and inside a window the safe-to-notarize check waits on a repair round trip polled every 20 ms.

Then there is standstill. If nothing finalizes for 10 seconds, the timeouts start scaling: each leader window since the standstill multiplies the handover timeout by 1.05, capped at one hour. The network slows itself down deliberately rather than thrashing.

Votes Are Not Transactions Any More, and That Changes the Economics

Under TowerBFT every validator sent a vote transaction roughly once per slot, and paid a fee for it — about 3,000 of mainnet's ~5,000 transactions a second on the afternoon it ended. Under Alpenglow, votes and certificates travel over a dedicated QUIC datagram transport between validators — 1,280-byte datagrams, no streams, a five-second idle timeout — and never enter a block as transactions. The voting service budgets six new packets per slot plus a refresh batch.

Two consequences land on people who never run a validator:

• Vote rewards move to certificates. A validator is paid for a vote only if the leader of the slot eight slots later includes it in a reward certificate, and each slot's inflation reward is split 50/50 between the voter and that leader. A validator with poor connectivity to the next leaders does not just vote late; it goes unpaid.
• The cost of running a validator drops. No vote transactions means no vote fees, which is the mechanism behind the widely quoted claim that the minimum profitable stake falls from a few thousand SOL to a few hundred. The new fixed cost that replaces it — the admission ticket — is a separate post.

The Migration Window, and What Mainnet Actually Did

Alpenglow does not flip on at the activation slot. The code schedules migration 5,000 slots after the feature activates (about 18 minutes at the ~215 ms slots mainnet ran on the day), and during the migration itself the network produces vote-only blocks and reports no commitment level and no root. A bot polling getSignatureStatuses for a "confirmed" fill during that window would see nothing confirm, because nothing is being reported, not because nothing landed.

The genesis certificate that ends the migration needs 82% of stake and lives at a readable on-chain address — a PDA under the Alpenglow feature program. Once it exists, the first Alpenglow epoch begins.

Mainnet, 21 October 2026

We polled a public mainnet RPC every seven seconds from 13:43 to 13:59 UTC, reading the newest slot at each commitment level, alongside its one-minute performance samples. Finalized never stopped advancing: it read 459,652,963 at 13:53:59 and 459,653,029 at 13:54:08, straight across the migration slot. Vote transactions stopped within a few dozen slots of it — the minute containing slot 459,653,000 still carried 2,780 a second, the next minute none. Whatever window without a commitment level the migration produced was shorter than seven seconds.

The finality row needs one adjustment to read honestly. The three slot reads are sequential, so each lands about two slots after the one before it. Corrected for that, finalized trailed the newest slot by about 31 slots before the switch (32 slots at ~215 ms is 6.9 seconds) and by nothing after it, to within the two slots — about 0.4 seconds — that polling can resolve. That is commitment as one RPC reports it, not the end-to-end latency of a transaction you send. The headline TPS fell by almost exactly the vote traffic; everything else carried on at 1,500–3,000 transactions a second either side of the switch.

Alpenglow Finality: Questions People Actually Ask

What to Change, and What Not To

The gate has activated, so none of this is preparation any more. These are the decisions that are live now.

• Stop counting blocks. Thirty-two confirmations is a legacy measure. After Alpenglow the honest answer to "is this final" is a finalize or fast-finalize certificate for the block, and the RPC commitment levels map onto those. Build for the certificate, not the depth.
• Expect two speeds of final. An 80% fast-finalize and a 60%-then-60% slow path are both "final". They differ in how quickly they arrive, not in how safe they are.
• Do not trust 800 ms as a promise. It is the skip timer, not a latency guarantee. Real finality time is propagation plus aggregation, and the only source for that is measurement after activation.
• Watch the gate, not the announcement. The Alpenglow feature is one account on chain. It activated at the epoch 1064 boundary, and the switch it schedules came 5,000 slots later: the gate, not the announcement, tells you which of the two has happened.

This post does not cover the validator side — the 2,000-seat cap, the BLS key requirement and the admission ticket. Those decide who gets to vote at all. For the transaction format that went live on mainnet on 15 September 2026, see Solana's 4,096-byte transactions.

Constants read from the Agave validator source at commit beee69b958: votor-messages/src/certificate.rs, votor/src/common.rs, votor/src/migration.rs and runtime/src/bank/vote_reward.rs. These are design constants, not measured mainnet latencies. The mainnet figures in section 05 and the FAQ were read from the public mainnet RPC (getSlot at each commitment level and getRecentPerformanceSamples) between 12:12 and 14:21 UTC on 21 October 2026.