Alpenglow’s 20+20 Security Model: What It Changes in Institutional Risk Frameworks

TL;DR

• Alpenglow replaces TowerBFT with Votor, targeting protocol finality in 100–150 ms.
• The Alpenglow security model (20+20) separates safety against 20% adversarial stake from liveness with an additional 20% offline stake.
• Faster finality reduces rollback exposure, but actual settlement speed still depends on institutional infrastructure and policies.
• Stake concentration across operators, data centers, and clients remains a key institutional risk.
• Validator due diligence must cover VAT funding, BLS key custody, failover procedures, and independent finality verification.

Alpenglow brings Solana transaction finality down from about 12.8 seconds to a target of 100–150 ms. That significantly shortens the time a transaction remains exposed to a rollback, but it does not change the operational and counterparty risks surrounding settlement.

Alpenglow’s consistency protection is designed to withstand up to 20% adversarial stake, while a separate 20% offline-stake allowance supports continued finalization under stronger network assumptions. For an exchange, custodian or delegation desk, that means less time exposed on each transfer and closer scrutiny of who validates the chain.

How Alpenglow Changes Institutional Risk Assessment

Alpenglow is the consensus upgrade that replaced TowerBFT on Solana mainnet on October 21, 2026, changing how validators vote and how quickly blocks become final. For institutions, those changes reach risks they already assess, from rollback exposure on each transfer to concentration in the validator set.

Under TowerBFT, blocks took about 12.8 seconds to reach finality, and validators cast votes through on-chain transactions that anyone could inspect over RPC. The table compares that system with Alpenglow risk by risk and shows the institutional decision each change affects.

Risk	TowerBFT era	Alpenglow	Decision it affects
Rollback exposure	About 12.8 s to finalized; confirmed was optimistic	100–150 ms target; confirmed and finalized are one state	Deposit crediting, collateral release, DvP leg timing
Adversarial stake that breaks consistency	About 33%	20%	Concentration limits by operator, data center and client
Liveness under outages	Finality stopped above 33.34% unavailable stake	20% adversarial plus 20% offline, checked separately	Halt contingency planning
Finality evidence	On-chain vote transactions, queryable via RPC	BLS certificates in the block footer, outside JSON-RPC as of October 2026	Audit trail, reconciliation
Validator participation	Vote fees; timely vote credits	0.8 SOL VAT per epoch, BLS key, 2,000-seat cap, provable double voting	Validator due diligence, delegation policy
Unchanged	Client bugs, key compromise, venue rules, legal finality, counterparty default	Same	Existing frameworks

The risks in the last row remain just as relevant after the upgrade. Faster finality cannot prevent a compromised signing key or protect an institution when a counterparty fails to deliver.

What Does the 20+20 Model Protect, and What Does It Leave Out?

The 20+20 model protects two properties institutions rely on: finalized blocks remain final, and the chain continues finalizing new ones. However, it does not protect against software bugs or infrastructure outages affecting a large share of validators at once.

The model can maintain consensus with up to 20% adversarial stake and a separate 20% of stake offline. Because the thresholds cover different fault conditions, they must be assessed separately. Treating them as a combined 40% allowance overstates the protocol’s fault tolerance.

• Adversarial (Byzantine) stake: validators holding up to 20% of stake can lie, equivocate or collude, and finalized blocks still stay final. A legitimate operator whose voting key is stolen counts toward this 20%, which puts key custody on the same checklist as protocol design.
• Offline (crash) stake: another 20% can drop out through outages or misconfiguration, and the chain keeps finalizing over the slower 2-round path. This allowance holds only when the network meets Alpenglow’s stronger communication assumptions.

Validators finalize a block by voting on it, and three outcomes are possible:

• Fast path: at least 80% of stake approves the block in 1 round, and it is final.
• Slow path: at least 60% approves it in a first round and 60% confirms it in a second.
• Skip: at least 60% votes to skip the slot, and no block is finalized for it.

