Solana’s Near-Freeze Exposes a Hidden Validator Risk

Solana did not go down on August 12.

That is what makes the incident interesting.

A routing problem at infrastructure provider TeraSwitch disconnected enough validators to push roughly 28.8% of Solana’s staked SOL offline at nearly the same time.

Blocks kept being produced.

Transactions kept landing.

The public Solana status page still showed the network as operational.

But underneath that apparently normal uptime, Solana was only a few percentage points away from a much more serious consensus event.

The network generally needs more than two-thirds of stake participating to keep finalizing new blocks. Once more than roughly one-third becomes unavailable, that supermajority can no longer be reached normally.

August 12 stopped just short of that line.

The incident therefore exposed a form of blockchain centralization that ordinary validator counts can miss.

A network can have many independent validators.

Those validators can be spread across several countries.

They can run different businesses.

Yet if too much stake ultimately depends on the same hosting company, network provider or routing infrastructure, one failure underneath them can behave like one enormous validator outage.

That is the hidden risk.

Decentralized ownership does not automatically mean decentralized infrastructure.

---

Key Takeaways

• A routing problem affecting TeraSwitch infrastructure disrupted Solana validators on August 12, 2026.
• Approximately 28.8% of staked SOL temporarily lost connectivity.
• Around 90 validators were affected.
• Solana did not experience a full network outage. Blocks continued to be produced and transactions continued to land.
• The incident remained below Solana’s roughly 33.33% offline-stake threshold, beyond which the remaining network would normally be unable to reach the two-thirds vote required for finality.
• Metrika measured skipped slots rising above 32% during the disruption.
• Finality degraded much more severely than the network’s 100% uptime figure suggested.
• For part of the incident, newly produced blocks were not reaching finality at their normal pace, with delayed blocks later taking roughly 1,600 seconds on average to finalize compared with a normal baseline around 13 seconds.
• The event originated in ordinary internet-routing infrastructure rather than a Solana consensus bug or smart-contract exploit.
• Geographic validator distribution did not fully protect the network because affected infrastructure dependencies extended across several locations.
• Solana’s own 2025 network-health reporting showed TeraSwitch hosting roughly 24.3% of network stake at the time, illustrating that hosting concentration was already measurable.
• Validator count alone is therefore a weak measure of decentralization.
• Stake distribution, hosting-provider concentration, network routing, failover design and software-client diversity all describe different forms of resilience.
• For exchanges, bridges and institutions, time to finality can be a more meaningful operational metric than whether the blockchain technically remains online.
• The incident should be treated as a near miss, not as proof that Solana suffered another full outage.

---

What Happened

At roughly 03:43 UTC on August 12, a routing problem began affecting infrastructure associated with TeraSwitch.

Solana Foundation later described the incident as a routing issue involving TeraSwitch’s Frankfurt infrastructure, where several Solana validators were hosted.

Independent monitoring by Metrika found the impact extended much further.

A bad internet route originating from TeraSwitch infrastructure propagated across validator connectivity associated with locations including:

• Frankfurt
• London
• Amsterdam
• Singapore
• Tokyo

Around 90 validators became unreachable.

Together, they represented approximately 28.8% of Solana’s active stake.

One affected network operator alone accounted for more than one-quarter of staked SOL in Metrika’s analysis.

That is what transformed an infrastructure problem into a consensus risk.

If the same number of tiny validators disappeared, Solana might barely notice.

Consensus is not weighted by the number of validator machines.

It is weighted by stake.

---

What Happened To Solana On August 12

Metric	Observed Impact	Why It Matters
Affected Stake	About 28.8% of staked SOL temporarily went offline	Solana remained only a few percentage points away from the threshold where finality would stop
Validators	Around 90 validators lost connectivity	Validator count alone understated the impact because stake is unevenly distributed
Block Production	Continued throughout the incident	The chain did not experience a conventional full outage
Skipped Slots	Rose above 32% during the disruption	Offline scheduled leaders could not produce their assigned blocks
Finality	New finalizations were severely delayed during part of the event	Transactions could land before users received the usual strong settlement assurance
Recovery	Connectivity returned after the routing problem was corrected	The network recovered without crossing the consensus halt threshold

---

Solana Did Not Have A Full Outage

This distinction needs to stay clear.

Solana’s blockchain continued producing blocks throughout the incident.

The official status page did not record mainnet downtime on August 12.

Solana Foundation’s own August 13 changelog explicitly says:

the issue did not result in network downtime.

That is technically accurate.

It is also incomplete if used as the only description of the event.

A blockchain can remain online while operating much closer to its consensus limits than users realize.

During the August disruption:

• many validator votes disappeared
• skipped slots rose sharply
• transaction throughput fell
• finality slowed dramatically

The network was alive.

Its safety margin was much smaller.

Those are different conditions.

---

Uptime And Finality Are Not The Same Thing

A website is usually either reachable or unreachable.

Blockchains have more layers.

One useful distinction is between:

block production

and

finality.

Block production means validators are continuing to create blocks containing transactions.

Finality is a stronger statement.

It means enough consensus participants have agreed on the chain that the block is considered effectively irreversible under the protocol’s normal assumptions.

A transaction can therefore appear in a block before it reaches the strongest settlement state.

Most of the time, the gap is small enough that ordinary users barely notice.

On August 12, it was not.

Metrika’s monitoring showed a period of roughly half an hour during which no newly observed blocks reached finality.

When the backlog began clearing, affected blocks were taking around 1,600 seconds on average to reach finality, compared with a normal baseline around 13 seconds.

