What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The four numbers in Alpenglow’s headline figures are not a speed test or a fee schedule. The 60% and 80% values are stake thresholds that decide when validators’ votes form a valid consensus certificate. The 250 ms and 800 ms values are timing parameters from an independent technical explainer. Solana Foundation’s roughly 150 ms figure is a finality target, not a measured average. Each number answers a different question, so reading them as one latency equation leads to wrong conclusions.
Start with what the percentages measure
Alpenglow is the consensus protocol proposed for Solana in Solana Foundation’s SIMD-0326 proposal. Consensus is the process by which validators agree on which blocks are part of the chain. Validators weigh their votes by stake, meaning the amount of SOL delegated to them. A threshold of 60% therefore means that votes representing 60% of total stake must agree before a certificate exists.
The proposal defines the term this way: “A certificate is a proof that a certain fraction of nodes (by stake) cast a specific type of vote.” A certificate is a protocol state, not a timer. Once enough stake has voted in a given way, the certificate exists regardless of how long that took in wall-clock time.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Figure | What it sets | Kind of value | Source and qualification |
|---|---|---|---|
| 60% | Stake share needed for notarization and finalization certificates | Protocol threshold | SIMD-0326 proposal. It is one part of the slow-finalization path, not the whole path. |
| 80% | Stake share of first-round notarization votes needed for a fast-finalization certificate | Protocol threshold | SIMD-0326 proposal. It enables the fast path; it does not guarantee that every block uses it. |
| 250 ms | Assumed message-crossing time between validators in normal operation (the explainer’s DELTA) |
Design assumption | xroot.dev explainer, September 12, 2026. It is not a Solana Foundation measurement or a network-wide bound. |
| 800 ms | Timer after which validators skip a slot whose leader stays silent | Timeout | xroot.dev explainer, September 12, 2026. It governs failure handling, not transaction finality. |
| About 150 ms | Expected time for a transaction to become final | Finality target | Solana Foundation’s Alpenglow upgrade page, updated September 2026. It is an expectation, not a constant. |
| 12.8 seconds | Finality comparison figure for the current TowerBFT consensus | Official comparison baseline | Solana Foundation’s Alpenglow upgrade page, September 2026. It is a stated comparison, not a claim that every confirmation takes exactly this long. |
How the two finality paths use the thresholds
Alpenglow runs in two voting rounds. In round one, each validator votes either to notarize a specific block or to skip the slot. A validator notarizes if a valid block arrived before its local timeout; otherwise it votes to skip. Votes travel directly between validators rather than through a relay step in the proposal’s description.
#1 Best Overall
Finalization can then happen by one of two routes. The proposal allows a slot to finalize with either certificate type, so the two paths below are alternatives rather than stages of one process.
Fast finalization: 80% in round one
- Validators collect first-round notarization votes for a block.
- If votes representing 80% of stake notarize the same block, a fast-finalization certificate forms.
- The slot is final on that certificate alone. No second round is needed.
Slow finalization: 60% in two rounds
- Round one produces a notarization certificate for the block, which requires votes representing 60% of stake.
- In round two, validators vote to finalize once they have seen enough notarization votes.
- Votes representing 60% of stake in that second round form a slow-finalization certificate.
- The slot finalizes when it holds both a slow-finalization certificate and a notarization certificate.
The proposal also says a finalized block decides earlier undecided slots indirectly. Its ancestors are finalized, and any slots omitted from the chain are skipped. Safety and liveness proofs are attributed in the proposal to a companion white paper, which this article does not reproduce.
250 ms and 800 ms: timing inputs, not a finality clock
The explainer published by xroot.dev on September 12, 2026 uses these two values to illustrate how Alpenglow’s timers behave. They are design inputs for an implementation, and they belong to the protocol’s machinery rather than to any user-facing result.
250 ms: the assumed normal-operation crossing time
The 250 ms figure is the message-crossing time the explainer assumes for normal operation. It is a planning assumption about how quickly a message moves between validators. Real messages take as long as propagation, network conditions and aggregation allow, so it is not a measured average or an upper bound for every network path.
800 ms: the silent-leader skip timer
The 800 ms value is the timer that lets validators give up on a leader who produces nothing. When that timer expires, validators vote to skip the slot and move on. It sets how quickly the chain recovers from a silent leader. It does not set how quickly a transaction becomes final. The explainer states that actual finality depends on propagation and aggregation, so an 800 ms timer and a transaction finalizing in 800 ms are different things.
Where the roughly 150 ms target fits
Solana Foundation’s Alpenglow page states the expectation directly: “The 150ms is how long a transaction takes to become final, not how often blocks are produced.” That sentence separates finality from slot time, which is the interval between block production opportunities. A fast slot time and a fast finality time are different properties, and Alpenglow’s headline claim concerns the second.
Rank #4
The 12.8-second figure on the same page is the comparison the Foundation uses for TowerBFT, the current consensus protocol. It is a stated baseline. Individual confirmations on the current network can differ from it, and the page does not present it as a per-transaction measurement.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The 150 ms target and the 250 ms and 800 ms timing values come from different kinds of sources. The first is a high-level expectation from the Foundation. The other two are parameters from an independent, implementation-focused explainer. Combining them into a single predicted latency would invent a calculation that neither source makes.
Best Value
Rollout status: what the sources establish
- Votor, Alpenglow’s voting component, ships in Agave 4.3 according to the Foundation’s September 2026 page.
- Rotor, the block-data dissemination component, is planned for a later release. The page gives no schedule.
- Alpenglow replaces the consensus layer. Execution, including the SVM, transactions, programs and fees, is unchanged according to the same page.
- The sources above do not establish which clusters have activated Alpenglow. Check the current Solana release and cluster status before relying on it for any network.
Because the Foundation’s page is dated September 2026, anything after that month, including activation on a specific cluster, may already have changed. Confirm the current state directly from the Alpenglow upgrade page before making operational decisions.
Safety and migration claims
The SIMD-0326 proposal describes Alpenglow’s resilience model as reaching consensus while tolerating 20% malicious stake and 20% offline stake. The proposal presents this as a design property. It also acknowledges that a major protocol change makes migration challenging. Neither statement is a guarantee that implementation or deployment will be free of risk.
Reading Alpenglow numbers correctly
Before you quote or compare one of these figures, check four things:
Recommended Free Tools
- Kind of value. Is it a stake threshold, a design assumption, a timeout or a finality target?
- Round count. Does the figure belong to the one-round fast path or the two-round slow path?
- Source. Is it from the protocol proposal, the Foundation’s page or the independent explainer?
- Cluster status. Is the feature live on the network you care about, and in which release?
Using these checks keeps each number on the question it actually answers.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