These thresholds are high enough that two conflicting blocks could both be certified only if honest validators voted for both. The protocol forbids that, which keeps finality intact while adversarial stake stays at or below 20%.

A slow or congested network can delay finality, and the design’s formal correctness proofs show that delay cannot reverse a block that is already final.

Classic BFT protocols tolerate under 33% faulty stake of any kind. Alpenglow sets a lower adversarial-stake threshold to enable one-round finality, while retaining additional resilience through a separate allowance for offline validators.

Three risks remain outside the model and can disrupt the network regardless of how well the consensus mechanism works:

• Software bugs. When most validators share one codebase, a bug there can affect far more than 20% of stake at once.
• Client-specific halts. Firedancer and Frankendancer were not supported for the migration, so every voting validator operated an Agave-based client during the switch.
• Infrastructure outages. A data center or network provider hosting more than 20% of stake can take that stake offline in one incident.

Protocol Finality vs. Settlement Finality

When can an institution treat a transaction as final?

Under Alpenglow, validators reach protocol finality in about 150 ms. The institution sees that result when its node reports finality, after which its crediting and custody rules determine when the funds become available.

Faster consensus does not automatically accelerate settlement. Venue crediting rules, custodian reconciliation, contract terms and legal finality remain unchanged since October 21, 2026.

Under TowerBFT, confirmed arrived in about 1 slot while finalized took about 12.8 seconds. To avoid that delay, most applications read at confirmed, accepting a small theoretical risk that the block could still be dropped.

Under Votor, a block becomes final as soon as its finalization certificate is issued. As a result, confirmed and finalized now describe the same state. Teams can switch to reading at finalized without adding latency, and will eventually need to as confirmed is removed in a later release.

processed still indicates only that a transaction has executed in a bank. Crediting a deposit at this stage means releasing funds before the network has finalized the block.

The node an institution uses also affects when it observes finality. Unstaked RPC nodes learn of finalization from a later block, adding about 1 block interval, or roughly 200 ms at today’s 200 ms slots.

Location shapes the numbers too. Everstake’s review of post-activation scoring found an active validator in Rotterdam recording 0% fast certificates in the first hours after activation, while a passive node in Frankfurt recorded more than 99%.

Public measurements tell a similar story. An outside 24-hour sample ending October 23, 2026, taken from a public RPC node, recorded a 404 ms median and 765 ms at the 99th percentile, well above the 150 ms protocol target.

Protocol upgrades also create settlement windows of their own. During the Alpenglow migration on October 21, 2026, user transactions stopped landing for one to two slots at the handoff boundary, so operations teams needed a plan for pausing and resubmitting.

Consider an exchange crediting a large SOL deposit. The block may reach finality within 150 ms, but the funds become available only after the exchange’s node reports it, its crediting rules take effect and, where applicable, the custodian reconciles the balance.

These stages involve different parties. Alpenglow changes how quickly transactions reach protocol finality and how soon institutions can observe it. Venue and custodian policies, however, remain outside the protocol’s scope:

Stage	Who decides	What Alpenglow changed
Protocol finality	Solana validators, through Votor certificates	About 12.8 s to a 100–150 ms target
Observed finality	The institution’s RPC provider or node	Adds observer latency; unstaked nodes lag about 1 block
Venue crediting	Exchange or platform rules	Nothing; rules tuned to 12.8 s may be out of date
Custodian reconciliation	Custodian policy	Nothing in protocol; polling intervals may need review
Legal and contractual finality	Contracts, governing law, counsel	Nothing

Atomic settlement programs are where faster finality helps most. Solana DvP settles an asset and its payment in 1 atomic transaction, so faster finality shortens the window in which either leg can be reversed, while the contract still decides when the trade legally counts as settled.

Before changing settlement policy, institutions can work through three questions with counsel:

1. Does each contract define settlement by finalized, a confirmation count or elapsed time?
2. Do venue crediting rules still wait for 32 confirmations or 12.8 seconds, a delay the protocol no longer needs?
3. Which stage releases collateral, and who bears the loss if a later stage reverses?