That is why saying only:

Solana stayed online

misses the most important operational effect.

---

Why One-Third Of Stake Matters

Solana’s consensus relies on stake-weighted voting.

Validators do not all have equal influence.

A validator representing more delegated SOL carries more voting weight than one representing very little stake.

Under the consensus model operating during the August incident, finalization requires votes representing more than two-thirds of stake.

That creates an important boundary.

If slightly less than one-third of stake disappears, the remaining validators can still form the required supermajority.

If more than one-third disappears, they cannot.

The online validators may still know which chain they prefer.

Some blocks may still be produced.

But normal finality cannot progress because the mathematical voting threshold is unavailable.

---

Why Solana's One-Third Threshold Matters

Network Condition	Consensus Effect	Practical Meaning
Less Than One-Third Offline	More than two-thirds of stake can continue voting	The network can continue reaching finality
Around One-Third Offline	The safety margin becomes extremely thin	Finality can slow and operational risk rises sharply
More Than One-Third Offline	The remaining online stake cannot reach the normal supermajority threshold	New blocks may still appear, but the network cannot normally finalize them
More Than Two-Thirds Malicious	A fundamentally different consensus-security failure	This is not what happened during the August routing incident

---

Solana Came Within About 4.5 Percentage Points

Metrika measured the affected stake at 28.83%.

The relevant consensus boundary was approximately 33.34%.

That left around:

4.5 percentage points of stake

between the real incident and a much more serious finality failure.

Metrika estimated the gap at roughly another 20 million staked SOL.

That does not mean a full halt was inevitable.

The network remained on the safe side of the threshold.

Connectivity began recovering.

But it shows how little additional correlated failure would have been required to change the outcome.

Another mid-sized infrastructure dependency failing at the same moment could have turned a routing incident into a network-wide finality event.

That is why this deserves attention even though nothing fully stopped.

Near misses reveal system limits before a catastrophic failure forces everyone to notice them.

---

What Would Have Happened Above One-Third?

The phrase Solana would have frozen needs some nuance.

Crossing the one-third unavailable-stake threshold does not necessarily mean every validator computer shuts down.

It means the online stake no longer has enough voting power to normally finalize new blocks.

Some block production could continue for a period.

Users might still see transactions.

But the network would lose the normal consensus assurance that those blocks had become finalized.

That creates a very different operating environment.

Exchanges may stop crediting deposits.

Bridges may wait.

Institutional settlement can pause.

Applications depending on finality may become cautious.

Eventually, coordinated validator recovery may be needed before normal consensus resumes.

A blockchain can therefore become economically unusable for some activities before its block-production graph reaches zero.

---

Block Production Also Degraded

Although blocks continued, production was far from normal.

Solana uses a leader schedule.

Validators know in advance which slots they are expected to lead.

If the scheduled leader is offline, that slot can be skipped.

During the August 12 incident, Metrika measured the skipped-slot rate rising above 32%, compared with a normal rate well below 1%.

That closely matched the amount of stake affected.

This makes intuitive sense.

A significant portion of scheduled producers was temporarily unreachable.

The chain kept moving because enough other leaders remained online.

But nearly one-third of scheduled production capacity suddenly becoming unreliable is not an ordinary operating condition.

---

User Transactions Fell Too

The disruption also reached transaction throughput.

Metrika separated ordinary user activity from validator vote transactions and found that true transactions per block fell substantially during the worst part of the incident.

Typical levels of roughly 800–1,000 non-vote transactions per block fell to around 190 at the trough.

Network-wide true transactions per second dropped from approximately 1,100–1,300 to below 300.

Again, this was not zero.

Solana still processed transactions.

But the decline reinforces the same point.

A blockchain can maintain nominal uptime while delivering significantly degraded service.

That distinction matters for how crypto infrastructure should be monitored.

---

Why The Status Page Still Showed 100% Uptime

Solana’s public status page reports no downtime for August 12.

That does not contradict the validator data.

It demonstrates what the uptime metric is measuring.

If the definition is:

Did mainnet stop producing blocks?

then uptime remained 100%.

If the question is:

Was consensus behaving normally?

the answer is different.

For infrastructure operators, those are separate metrics.

A status page can correctly show a blockchain as operational while:

• finality slows
• validators disappear
• blocks are skipped
• transaction throughput drops

This is not unique to Solana.

It is a general problem with reducing blockchain health to a binary green or red indicator.

---

Finality Is The More Important Metric For Settlement

Suppose a user sends $20 between wallets.

A short finality delay may be inconvenient but economically minor.

Now suppose a financial institution moves $200 million of collateral.

The relevant question is not merely:

Did the transaction appear in a block?

It is:

When can we safely treat the transfer as irreversible?

The same applies to:

• exchange deposits
• bridge settlement
• stablecoin redemptions
• liquidations
• tokenized securities
• institutional collateral

That makes finality an operational boundary.

A chain can be online but not sufficiently settled for the next financial action to proceed.

As Solana attracts more institutional and real-world asset activity, that distinction becomes increasingly important.

TrendCrypt previously examined Solana’s expansion beyond purely speculative crypto activity in Solana’s RWA growth and its move beyond speculation.

Institutional usage makes resilience metrics more—not less—important.

---

Why Different Solana Users Care About Finality

