According to Metrika’s analysis of the incident, around 90 Solana validators holding roughly 29% of staked SOL lost connectivity, and blocks took up to about 30 minutes to finalise, against t
According to Metrika’s analysis of the incident, around 90 Solana validators holding roughly 29% of staked SOL lost connectivity, and blocks took up to about 30 minutes to finalise, against the usual 13 seconds.
Solana never went down. Blocks kept coming, and an uptime chart would have shown an ordinary day. On Wednesday, October 21, the network switches to Alpenglow, an upgrade that targets finality of roughly 150 milliseconds, but nothing in it touches the hosting problem. A research report published on October 16 by Fidelity’s FCAT unit puts the largest hosting network at about 29% of stake, close to the share Metrika saw go offline.
Solana finalises a block, the point at which a transaction can no longer be reversed, only while more than two-thirds of staked SOL is voting. That normally takes about 13 seconds. With roughly 71% of stake still online on August 12, the network stayed above the line, but only just. Metrika puts the offline share at 28.83%, against a 33.34% point at which finalisation stops chain-wide.
August 12: share of staked SOL offline, against the finality-halt line
Offline: 28.83% Headroom: about 4.5 points Finalisation stops: 33.34% Online: about 71%Source: Metrika.
Metrika says another four to five percentage points of stake on the affected routes would have meant a network-wide halt needing coordinated recovery. The fault began in TeraSwitch’s Miami facility and spread to validator infrastructure in London, Amsterdam, Frankfurt, Singapore and Tokyo, and in most cases the affected validators’ backup systems never switched on.
TeraSwitch fixed the fault about ten minutes after diagnosing it, and traffic was flowing again by 04:16 UTC, 33 minutes after it began. Validators recovered over the following 40 minutes. In that time, the share of scheduled slots producing no block jumped above 32%, from under 1%. Non-vote transactions per second fell from roughly 1,100–1,300 to below 300. For about half an hour no blocks finalised at all, and the backlog then cleared in a burst averaging around 1,600 seconds from production to finality.
The one number that didn’t move was uptime, which held at 100% because the chain never stopped producing blocks. For about half an hour, though, nobody could say when a payment would become irreversible. Metrika, which sells a digital-asset risk-management platform and draws on its own indicators here, treats finality delay, not downtime, as the event that matters to anyone settling funds on Solana.
READ MORE:
Wall Street Can Now Bet on Bitcoin Cash and Uniswap
The risk FCAT describes is stalled finality and possible censorship. A coalition holding more than one-third of stake could stop the rest from reaching the two-thirds needed for finality, the report says, but it would not gain unrestricted control over user assets or the ability to rewrite finalised transactions. A hosting fault that took out the same share of stake would halt finality without anyone attacking anything.
That share is not hard to reach. FCAT counts roughly 20 validator identities (18 in another passage) holding more than a third of stake, and says that third sits in two countries, on two hosting networks and on two base client implementations. Those are vote accounts, not independent organisations: Figment, for one, runs two of the top five validators in that group. FCAT’s overall verdict is positive, citing more than two years without a major mainnet outage, vote success averaging about 99.7% in 2026 and a software stack that is slowly diversifying. It lists concentration as the thing to keep watching. FCAT is Fidelity’s applied-technology research unit and runs a small Solana validator of its own.
FCAT’s October snapshot puts the largest hosting network at about 29% of stake. The two figures measure different things, stake offline during a fault and a network’s share of all stake, but they land in the same place. FCAT says the Solana Foundation had already been working to reduce TeraSwitch’s dominance. Here is how its numbers break down, from the people running validators to the code they run.
18-20
OPERATORS
validator identities hold over a third of stake
Vote accounts, not independent organisations. Figment runs two of the group’s top five.
~40%
LOCATION
of stake in Frankfurt and Amsterdam
An IP-geolocation estimate that FCAT says may be inaccurate. About 59% sits in Germany, the Netherlands and the US.
~29%
NETWORK PROVIDER
of stake on one hosting network
October snapshot. Validators in different cities can share a provider, and validators in one city can use different ones.
~63%
SOFTWARE
of stake ran Jito-based software in Q3
Another 26% ran Harmonic. Most configurations still share Agave code underneath, so one bug there could hit them together.
Source: FCAT, The State of Solana: Network Health and Resilience (October 2026).
Validators cluster for a reason. Latency rewards being close to other nodes, FCAT notes, and specialist hosts such as TeraSwitch and Latitude build hardware for Solana’s workload. Operators do have protections: failovers, backup power, and private networks such as DoubleZero that reduce reliance on the public internet. The Foundation also set up an incident-response network, SIRN, in early 2026. On August 12, though, most backups never switched on.
The Solana Foundation’s delegation programme sets the main rule. Since May 1, 2026, validators that want Foundation stake have had to sit on a hosting network under a 25% ceiling and in a data centre under 15%. A validator that fails loses its Foundation delegation until it passes again.
The limits took effect three months before the August fault, and by FCAT’s October snapshot the largest network was still above the ceiling. The programme’s reach is the other half of the problem. As of Q3 it delegated to about 51% of validators, but those delegations amounted to about 4% of active stake. The rule gives validators a reason to diversify, but it doesn’t govern the rest of the stake.
Largest hosting network’s share of stake (October)
About 29%. The black line marks the Foundation’s 25% ceiling.
Stake delegated by the Foundation’s programme (Q3)
About 4%.
Both bars use the same scale, 0-40% of staked SOL. Sources: FCAT, Solana Foundation.
Alpenglow goes live on mainnet in epoch 1064, which Solana says starts around 15:00 UTC on Wednesday, October 21. Anza, the team behind the Agave client, has said about 14:50. The old voting system keeps running for the first 5,000 slots, about 18 minutes, and the new one takes over at slot 459,653,000. Finality is meant to drop from about 12.8 seconds to roughly 150 milliseconds, a figure Solana describes as an expectation, not a constant. Wallets and apps keep working as they do today.
It does nothing for the hosting problem. A faster vote shortens how long agreement takes, but nothing on Solana’s upgrade page changes where validators run or which provider connects them.
For now it also narrows software diversity. Validators must run Agave, Jito-Solana or Harmonic Salsa on a release built on Agave 4.3.0. Firedancer and Frankendancer aren’t supported during the migration, and Solana’s page gives no date for when they will be. Firedancer is the independent codebase FCAT calls Solana’s most significant move toward independent client diversity. Validators must also hold at least 0.8 SOL above the rent-exempt minimum in their vote account, or they won’t vote or produce blocks in the next epoch.
BEFORE
Now to about 14:50-15:00 UTC, October 21
Firedancer and Frankendancer operators move to an Agave-based client. Every voting validator holds 0.8 SOL above rent-exempt in its vote account.
AT THE SWITCH
Epoch 1064 begins
The old voting system runs for the first 5,000 slots, about 18 minutes. Alpenglow takes over at slot 459,653,000.
AFTER
What changes for data
Vote transactions leave blocks, so transaction counts fall. Confirmed and finalized become the same state. Participation data moves to block-footer certificates.
Monitoring changes too. Metrika’s analysis treats votes per block as the closest indicator of how near the network is to the finality line, because votes are ordinary transactions carried in blocks. Alpenglow takes votes out of blocks, and Solana’s migration notes say anything that measures validator participation by parsing vote transactions will need a new source, because that data moves into certificates in the block footer. Reported transaction counts will also fall without any drop in real activity.
If you stake SOL: look up where your validator is hosted before you delegate. Validators.app, the source both FCAT and the Foundation use, tracks stake by hosting network and data centre. A validator on the largest network shares the August risk.
If you build on Solana: expect transaction-count and TPS dashboards to drop on Wednesday with no change in real activity. Keep reading at confirmed until Alpenglow is live, then move to finalized, as Solana’s migration notes advise. Before activation, finalized still means a wait of about 12.8 seconds. Re-check any timeout or retry tuned to that delay, and track time to finality alongside uptime.
If you run a validator: if you use Firedancer or Frankendancer, switch to an Agave-based client before epoch 1064, and check that the vote account holds the 0.8 SOL.
After Wednesday, two numbers are worth watching: whether the largest hosting network’s share falls below the Foundation’s 25% ceiling, and when Firedancer is supported again. Neither is on Wednesday’s schedule.
This article is provided for informational purposes only and does not constitute financial or investment advice.
The post Solana Was 4.5 Points From a Halt and Uptime Said Nothing appeared first on Coindoo.