How Does the 20% Threshold Apply to Stake Concentration?

The shift from a 33% to a 20% adversarial-stake threshold changes how institutions assess validator concentration. They now need a clearer picture of how stake is distributed across operators, infrastructure providers and client software, including where several validators depend on the same entity or technology.

By Operator

According to Fidelity FCAT’s October 16, 2026 report, about 18 validators held more than 33% of stake in Q3 2026. Under the new 20% threshold, just 8 validators are enough to cross that mark: a public validator ranking from November 2026 shows the eighth-largest validator pushing cumulative stake above 20%.

For delegation desks, validator counts alone provide an incomplete picture. Grouping stake by operator and voting-key ownership reveals how much stake is ultimately controlled by the same team, including across multiple vote accounts.

By Data Center

On August 12, 2026, a routing fault at TeraSwitch took 28.83% of staked SOL offline for about 33 minutes. Under TowerBFT, that left the network just 4.51 percentage points below the 33.34% offline-stake threshold that stops finalization.

Under Alpenglow, the same outage would affect finality differently. With nearly 29% of stake offline, validators could no longer form the 80% fast-path quorum.

The remaining 71% could still meet the 60% slow-path threshold in principle. However, the outage would exceed Alpenglow’s 20% offline-stake allowance, taking the network outside the conditions covered by its formal liveness proof.

The concentration risk extends beyond individual outages. As of September 28, 2026, validators hosted on the TeraSwitch network AS20326 held about 29.7% of stake. This exceeds the under-25% concentration limit that the Solana Foundation Delegation Program applies to any single ASN or hosting provider.

This limit applies only to validators receiving Foundation stake through the delegation program. The protocol itself places no cap on network-wide stake concentration, leaving institutions to define and monitor their own limits.

Distributing validators across geographic regions can reduce this exposure, although it may increase latency. This trade-off is also examined in geographic clustering across proof-of-stake networks.

By Client

Client concentration presents a less visible risk because validators running different client implementations may still rely on the same underlying codebase. A study published on October 16, 2026 found that about 63% of stake ran Jito-Solana clients and another 26% ran Harmonic clients. Both derive from the Agave codebase.

A vulnerability in that shared code could therefore affect far more than 20% of stake at once. The 20+20 model does not cover this type of failure, leaving operators and institutions responsible for managing the resulting exposure.

Verifying Finality Independently: Certificates and Audit Records

How can institutions verify transaction finality independently of their RPC providers? Under Alpenglow, finality is recorded in aggregated BLS certificates. As of October 2026, however, the JSON-RPC methods commonly used by back-office systems do not expose these certificates.

Consider an exchange that receives a finalized status for a deposit from its node. Its monitoring system typically accepts that status without checking the underlying certificate, leaving the exchange dependent on its provider’s account of finality.

Under TowerBFT, validators’ votes were recorded on-chain and available through RPC for independent auditing. With Alpenglow, applications requesting finality status must rely on their node’s report until standard RPC provides access to the certificates.

Institutions can still verify finality independently, but doing so requires additional engineering. A leader includes its latest finalization certificate in the block footer, which Geyser plugins can be configured to receive. Anyone with the corresponding votes and validators’ BLS public keys can then verify the certificate independently.

Standard RPC exposes one certificate through getAgGenesisCert: the certificate for the Alpenglow genesis block at slot 459,652,999. This certificate confirms the migration but provides no evidence of finality for subsequent blocks.

Audit and reconciliation teams also need visibility into how each finality record was obtained. Each record should include the observer’s location, stake status, commitment level and timestamp. This allows teams to compare measurements across providers on a consistent basis.

Validator Requirements Institutions Should Review After Alpenglow

Under Alpenglow, validators serving institutions must meet operational requirements that were not part of TowerBFT. These include maintaining VAT funding, protecting BLS keys, preventing double voting during failover and keeping client software current.