Activity	What Can Still Work	Why Finality Matters
Ordinary Wallet Transfer	Transaction may still appear and receive confirmations	Users should distinguish inclusion from stronger finality
Exchange Deposit	Exchange may wait for its own confirmation or finality policy	Deposit crediting can slow even if blocks continue
Bridge Transfer	Bridge may depend on finalized state before releasing assets elsewhere	Finality delay can turn into cross-chain settlement delay
DeFi Liquidation	Positions and oracle-sensitive actions continue under degraded conditions	Timing uncertainty can become economically important
Institutional Settlement	Collateral or payment workflows may require irreversible settlement	Uptime alone is not an adequate operational-risk metric

---

The Failure Was Underneath Solana

The August incident did not begin with a broken Solana smart contract.

It was not an exploit of validator consensus code.

It was not a malicious governance action.

The immediate cause was network routing.

That distinction is important because blockchain security discussions often concentrate on protocol-level threats:

• consensus bugs
• exploits
• malicious validators
• client vulnerabilities
• cryptographic failures

Yet every blockchain runs on physical and internet infrastructure.

Validators still need:

• servers
• power
• data centers
• networking
• internet routes
• upstream providers

A blockchain can decentralize consensus without eliminating dependence on the ordinary internet.

August 12 showed how those layers interact.

---

Many Validators Can Share One Failure Domain

Imagine 100 validators.

On paper, that sounds more decentralized than 10 validators.

Now imagine 60 of the 100 are located inside the same data center.

One power failure can remove 60% of them simultaneously.

The network has 100 validator identities.

Operationally, it has one enormous failure domain.

The same problem can occur more subtly with:

• hosting companies
• cloud providers
• internet carriers
• autonomous systems
• regional routing
• shared backup infrastructure

Validator identities describe consensus participants.

They do not automatically describe infrastructure independence.

That is the central lesson of the Solana near miss.

---

Blockchain Decentralization Has More Than One Layer

Layer	What It Measures	What Validator Count Can Miss
Validator Operator	Who controls and runs the validator	Different operators can still depend on the same infrastructure
Stake Distribution	How much SOL is delegated across validators	A small number of heavily staked validators can matter more than many small validators
Hosting Provider	Where validator hardware is physically or commercially hosted	Independent validators can share the same data-center company
Network Provider	Which routing and connectivity infrastructure validators depend on	A networking fault can affect otherwise independent machines simultaneously
Geographic Distribution	Where validators are located	Different cities do not guarantee independent network paths
Client Diversity	Which validator software implementations are used	Protects against one class of common failure but not shared hosting or routing faults

---

Hosting Concentration Was Already Visible

The August incident did not reveal TeraSwitch concentration from nowhere.

Solana Foundation’s June 2025 Network Health Report showed validators operating across more than 100 data-center providers.

That sounds highly distributed.

But the stake distribution was much more concentrated than the provider count.

At that time:

• TeraSwitch: approximately 24.28% of stake
• Latitude.sh: approximately 21.42%
• AWS: approximately 5.98%
• Cherry Servers: approximately 5.24%
• OVH: approximately 4.22%

So the two largest reported hosting providers together represented close to half of staked SOL.

The Foundation’s report was transparent about the data.

The August 2026 incident demonstrated why the metric matters.

A provider does not need to control validators maliciously.

Its infrastructure simply needs to fail in a correlated way.

---

Infrastructure Concentration Is Not The Same As Validator Ownership

This distinction also matters.

Saying that a hosting provider supports 25% of stake does not mean that company owns or controls 25% of SOL.

Different validator operators can independently choose the same provider.

They can have:

• different owners
• different staking customers
• different software
• different operational teams

Consensus ownership may be decentralized.

Infrastructure dependence can still be concentrated.

That is why a network can look healthy under one decentralization metric and vulnerable under another.

Both observations can be true at the same time.

---

Geographic Diversity Did Not Fully Save The Network

One intuitive solution is to put validators in many countries.

That is useful.

It is not enough.

Metrika’s incident analysis says the routing problem propagated across infrastructure associated with several cities on different continents.

This demonstrates a subtle point about internet architecture.

Two servers can be thousands of kilometers apart while depending on:

• the same company
• the same autonomous system
• common routing configuration
• shared backbone infrastructure

Physical distance does not guarantee failure independence.

A validator in Europe and a validator in Asia can still disappear for the same networking reason.

---

Autonomous Systems Matter More Than Most Users Know

Internet routing is organized partly around autonomous systems, or ASes.

An autonomous system represents a set of networks operated under a common routing policy and identified by an Autonomous System Number.

For blockchain resilience, this can matter because validators using different physical machines may still depend on the same network operator.

Solana Foundation has tracked autonomous-system concentration for years.

Its earlier validator-health reporting explicitly warned that a single ASN can span multiple geographic locations.

That is almost exactly the class of hidden dependency highlighted by the August event.

A map full of validator dots can look geographically diverse.

The routing graph underneath it can be much less diverse.

---

Stake Concentration Makes Infrastructure Failures More Important

If consensus were based only on validator count, 90 validators disappearing would have one meaning.

In proof-of-stake consensus, the stake assigned to those validators matters more.

Suppose 90 validators control 2% of stake.

The network barely notices.

Suppose 90 validators control 29%.

The network approaches its finality threshold.

This is why stakers influence resilience.

Where SOL is delegated changes the weight attached to each validator and indirectly changes the importance of the infrastructure supporting that validator.

Delegating to another validator with the same hosting dependency may improve operator diversity without improving infrastructure diversity.

That makes decentralization harder to measure—and more important to measure correctly.

---

Solana Has Been Working On Validator Diversity

The near miss should not be interpreted as evidence that Solana Foundation has ignored decentralization.

The Foundation has spent years changing delegation programs and encouraging broader validator participation.

