Originally published on xroot.dev.
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. Today "confirmed" means two-thirds of stake voted on the block at least once, and "finalized" means 32 blocks were built on top of it — a depth, not a time. A wallet turns the tick green somewhere in between and nobody checks which.
Alpenglow replaces 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.
One thing first: these are the numbers the protocol is built to, not numbers measured on mainnet. The gate that switches Alpenglow on had not activated on mainnet when this was written. Treat every millisecond below as a design target until the tracker says otherwise.
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:
Notarize — 60% of stake
Notarize fallback — 60%
Skip — 60%
Finalize — 60%
Fast finalize — 80%
Genesis (the migration certificate) — 82%
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 today'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% (today'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 twelve-plus seconds that 32 confirmations take today. Whether mainnet hits that depends on real propagation, which is exactly the number the design constants cannot tell you.
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
Today every validator sends a vote transaction roughly once per slot, and pays a fee for it. 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, Which Nobody Will Warn You About
Alpenglow does not flip on at the activation slot. The code schedules migration 5,000 slots after the feature activates (about 33 minutes at today's slot time), 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 will 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.
If you run anything that credits deposits, releases goods, or fires on confirmation, put a hold on that logic for the migration window. It is the single most predictable outage in the upgrade and it is on a schedule.
Alpenglow Finality: Questions People Actually Ask
How fast is finality under Alpenglow?
The design target is two network round trips: a 60% notarize certificate, then a 60% finalize certificate, or a single 80% fast-finalize. The protocol assumes 250 ms per message and skips a silent leader after 800 ms. Real mainnet latency is a measurement, not a constant.
What replaces “confirmed” and “finalized” under Alpenglow?
Certificates. A block is final when a finalize (60%) or fast-finalize (80%) certificate exists for it. RPC commitment levels map onto those certificates rather than onto vote depth.
Is Alpenglow live on Solana mainnet?
It is gated by one feature account (alpenglow). Check a feature-gate tracker for the state on each cluster; the gate activates at an epoch boundary after 95% of stake adopts it, then migration begins 5,000 slots later.
Will my transactions behave differently during the Alpenglow migration?
For roughly 5,000 slots after activation the network produces vote-only blocks and reports no commitment level or root. Anything that waits for “confirmed” should pause during that window.
What to Change, and What Not To
Nothing below needs doing before the gate activates. Everything below needs deciding before it does.
- 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 will 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, and it activates at an epoch boundary after 95% of stake has adopted it.
— Watch the Gate, Not the Announcement —
The Alpenglow feature is one account on chain.
The upgrades tracker reads the feature-gate accounts from the chain every minute and shows which cluster has which gate live. That is the page to check the morning you think it has happened — not a blog post, and not an announcement.
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 arriving alongside it, 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.