VAT Funding

Each admitted validator must fund a 0.8 SOL Validator Admission Ticket (VAT) from its vote account one epoch in advance. The payment is burned. A missed payment directly affects delegators. If the vote account does not hold 0.8 SOL above its rent-exempt minimum at the start of an epoch, the validator cannot vote or produce blocks in the next epoch, and its delegators receive no protocol rewards from it.

Shorter epochs turn this into a daily task. The slot-time change in SIMD-0525, completed on October 9, 2026, brought epochs down to about 24 hours at 200 ms slots. The first full epoch measured 26.2 hours.

BLS Key Custody

Since the VAT gate activated on July 22, 2026, validators without a registered BLS public key cannot participate in consensus. The BLS key is derived from the authorized voter keypair. Whoever controls that keypair therefore controls both, a point custody reviews should account for.

Admission is limited to the 2,000 validators with the highest stake. At activation, 654 validators participated, leaving room under the cap. The limit also sets an upper bound on the active set.

Failover Without Double Voting

Validators need failover procedures that prevent two machines from voting simultaneously. Without them, a recovery attempt can produce conflicting votes and compromise protocol consistency.

Equivocation on mainnet has so far happened by accident, when an operator’s primary and hot spare were both live.

Client Compatibility

Client compatibility is another factor institutions should examine. Voting through the migration required Agave, Jito-Solana or Harmonic Salsa at version 4.3.2, the same minimum the Solana Foundation Delegation Program now applies.

Everstake has been successfully running the Harmonic Firedancer client.

Reward mechanics under Votor are covered in what Alpenglow is and how it works.

What to Ask a Validator After Alpenglow

Institutions can translate these requirements into practical questions for their validators. Good answers come with evidence such as runbooks, monitoring records and past incident reports.

1. How is the VAT balance monitored and topped up before each epoch starts?
2. How are BLS and identity keys custodied, and who can sign with them?
3. How does failover work without a second active node voting?
4. What is the client and version policy, and how are upgrades tested before mainnet?
5. Where are nodes located relative to the largest data-center and ASN concentrations?
6. How is finality observed and reported to clients, and from which locations?
7. How are incidents communicated to delegators, and on what timeline?

Everstake has operated a Solana validator since July 4, 2020, and has historically maintained non-custodial infrastructure across 130+ networks. Institutions can use these 7 questions to assess the Everstake team through an Institutional Staking consultation and compare its answers with their own risk framework.

Institutions looking to stake SOL can partner with Everstake for dedicated validator infrastructure through its Validator-as-a-Service offering. Everstake combines institutional-grade validator performance and operational expertise to support customized staking requirements.

With dedicated infrastructure, institutions retain control over their staking policies while benefiting from reliable validator operations, transparent performance monitoring, reporting, and technical support from an experienced Solana validator operator.

Asset managers and treasuries can also explore sector-specific options.

FAQ

What is the Alpenglow 20+20 security model?

It keeps Solana consistent with up to 20% adversarial stake and keeps it finalizing with an additional 20% of stake offline.

Does Alpenglow tolerate 40% faulty stake?

It tolerates up to 20% adversarial stake for consistency and, under stronger network assumptions, a separate 20% of offline stake for liveness, and the two limits are assessed independently.

Which commitment level should institutions read after Alpenglow?

Institutions can read at finalized, which now arrives as quickly as confirmed did, while confirmed will be removed in a later release.

Can a data-center outage still halt Solana finality?

Yes, an outage that takes more than 40% of stake offline leaves no way to reach the 60% threshold, and any outage above 20% removes the fast path.

Can institutions verify Solana finality without trusting an RPC provider?

Yes, by collecting Votor certificates through Geyser block footer callbacks and checking them against validators’ BLS public keys, since standard JSON-RPC did not expose them as of October 2026.

What happens if a validator cannot pay the VAT?

The validator does not vote or produce blocks in the next epoch, and its delegators receive no protocol rewards for that epoch.