Its January 2026 Delegation Program report showed Foundation-delegated stake falling substantially as externally delegated SOL increased.

The Foundation said its share through the program had fallen from roughly 44.4% near the program’s early period to about 5.9% by November 2025.

That is meaningful progress in one dimension.

It reduces dependence on Foundation-controlled delegation.

But August 12 demonstrates why decentralization work cannot stop at:

Who delegated the stake?

The next question is:

Where does the validator receiving that stake actually run?

---

Independent Validators Can Choose The Same Best Provider

Infrastructure concentration does not necessarily happen because someone designs the network badly.

Economic incentives can create it naturally.

Solana validators have demanding hardware and bandwidth requirements.

Operators look for providers offering:

• strong networking
• bare-metal servers
• low latency
• suitable CPUs
• reliable connectivity
• competitive pricing

If one provider offers particularly good infrastructure, many independent operators can rationally choose it.

Each individual decision makes sense.

Collectively, they create concentration.

This is a common decentralization problem.

Centralization can emerge from optimization rather than coercion.

---

Solana’s Performance Goals Can Make This Harder

Solana explicitly prioritizes high throughput and low latency.

That creates stricter infrastructure requirements than slower networks can tolerate.

The Foundation itself wrote in June 2026 that high-performance validators increasingly benefit from bare-metal hardware and strong networking as Solana pushes toward higher compute limits.

That is important context.

Performance is not free.

A network that demands very capable hardware can reduce the number of infrastructure environments where validators operate efficiently.

That does not automatically make the blockchain centralized.

But it creates an economic pressure toward specialized providers.

The faster Solana becomes, the more important infrastructure diversity becomes.

---

Decentralization And Performance Can Pull In Opposite Directions

A hypothetical blockchain can maximize hardware accessibility by allowing validators to run on ordinary laptops.

That can encourage broad participation.

It may also limit throughput.

Another blockchain can demand high-performance servers and extremely fast networks.

That can process much more activity.

But fewer providers may offer the required environment.

Solana sits closer to the second model.

Its design makes validator infrastructure a serious engineering operation.

That trade-off does not have a simple right answer.

The important part is recognizing it.

Performance metrics should not be discussed separately from the infrastructure needed to achieve them.

---

Failover Was Another Weak Point

Redundant systems are supposed to prevent one failure from removing a validator completely.

A validator operator can maintain backup infrastructure ready to take over.

Yet Metrika found that many affected validators’ backup systems did not successfully switch during the August incident.

That introduces another important distinction:

having redundancy

and

having independent redundancy

are not the same thing.

A primary validator and backup validator can both fail if they depend on the same:

• hosting provider
• autonomous system
• network configuration
• credentials
• operational process

A backup also does nothing if failover procedures are not tested enough to work during a real incident.

---

Redundancy Needs Different Failure Domains

A useful backup should fail differently from the primary system.

If the primary validator runs in Frankfurt through Provider A, an effective backup might use:

• another provider
• another network
• another region
• independently tested routing

Simply renting another server in the same environment may protect against a hardware failure.

It does little against a provider-wide networking event.

This principle is ordinary infrastructure engineering.

Blockchains do not escape it because consensus is decentralized.

In fact, proof-of-stake networks need to think about it at network scale.

Hundreds of individually sensible backup plans can still share one collective weakness.

---

The Nakamoto Coefficient Does Not Tell The Whole Story

Blockchain decentralization is often summarized using the Nakamoto coefficient.

The basic idea is to ask how many independent entities would need to cooperate or fail before they could disrupt the network.

That is useful.

It depends heavily on what counts as an independent entity.

If the calculation looks only at validator operators, it may miss shared:

• hosting
• cloud infrastructure
• routing
• client software

The August 12 incident demonstrates why the definition matters.

Dozens of validators can be independent at the ownership layer while behaving like one correlated group during an infrastructure outage.

A more useful decentralization assessment therefore needs several coefficients, not one headline number.

---

Client Diversity Solves A Different Problem

Solana has also been working toward broader validator-client diversity through Firedancer and related implementations.

That is important for resilience.

If every validator runs the same software and one critical bug affects that client, the whole network can experience correlated failure.

Multiple independent clients reduce that risk.

But software diversity does not solve routing concentration.

A Firedancer validator and an Agave validator can both disappear if the network path underneath them fails.

The same applies in reverse.

Perfect hosting diversity would not protect against a bug shared by every validator client.

Resilience needs multiple independent layers.

---

Solana’s Coming Alpenglow Upgrade Changes Consensus Again

There is another reason the August event is timely.

Solana is preparing to activate Alpenglow, its next-generation consensus system.

The Foundation says the BLS public-key and Validator Admission Ticket prerequisites are already live, while the main Alpenglow consensus switch is expected with Agave 4.3.

Alpenglow is designed to bring substantially faster finality, with the Foundation targeting roughly 150 milliseconds under normal conditions.

That would be an enormous performance change.

It does not make infrastructure concentration irrelevant.

A faster consensus mechanism still needs validators to remain connected.

In some respects, the more financial activity relies on extremely fast finality, the more visible unusual delays become.

The consensus algorithm can improve.

The network underneath it still matters.

---

A 150 Millisecond Network Still Depends On The Internet

This is an important reality check for blockchain performance.

Protocol engineers can optimize:

• voting
• block propagation
• transaction scheduling
• execution
• consensus messages

Eventually, packets still move through real networks.

Routers fail.

Fiber breaks.

Configuration mistakes happen.

