The Solana Foundation published a detailed retrospective on September 14 about an infrastructure incident that most network users apparently never noticed.

At 04:01 UTC on August 12, TeraSwitch suffered a routing issue affecting its Frankfurt infrastructure, where a substantial number of Solana validators were hosted.

Nearly 29% of mainnet stake became unavailable.

Blocks continued to be produced and transactions continued landing. The Foundation says the infrastructure provider fully recovered a little over thirty minutes later.

Twenty-nine percent matters more than the thirty-minute duration

The outage itself was brief. The affected stake percentage explains why the event is technically significant.

Solana's current consensus still relies on TowerBFT. Like other Byzantine quorum systems, it can continue making progress as long as enough weighted voting power remains online and able to communicate.

The Foundation puts the relevant failure boundary at roughly 33.33% of stake.

Below that level, more than two-thirds remains available and the network can still form the quorum required for progress.

An outage approaching 29% is therefore more than “a lot of validators went offline.” It places the network only a few percentage points away from an area where normal consensus progress could become impossible.

That does not mean one-third of stake can disappear without consequence

The Byzantine threshold is easy to describe too casually.

Saying a system tolerates close to one-third failure does not mean it behaves identically with 1% and 32% of stake unavailable.

As participation falls, operational safety margin disappears. A second independent failure can suddenly push the network across the quorum boundary.

Offline leaders can also contribute to skipped slots and temporary performance degradation.

What the August incident primarily demonstrated is that failure of one large infrastructure provider was not, by itself, enough to stop consensus.

The risk was already known: TeraSwitch previously hosted 38% of stake

The most important part of the Foundation's account happened before the outage.

According to Solana Foundation VP of Technology Jacob Creech, TeraSwitch hosted around 38% of network stake the previous year.

At that concentration, a provider-wide failure could have crossed the one-third threshold.

The Foundation says it worked to reduce that concentration below 30% before the August incident occurred.

In other words, the network did not merely get lucky that only 29% disappeared. Prior diversification work directly changed the failure scenario.

Validator count alone is therefore a weak decentralization metric

One thousand validators do not necessarily create one thousand independent failure domains.

If hundreds of them share the same data center, network operator, cloud provider or software client, they can fail together.

In the TeraSwitch incident, hundreds of individual machines did not need to suffer separate hardware faults. A shared routing layer removed their ability to communicate with the rest of the network.

Operational and geographic independence therefore matters at least as much as the raw number of validator machines.

That is why infrastructure-provider, region and client distribution are part of the Solana Foundation's broader validator-health analysis.

Devnet experienced a much harsher version of the same event

The outage hit Solana's development network far more severely.

According to the Foundation, roughly three-quarters of Devnet stake became unavailable.

That is far beyond the amount needed to break normal quorum.

Devnet therefore stopped making normal progress temporarily, but the Foundation says it recovered automatically as validators returned, with no coordinated restart.

That distinction matters.

A blockchain can lose quorum and halt without necessarily requiring complicated manual intervention to recover once enough validators return.

The Foundation describes the behavior as self-healing: infrastructure came back and the network resumed from its existing consensus state.

Solana still carries the history of its earlier outages

The publication is particularly notable because of Solana's own past.

The network suffered several significant interruptions during its earlier years, some of which required coordinated validator restarts.

Bot-driven transaction floods exposed limits in transaction ingestion, while other events revealed problems in scheduling and validator software.

Those incidents permanently linked Solana's reputation to uptime questions.

The Foundation now points to changes made since then, including greater validator connection capacity, stake-weighted quality of service and a redesigned scheduler that reduces incentives to submit duplicate transactions.

The Foundation says mainnet has maintained 100% uptime since February 2024

Solana now claims its mainnet has experienced no downtime since February 2024.

Its official status page also reports 100% mainnet-cluster uptime across the most recent 90-day window.

That number still depends on what the operator defines as network availability.

A chain can keep producing blocks while experiencing performance degradation, RPC failures or problems affecting only some users.

The TeraSwitch event demonstrates that distinction perfectly: an enormous piece of infrastructure disappeared, while consensus itself never stopped.

Blockchain availability exists at several different layers

To an ordinary user, “Solana is up” sounds binary.

Technically, multiple layers can fail independently.

Consensus can continue while a major RPC provider is unavailable. An explorer can fail while validators operate normally. One geographic region can lose connectivity while other regions continue producing blocks.

The reverse is also possible: websites and RPC endpoints may remain reachable while consensus can no longer finalize new state.

Meaningful resilience therefore requires separating chain availability from validator, RPC, indexer, wallet and application availability.

Decentralized networks still run on highly concentrated infrastructure

A distributed consensus protocol ultimately runs on conventional infrastructure.

Validators use data centers, transit providers, bare-metal hosts, DNS, monitoring systems and cloud services.

A blockchain can distribute voting power across many operators while retaining shared dependencies underneath them.

TeraSwitch is almost a textbook example.

The protocol itself was not attacked. A conventional Internet routing layer failed, and nearly three out of every ten stake-weighted validators disappeared from the network's perspective.

Stake weighting makes some outages far more important than others

Solana validators do not all carry equal consensus weight.

Voting influence reflects the stake delegated to them. Losing ten tiny validators can be almost irrelevant, while losing a handful of large validators can move quorum dramatically.

That is why 29% of stake is the meaningful statistic here rather than simply the number of affected servers.

The network's economic topology becomes part of its technical topology.

Delegators indirectly determine which operators, software implementations and infrastructure providers become systemically important.

A major consensus transition is arriving at the same time

Solana is currently preparing its transition toward Alpenglow, the network's next consensus mechanism.

Cryptographic prerequisites are already being activated on mainnet. Validators now need registered BLS public keys, while the Validator Admission Ticket went live in July.

The full Alpenglow consensus switch is expected separately with Agave 4.3, currently targeted for the fourth quarter of 2026.

Alpenglow will replace TowerBFT and targets approximately 150ms finality.

That upgrade does not eliminate the problem exposed by TeraSwitch. Whatever the consensus algorithm, concentrating too much voting weight behind one infrastructure provider creates a shared failure domain.

Resilience is therefore an infrastructure policy as much as a consensus algorithm

The consensus protocol did exactly what it was designed to do on August 12: continue while enough voting power remained available.

But that success depended partly on a decision made long before the incident — reducing TeraSwitch's share of hosted stake from 38% to below 30%.

That may be the most useful lesson from the event.

Fault tolerance is not just about writing a protocol that can survive one-third of nodes failing.

It is also about ensuring that no single cable, operator, data center, cloud provider or software client represents that one-third in the first place.

On August 12, Solana remained on the safe side of that boundary.

With nearly 29% of stake offline, it simply did not have a great deal of room left to discover a second problem at the same time.