The affected validators recovered within approximately 40 minutes, and the Solana mainnet did not require a coordinated restart.
Creech described the event as evidence of Solana's ability to withstand infrastructure disruptions. Jacob Creech's statement on X
However, separate analysis from Marinade Finance showed that the incident came closer to Solana's finality threshold than the validator count alone suggests.
Nearly 29% of Staked SOL Became Delinquent
Marinade Finance reported that approximately 28.83% of all staked SOL became delinquent for around 33 minutes during the incident.
That figure is important because Solana requires more than two-thirds of staked voting power to participate for transactions to reach finality.
The theoretical threshold at which finality could stop is therefore around 33.34% of staked SOL becoming unavailable.
In other words, the incident temporarily pushed delinquent stake to roughly 86% of the level required to disrupt finality.
The network nevertheless continued operating throughout the event.
Marinade's analysis identified approximately 90 validators affected by the routing problem, while Creech reported that 102 validators were not voting at one point.
Those figures measure different aspects of the incident and do not necessarily mean that all 102 validators were affected by the same infrastructure failure.
Solana Validators Recovered Without a Network Restart
One of the most important differences between the Aug. 12 event and previous Solana disruptions is that validators recovered without requiring a coordinated restart of the network.
Solana's official status page showed no mainnet incident for Aug. 12 or Aug. 13 and reported 100% Mainnet Beta cluster uptime over the previous 90 days. Solana Status
Validators participating in the Solana Foundation Delegation Program were also reportedly unaffected.
The incident therefore did not result in a prolonged interruption to block production or transaction processing.
Teraswitch Routing Failure Triggered the Disruption
The infrastructure problem was traced to Teraswitch, a network and hosting provider used by some Solana validators.
According to Teraswitch's incident report, a malformed default route originated from its MIA1 facility in Miami.
A route reflector in Amsterdam subsequently propagated the altered route into European and Asia-Pacific markets.
Local routers in several locations preferred the incorrect route over valid alternatives.
As a result, connectivity was disrupted at 12 sites across:
London
Amsterdam
Dublin
Frankfurt
Singapore
Tokyo
Teraswitch said its North American sites were not affected.
Engineers identified the malformed route within approximately 10 minutes and removed Miami from the provider's private backbone.
Service was restored at 04:16:15 UTC.
Teraswitch incident status report
Routing Problem Exposed Validator Infrastructure Concentration
While Solana successfully remained online, the incident highlighted a different type of decentralization risk.
The problem was not caused by a software failure in Solana's consensus mechanism.
Instead, the disruption affected the physical and network infrastructure supporting validators.
Marinade's analysis found that a single autonomous system controlled approximately 118.9 million SOL, representing more than one-quarter of all staked SOL.
Around 94% of that stake reportedly went offline together during the infrastructure disruption.
That concentration means that even when validator operators are geographically distributed, they can still share common infrastructure providers.
A failure affecting one major hosting or networking provider can therefore remove a significant amount of voting power at the same time.
Solana's Resilience Was Put to the Test
The event provides an important test of Solana's network resilience.
Despite the temporary loss of a large amount of voting stake, the network continued producing blocks and processing transactions.
That is particularly relevant given Solana's history of network interruptions.
The latest incident demonstrated that an infrastructure failure does not necessarily result in a full blockchain halt when sufficient voting stake remains available.
At the same time, the near-finality threshold reached during the event shows why infrastructure diversification remains important.
How This Differs From Solana's 2024 Outage
The Aug. 12 incident was significantly different from Solana's major network disruption in February 2024.
During the 2024 event, block production stopped and validators eventually required a coordinated restart before the network could resume normal operations.
The latest incident did not require a mainnet restart.
That difference highlights improvements in Solana's overall resilience while also showing that the network continues to face risks outside its core consensus software.
Firedancer Adds Another Layer of Validator Diversity
Solana has also been working to reduce dependence on a single validator software implementation.
Firedancer, an independent Solana validator client developed by Jump Crypto, began producing blocks on Solana mainnet in 2026.
The introduction of an additional validator client provides another layer of software diversity for the network.
However, the latest incident demonstrates that software diversity alone cannot solve every decentralization risk.
A blockchain can have multiple validator clients while still having substantial concentration among hosting providers, autonomous systems or physical data centers.
Infrastructure Diversity Becomes the Next Challenge
The Aug. 12 incident could therefore push Solana validator operators to examine how much infrastructure they share.
Geographic distribution is only one part of decentralization.
Validators can be located in different cities while still depending on the same cloud provider, networking company, autonomous system or private backbone.
Reducing those common dependencies could help prevent a single infrastructure failure from affecting a large percentage of voting stake.
Marinade said it plans to examine concentration limits based on autonomous systems and data centers, along with transparency around validator failover arrangements.
Teraswitch Still Investigating the Root Cause
Teraswitch has already deployed a global configuration change intended to prevent a similar malformed route from blocking traffic forwarding across its network.
However, the provider said its investigation into the underlying defect is still ongoing.
The company is examining why the Miami default route was advertised with incorrect attributes and has involved its hardware vendor in the investigation.
A complete root-cause report is expected after that work is finished.
What the Incident Means for Solana
The Aug. 12 disruption presents a mixed picture for Solana.
On one hand, the network continued processing transactions without a restart despite losing a substantial amount of voting stake.
On the other hand, the incident exposed how infrastructure concentration can create risks even when the blockchain itself remains operational.
The fact that nearly 29% of staked SOL became delinquent also shows how close a large infrastructure failure can bring the network to its finality threshold.
For Solana, the next stage of network resilience may therefore depend less on simply increasing validator numbers and more on diversifying where those validators run and which infrastructure providers they depend on.
Solana Network Remains Operational
The latest event did not produce another major Solana outage.
Instead, it demonstrated that the network can withstand a significant infrastructure disruption while continuing to process transactions.
But the incident also provides a warning about the importance of infrastructure decentralization.
As Solana's ecosystem grows, reducing the amount of stake exposed to individual hosting providers, autonomous systems and data centers could become an increasingly important part of maintaining network resilience.
Solana passed the latest infrastructure stress test without stopping, but the incident shows that validator diversity must extend beyond the number of validators to include the underlying networks and infrastructure supporting them