Data centers lose connectivity.

BGP routes propagate incorrectly.

The physical internet becomes part of the blockchain’s effective security boundary.

This is true for every distributed system.

High-performance blockchains simply operate closer to those infrastructure limits.

---

The Incident Was Not A Solana Exploit

Security headlines can easily make the August event sound like an attack.

There is currently no evidence that someone exploited Solana’s protocol to deliberately remove 29% of stake.

The reported cause was an infrastructure-routing failure.

That matters for risk classification.

A blockchain can face:

adversarial risk

someone actively attacks it.

It can also face:

operational risk

ordinary infrastructure breaks.

Financial systems need to withstand both.

Operational failures can sometimes be more difficult to predict because nobody needs an incentive to cause them.

One configuration error can be enough.

---

Near Misses Are Useful Security Data

Organizations routinely study failures that almost happened.

A plane does not need to crash before aviation investigators care about a dangerous incident.

A bank does not need to fail before regulators examine a liquidity near miss.

Blockchains should use the same logic.

Nothing fully halted on Solana.

That is good.

It also means the event provides unusually useful information at lower cost.

The network effectively ran a real-world stress test.

It revealed:

• how much stake shared one failure domain
• how finality behaved
• how quickly throughput degraded
• whether failover worked
• how fast infrastructure recovered

Those signals can be used before a larger incident forces the same lesson.

---

A Status Page Can Create False Comfort

For ordinary users, the natural question is:

Is Solana up?

For serious infrastructure monitoring, that is too simple.

Metrika’s analysis found several signals moving dramatically while headline uptime remained unchanged.

---

Why Solana Uptime Alone Missed The Incident

Metric	What It Measures	What It Revealed Or Missed
Status / Uptime	Did blocks continue to be produced?	Can miss serious degradation when the chain technically remains online
Votes Per Block	How much validator participation is reaching consensus?	Shows how close the network is moving toward its finality threshold
Skipped Slot Rate	How often scheduled leaders fail to produce blocks?	Makes validator connectivity failures visible
Finalization Time	How long until transactions reach strong settlement?	More useful than uptime for institutions moving collateral or value
True TPS	How much non-vote user activity is being processed?	Shows whether users are experiencing meaningful degradation

---

Institutions Need More Than A Green Status Indicator

If Solana is used mainly for speculative trading, temporary degradation is one kind of problem.

If it increasingly supports:

• tokenized assets
• payment settlement
• stablecoins
• institutional collateral
• funds

the operational expectations change.

A financial institution may have internal rules specifying when an asset transfer is considered final.

Its risk system may need to know:

• current validator participation
• finalization delay
• skipped-slot rate
• congestion
• client health

A public “Operational” badge cannot replace that monitoring.

This applies beyond Solana.

As public blockchains become financial infrastructure, institutions will increasingly monitor them like infrastructure rather than like websites.

---

What A Genuine Finality Halt Could Affect

If enough stake were unavailable to halt finalization, different applications could respond differently.

A wallet might still show a recent transaction.

An exchange might stop crediting it.

A bridge might refuse to release corresponding assets.

A DeFi protocol may continue processing activity on blocks whose settlement has not reached the expected confidence level.

Infrastructure providers may temporarily disagree about what commitment level is safe enough.

This creates operational complexity even if the network eventually recovers without loss.

The risk is not necessarily that transactions instantly disappear.

It is that everyone becomes less certain about when they can safely act on them.

---

Bridges Are Especially Sensitive

Cross-chain bridges depend on one blockchain making statements another system is willing to trust.

Suppose assets are locked on Solana and corresponding assets are released on another chain.

The bridge needs a settlement rule.

Release too early and a chain reorganization can create mismatched assets.

Wait for stronger finality and the bridge becomes safer but slower.

During a finality disruption, that trade-off becomes visible.

A blockchain can continue producing activity while cross-chain systems intentionally pause.

This is why underlying consensus health can affect applications that appear far removed from validator infrastructure.

---

Exchanges Can Add Their Own Safety Margin

Centralized exchanges do not need to treat every blockchain commitment level identically.

They can require additional confirmations or wait for stronger finality before crediting deposits.

That is one reason users sometimes experience delayed deposits even when block explorers show a successful transaction.

During an unusual consensus event, exchanges can become more conservative.

This can look like an exchange problem.

The underlying reason may be blockchain settlement risk.

Users should therefore distinguish:

transaction broadcast

from

transaction included

from

transaction finalized

from

exchange credited.

Those are separate stages.

---

Infrastructure Risk Is A Security Risk

Crypto security is often framed around theft.

Did someone lose money?

Was a smart contract hacked?

Were private keys exposed?

Operational resilience is another security property.

A network intended to settle value must remain available and predictable enough that users can know when transactions are final.

A routing configuration can therefore matter to blockchain security even when nobody steals a token.

Security includes:

• integrity
• availability
• resilience

The Solana incident primarily tested the last two.

---

Hidden Infrastructure Failure Domains

Failure Domain	How Concentration Appears	What Can Go Wrong
Single Data Center	Many validators occupy the same physical facility	Power, cooling or local networking problems can affect them together
Single Hosting Provider	Validators across regions use the same infrastructure company	A provider-wide configuration or routing problem can cross geographic boundaries
Shared Autonomous System	Large amounts of stake depend on the same network routing domain	A routing failure can disconnect supposedly separate validators simultaneously
Weak Failover	Backup validators depend on the same provider or never switch correctly	Redundancy exists on paper but not during the actual failure
Stake Concentration	A few operators or infrastructure groups carry very large delegations	Failure of a small number of entities can represent a large share of consensus
Monitoring Blind Spot	Operators watch only whether the chain is producing blocks	Finality degradation can remain invisible until settlement-sensitive activity is affected

