TL;DR
- 28.76% of staked SOL became delinquent.
- Only 19.9 million SOL remained before the threshold.
- One routing failure hit validators across multiple regions.
- The incident exposed shared infrastructure concentration.
Solana stayed online on August 12, but the margin was much thinner than normal uptime statistics would suggest.
A routing failure affecting validators tied to the same infrastructure provider pushed 28.76% of all staked SOL into delinquent status, according to a reconstruction by Marinade Finance. At the worst point, only 19.9 million SOL separated the network from the one-third stake threshold where normal finality could stop.
Nearly 29% of Staked SOL Stopped Voting
Marinade Finance reconstructed the outage window validator by validator, showing how quickly delinquent stake built across the network on August 12.
The worst point came at roughly 03:58 UTC. Solana had 434.93 million SOL actively staked at the time, with 125.08 million SOL no longer voting normally, 28.76% of the total. The one-third mark was around 144.98 million SOL, putting the network about 86% of the way there.
“Delinquent” matters here. The affected validators were not necessarily powered off or crashed; they had fallen far enough out of sync, or lost enough connectivity, that their votes were no longer reaching the cluster as expected.
For consensus, the difference is mostly academic. Stake that cannot vote is stake the network cannot use.
Why the One-Third Threshold Matters
Solana relies on stake-weighted votes, and roughly two-thirds of voting power needs to remain available for the chain to keep reaching normal finality. Lose more than one-third and the network runs out of the voting weight required to keep confirming history in the usual way.
The Solana Foundation refers to 33% of delegated stake as a “superminority” because that share is enough to interfere with the network’s ability to finalize new blocks.
That does not mean every server goes dark at 33.3%. Validators may still be running and blocks may still be produced, but consensus loses the margin it needs to keep advancing normally.
August 12 came uncomfortably close to turning a networking problem into exactly that.
The Validators Were Separate. Their Infrastructure Wasn’t.
Marinade’s post-mortem points away from Solana’s validator software and toward a much less exotic failure: one hosting provider and one routing fault.
The trouble appears to have started around infrastructure in Miami, but the fallout was not local. Validators in Europe and Asia lost connectivity as well, and roughly 94% of the stake hosted with the affected provider became delinquent.
The operators themselves were separate businesses. The bottleneck was upstream.
Different validator identities, different delegations and different operators do not buy much resilience if a large share of them still depends on the same hosting company, transit provider or route to reach the rest of the cluster. Once that shared layer failed, what looked decentralized on-chain behaved like a single failure domain underneath it.
That is the part ordinary validator counts miss.
The Route Was Fixed in Minutes. Validators Took Longer.
The underlying routing issue was corrected within roughly 10 minutes, but validator participation did not snap back all at once. Marinade’s chart shows delinquent stake staying elevated after the network path was repaired, then dropping sharply as machines caught up with the cluster and resumed voting.
By around 04:30 UTC, most of the affected stake was back.
Solana never required the kind of coordinated restart seen during some of its previous outages. In February 2024, block production stopped for about five hours and validators had to upgrade software before restarting the cluster. Nothing comparable happened here: enough stake kept voting, the chain continued running, and the failure cleared before the one-third threshold was crossed.
The source of the risk was also different. This was not a validator-client bug or an internal consensus failure. A dependency outside the protocol briefly removed a huge chunk of voting power in one shot.
Alpenglow Is Already Moving Toward Mainnet
The near miss lands while Solana is already deep into testing Alpenglow, its biggest consensus overhaul in years. The code is feature-complete in Agave 4.2 and validators are now running it in a community test cluster, with mainnet activation targeted for Agave 4.3 in October.
Alpenglow will replace TowerBFT with Votor and targets roughly 150ms finality, down from about 12.8 seconds today. But the August 12 incident sits below that layer: faster consensus cannot remove a shared routing or data-center bottleneck if too much stake still depends on the same provider.
Solana’s Decentralization Problem May Sit Below the Chain
The August 12 event is less interesting as another entry in Solana’s outage history than as a warning about what validator decentralization metrics fail to capture.
Stake can be spread across hundreds of independent operators and still bunch up behind the same physical infrastructure. On-chain, those validators look separate. From the perspective of a broken route, they are not.
Solana escaped this one without losing finality.
What the incident exposed is that the network’s real redundancy depends on more than validator count and stake distribution. Hosting concentration, transit providers and routing paths belong in that calculation too.
Credit: Source link