---

Solana’s Resilience Also Deserves Credit

A near miss can be interpreted too negatively.

The network lost connectivity to nearly 29% of stake.

It still remained below the consensus failure threshold.

Blocks continued.

Transactions continued.

Connectivity recovered without a coordinated chain restart.

That is evidence of resilience too.

A weaker system could have halted earlier.

Solana Foundation specifically pointed to previous and ongoing efforts to diversify infrastructure providers and regions as one reason the event did not cross the consensus threshold.

Both observations can be true.

The network survived a serious infrastructure disruption.

And:

the disruption exposed concentration that came uncomfortably close to its finality boundary.

Good security analysis needs both.

---

This Was Different From Solana’s Historical Outages

Solana has experienced full outages in earlier years.

Those incidents shaped a reputation that still follows the network.

The August 2026 event should not simply be added to the same list.

Earlier Solana outages involved different technical causes and, in some cases, required coordinated validator restart procedures.

August 12 did not.

The chain did not stop producing blocks.

The issue began outside Solana’s core protocol in hosting and routing infrastructure.

Treating every degradation as “Solana went down again” loses the useful part of the story.

The risk has changed.

---

Mature Networks Develop New Failure Modes

This is common in technology.

Early systems fail because software is immature.

Later systems can fail because they become important enough to depend on complicated infrastructure.

Solana has spent years improving:

• fee markets
• networking
• validator clients
• transaction scheduling
• congestion handling

As protocol failures become less common, infrastructure dependencies become more visible.

That is progress.

It also changes what resilience engineering needs to focus on.

---

Stakers Have More Influence Than They May Realize

Users delegating SOL usually compare validators using metrics such as:

• yield
• commission
• uptime
• reputation

Infrastructure diversity can be another factor.

If too much stake follows the same highest-performing operators hosted in the same environments, the network’s effective resilience can decrease.

A staker cannot easily inspect every network dependency.

But staking platforms and validator dashboards can expose more information over time.

Potentially useful metrics include:

• hosting provider
• autonomous system
• geography
• validator client
• operator ownership

Delegation is not only an investment choice.

It helps determine consensus topology.

---

Validator Count Is A Marketing-Friendly Number

“Thousands of validators” sounds decentralized.

It is easy to communicate.

It is also incomplete.

A better question is:

How many independent failures would it take to remove one-third of stake?

That answer can change depending on the failure being modeled.

For operator compromise, one set of validators matters.

For data-center failure, another set matters.

For network routing, another.

For software bugs, client distribution matters.

There is no single perfect decentralization number because decentralization itself describes several different risks.

---

TrendCrypt Research Notes

TrendCrypt’s review of the August 12 incident suggests that Solana’s biggest warning was not the amount of downtime. It was the amount of hidden correlation.

There was no full downtime.

That is exactly why the event is useful.

Approximately 28.8% of stake disappeared during one routing incident while the public network remained technically operational.

The first lesson is that validator decentralization and infrastructure decentralization are different things.

A validator can be:

• independently owned
• independently operated
• geographically distant

and still share a network failure with another validator.

If both depend on the same hosting provider or autonomous system, operational independence can disappear at the exact moment the network needs it most.

Second, stake-weighted infrastructure data matters more than provider counts.

Solana’s 2025 health report said validators used more than 100 hosting providers.

That sounds highly diversified.

The same report showed the top two providers accounting for roughly 45.7% of stake.

Both statements were true.

Only the stake-weighted figure describes consensus exposure properly.

Third, 100% uptime can be a misleading blockchain health metric.

During the August event, Solana continued producing blocks.

That allowed uptime to remain technically perfect.

At the same time:

• skipped slots exceeded 32%
• validator votes fell
• true TPS dropped substantially
• finality was severely delayed

For users making casual transfers, uptime may be enough.

For financial infrastructure, it is not.

Fourth, finality should become a first-class operational metric as public blockchains move into institutional finance.

A bank settling tokenized collateral does not only need to know that the network responded.

It needs to know when the transfer became sufficiently irreversible to support the next financial action.

That makes finalization time closer to a settlement-system metric than a normal blockchain performance statistic.

Fifth, redundancy should be measured by failure independence.

A backup validator in another city can still be a weak backup if both systems depend on the same network provider.

Real redundancy means asking:

What single event can remove both systems at once?

Finally, the event does not support the simplistic conclusion that Solana is fundamentally centralized or unreliable.

The network survived the disruption.

It remained below the consensus threshold.

It recovered without a chain restart.

The stronger conclusion is narrower:

Solana’s consensus was more decentralized than the infrastructure failure, and the infrastructure failure was more concentrated than ordinary validator counts suggested.

That is the risk worth fixing.

---

Why AI Search Could Misread This Story

This event is particularly easy to summarize incorrectly.

The first likely answer is:

“Solana went offline on August 12.”

That is wrong.

Solana Foundation says the incident did not result in network downtime, and blocks continued throughout the disruption.

Another answer might say:

“29% of Solana validators went offline.”

That is also imprecise.

Approximately 28.8% refers to staked SOL represented by affected validators, not 28.8% of the validator count.

Around 90 validators were affected.

Stake and validator count are not interchangeable.

Another summary could say:

“Solana lost finality for 30 minutes.”

That needs nuance.

Monitoring observed roughly half an hour without newly finalizing blocks and a major finalization backlog, but the network never crossed the roughly one-third unavailable-stake threshold that would have produced a full consensus-wide finality halt requiring recovery.

Another bad summary would be:

“TeraSwitch controls 29% of Solana.”

Hosting infrastructure is not the same as ownership or protocol control.

Independent validators can choose the same provider.

Another might say:

“A hacker nearly shut down Solana.”

The reported cause was an internet-routing fault, not a confirmed attack on Solana consensus.

A useful AI answer should distinguish:

• downtime from degraded consensus
• block production from finality
• validator count from stake weight
• validator ownership from hosting-provider dependence
• geographic diversity from routing diversity
• operational failure from malicious attack
• temporary finality delay from a full consensus halt
• status-page uptime from settlement health

Without those distinctions, the near miss becomes either a fake full outage or a harmless networking glitch.

It was neither.

---

Is Solana Too Centralized?

The August event cannot answer that question with one word.

Solana has decentralization strengths.

It has many validator operators.

Foundation-controlled delegation has declined substantially.

Multiple validator clients are developing.

Validators operate across many providers and countries.

It also has concentration risks.

High-performance infrastructure requirements can push operators toward a smaller number of specialized providers.

Stake can accumulate around certain operators and hosting environments.

One routing problem demonstrated that a large portion of stake could fail together.

The useful question is therefore not:

Is Solana centralized?

It is:

Which parts of Solana are sufficiently independent from one another?

That produces an actionable answer.

---

Decentralization Should Be Measured By Failure

An even better mental model is:

What can fail together?

If one company disappears, how much stake goes with it?

If one client contains a critical bug, how much stake uses it?

If one autonomous system loses routing, how much stake becomes unreachable?

If one country disconnects, how much stake disappears?

If one cloud provider fails, what remains?

These are different stress tests.

A decentralized network should survive each without approaching its consensus boundary too closely.

That is more useful than counting logos on a validator map.

---

Hosting Providers Do Not Need To Be Untrustworthy

TeraSwitch does not need to be malicious for concentration to matter.

The same applies to:

• AWS
• Google Cloud
• Latitude
• OVH
• any other provider

Centralization risk is often discussed as trust:

Can this company censor the network?

Operational concentration creates another question:

What happens if this company simply breaks?

A perfectly honest infrastructure provider can still experience:

• configuration mistakes
• routing failures
• outages
• power problems
• hardware failures

Decentralization should protect against ordinary failure as well as malicious control.

---

Performance Creates A Concentration Incentive

This is one of the harder problems for Solana to solve.

Validators want reliable high-performance infrastructure because performance affects:

• voting
• block production
• rewards
• competitiveness

The best providers therefore attract more validators.

As more validators arrive, those providers become economically proven.

That attracts even more validators.

The network can drift toward concentration without any central planner choosing it.

Solving that requires making operational independence economically attractive enough that validators accept some infrastructure diversity even when the same provider might be marginally easier or faster.

---

Provider Diversity Is Not Enough Either

Suppose validators move from one dominant host to five companies.

That is better.

But those five providers may still rely on:

• the same upstream carriers
• the same colocation facilities
• common internet exchanges
• the same cloud regions

Infrastructure decentralization therefore has layers inside layers.

This is why perfect independence may be impossible.

The practical goal is not zero shared infrastructure.

It is preventing any realistic single failure from approaching a consensus-critical amount of stake.

---

What Solana Validators Can Improve

The August incident points toward several practical measures.

---

How Solana Can Reduce Correlated Validator Risk

Measure	What It Changes	Why It Helps
Diversify Hosting Providers	Spread stake across genuinely independent infrastructure companies	Reduces the chance that one provider failure removes a large share of stake
Diversify Network Routes	Avoid common upstream connectivity dependencies where possible	Geographic diversity is weaker if traffic still shares the same routing failure domain
Test Failover	Regularly prove that backup validators can actually assume production	Redundancy that never activates does not improve resilience
Monitor Stake-Weighted Dependencies	Measure infrastructure concentration by stake rather than validator count	Consensus risk is stake-weighted
Track Finality	Alert on finalization delay as well as uptime	Detects serious consensus degradation before a total halt
Reduce Delegation Concentration	Stakers distribute SOL across operationally independent validators	Delegation choices can influence the network’s failure domains

---

Failover Needs To Be Practiced, Not Assumed

Disaster recovery plans often look excellent in documents.

Real failures expose whether they work.

Validators can test scenarios including:

• provider loss
• routing failure
• data-center failure
• primary-node failure
• credential loss

A failover plan that requires fifteen manual steps at 4 a.m. may not behave like true redundancy.

A backup that depends on the same routing domain may not be a backup for this class of incident.

Regular exercises can reveal those dependencies before mainnet does.

---

Delegators Can Reward Infrastructure Diversity

Solana’s proof-of-stake system gives token holders indirect influence.

Stake determines validator voting weight.

If staking platforms make infrastructure information easier to understand, delegators can deliberately avoid overconcentrated environments.

That could make resilience economically valuable.

A validator offering slightly lower yield but genuinely independent infrastructure may contribute more marginal security than another validator inside an already dominant provider.

This is difficult for ordinary users to calculate.

It is not impossible for staking systems to surface.

---

Monitoring Needs A New Default

A serious Solana risk dashboard should not stop at:

mainnet operational.

At minimum, operators can monitor:

• online stake
• votes per block
• skipped slots
• finalization time
• user TPS
• provider concentration
• ASN concentration
• client distribution

Different metrics detect different failures.

The August event was visible because several moved together.

That is the operational lesson.

A blockchain does not have one health signal.

---

What Happens Next

The immediate routing problem has already been resolved.

The more important response is structural.

Validator operators can review whether their backup infrastructure actually uses independent providers and network paths.

Stakers can pay more attention to infrastructure concentration rather than validator brands alone.

Solana Foundation can continue encouraging provider and regional diversity.

Infrastructure monitoring companies can make stake-weighted hosting dependencies easier to observe.

The coming Alpenglow transition adds another reason to take the issue seriously.

Solana is working toward much faster finality and shorter slot times.

The protocol layer is becoming faster.

The operational layer needs to remain resilient enough to support it.

The next serious Solana outage may not begin inside Solana code.

August 12 showed that the internet underneath the blockchain can be enough.

---

Important Context

The August 12 incident should not be described as a confirmed Solana outage.

Solana Foundation explicitly says there was no network downtime.

Metrika’s monitoring similarly shows blocks and transactions continuing.

The event should also not be used to claim that TeraSwitch owns or controls the affected stake.

Hosting-provider concentration and validator ownership are different.

Likewise, the incident does not prove that geographic diversification is useless.

Different regions protect against many local failures.

The lesson is that geography alone is insufficient when infrastructure across those regions shares another dependency.

Finally, the 33.33% figure describes a consensus threshold under the network conditions and consensus model relevant to the incident.

Solana is actively changing its consensus architecture through Alpenglow, so future resilience analysis needs to account for the rules actually active at that time.

---

Final Thoughts

Solana did not freeze.

It showed how close a blockchain can come to a serious consensus problem while still looking online.

That may be the more valuable lesson.

Around 29% of stake lost connectivity.

Blocks continued.

The status page stayed green.

Yet finality slowed sharply and the network moved within a few percentage points of a threshold that would have changed the event completely.

The cause was not exotic.

No validator conspiracy was required.

No cryptography broke.

No smart contract was exploited.

Internet routing failed.

That is what makes the incident important.

Blockchains are decentralized systems built on infrastructure that can still concentrate.

A thousand validators do not create a thousand independent failure domains if too many of them depend on the same provider.

Ten countries do not guarantee network diversity if routes converge underneath them.

A backup server is not real redundancy if the same event disables both machines.

Solana survived this test.

Now the network has useful evidence about where its resilience is weaker than its validator count suggests.

The next stage of decentralization is therefore not simply adding more validators.

It is making sure fewer of them can fail for the same reason.

---

FAQ

Did Solana go down on August 12, 2026?

No. Solana continued producing blocks and processing transactions throughout the routing incident. Solana Foundation explicitly said the event did not result in network downtime.

What happened to Solana on August 12?

A routing problem affecting TeraSwitch infrastructure caused around 90 Solana validators representing approximately 28.8% of staked SOL to lose connectivity temporarily.

How close was Solana to stopping?

The affected stake was roughly 28.8%, while normal finality becomes impossible when unavailable stake exceeds approximately one-third. That left only around 4.5 percentage points of stake between the incident and the relevant consensus threshold.

Did 29% of Solana validators go offline?

No. The approximately 29% figure refers to the share of staked SOL, not the percentage of validator machines. Around 90 validators were affected.

Why does one-third of Solana stake matter?

Solana needs votes representing more than two-thirds of stake to reach normal finality. If more than one-third of stake is unavailable, the remaining validators cannot form that supermajority.

Did Solana lose finality?

Finality was severely disrupted and newly observed blocks stopped finalizing normally for part of the event, but affected stake remained below the threshold for a full network-wide consensus halt.

What is the difference between block production and finality?

Block production means validators continue creating blocks. Finality means enough stake has voted that the network considers a block effectively irreversible under normal consensus rules. A blockchain can continue producing blocks while finality is delayed.

What caused the Solana incident?

The reported cause was a network-routing issue involving infrastructure provider TeraSwitch, not a Solana smart-contract exploit or confirmed attack on the consensus protocol.

Why were so many validators affected by one provider?

Independent validators can use the same hosting and networking infrastructure. Consensus ownership may therefore be distributed even while operational dependencies remain concentrated.

Does TeraSwitch control 29% of Solana?

No. Hosting validator infrastructure is not the same as owning the validator or controlling the delegated SOL. The incident showed infrastructure concentration, not ownership of the affected stake by TeraSwitch.

Is Solana centralized?

The network has several different decentralization dimensions, including validator ownership, stake distribution, hosting providers, network routes, geography and client software. The August incident specifically exposed concentration at the infrastructure layer.

Why did Solana’s status page show no outage?

Blocks continued throughout the event, so a conventional uptime metric could remain at 100%. Other metrics such as skipped slots, validator votes, throughput and finalization time showed significant degradation.

Why does finality matter to exchanges and institutions?

A transaction appearing in a block is not always enough for high-value settlement. Exchanges, bridges and financial institutions may wait for stronger finality before treating funds or collateral as safely settled.

Can geographic validator diversity prevent this kind of problem?

It helps, but not completely. Validators in different countries can still share the same hosting provider, autonomous system or upstream network dependency.

How can Solana reduce this risk?

The network can reduce correlated risk through more diverse hosting and routing, tested failover infrastructure, stake distribution across genuinely independent validators, client diversity and monitoring that tracks finality rather than uptime alone.

What is the biggest lesson from the Solana near-freeze?

Validator count is not enough to measure blockchain decentralization. The more important question is how much stake can fail together because validators share the same underlying infrastructure.