Solana Narrowly Avoids Finality Halt After Teraswitch Routing Error Knocks Validators Offline
A Close Call for Solana’s Consensus Layer
Solana recently came within a hair’s breadth of one of the most dangerous conditions a proof-of-stake network can face: a finality halt. The near-miss unfolded when a routing error at Teraswitch, an infrastructure provider with a significant footprint in the Solana ecosystem, caused a widespread validator outage. According to data shared by Marinade Finance, one of the leading liquid staking protocols on Solana, 28.83% of all staked SOL entered a non-transactional state at the peak of the incident. That number may sound like just another network metric, but in Solana’s consensus model, it represents a serious structural threat. The critical threshold for transaction finality on Solana is 33.34%. If the non-transactional share had crossed that mark, the network would no longer have been able to finalize blocks. Marinade’s post-event analysis estimated that just over 19.9 million additional SOL would have needed to be deactivated to push the chain into that state. In other words, Solana came within approximately 86% of the threshold where finality would stop. The event affected around 90 validators, and some operators took about 33 minutes to restore their nodes to full functionality. Block production never stopped, and the network did not experience a traditional full outage. But the episode left little room for comfort, especially for a blockchain that has built its reputation on speed, scalability, and reliability. What made the event particularly unsettling was not the fact that the network nearly stopped, but that it kept running in a dangerously weakened state without most users noticing.
Finality Halt, Explained: Why the Network Was in Danger
To understand the significance of this near-miss, it is important to understand what finality actually means. In a proof-of-stake blockchain, finality is the point at which a block is considered permanent and cannot be changed or reversed. On Solana, finality depends on a supermajority of staked SOL participating in consensus. More specifically, at least two-thirds of staked tokens need to be online and voting for new blocks to be confirmed. If the active staking rate drops below 66.67%, the network can no longer reach that supermajority and finalization stops. That is precisely the condition that the network approached during the recent incident. At its worst point, the active staking rate was approximately 71.17%. That number was still above the threshold, but only barely. A finality halt is not the same as a chain stopping entirely. In fact, Solana continued to produce blocks throughout the event. The danger lies in the fact that without finality, those newly produced blocks lack the security guarantee that normally prevents them from being reorganized. Transactions could be left in an uncertain state, decentralized applications could lose access to reliable settlement, and exchanges and protocols that depend on Solana would face difficult decisions about whether to continue processing activity. The fact that the chain kept producing blocks may have made the incident invisible to many users, but the underlying risk was no less real. Marinade’s report made it clear that the network had slipped into a territory where a relatively small additional disruption could have triggered a finality halt. It also underscored the importance of staking delegation: when users stake SOL, they are not just earning rewards, they are choosing the validators that secure the network. If those validators share the same infrastructure, the entire network inherits that risk.
Teraswitch Routing Error: How It Happened
The source of the problem, according to Marinade’s technical analysis, was a network routing error tied to Teraswitch. The trouble started with a default route announcement from Teraswitch’s Miami facility. In routing terms, a default route is a catch-all path used by routers when no more specific path is available. For a route to work properly, it must be announced with the appropriate specifications and accepted by neighboring networks. In this case, the Miami route was announced without the necessary parameters. A route reflector in Amsterdam then picked up this flawed route and redistributed it to other facilities across Europe and the Asia-Pacific region. The effects were immediate and confusing. Edge routers in multiple locations began treating the erroneous route as their local default, while the core network continued to regard it as invalid. The mismatch led to the loss of valid traffic routing paths in a total of 12 locations, including London, Amsterdam, Dublin, Frankfurt, Singapore, and Tokyo. North American infrastructure was largely unaffected. The fact that the error originated in Miami and then propagated outward through Amsterdam underscores how unpredictable routing failures can be. The internet relies on Border Gateway Protocol, or BGP, to exchange information between networks, and BGP is based on trust. Networks announce routes, and other networks generally accept them without deep verification. When a bad announcement slips through, the consequences can spread far beyond the original point of failure. For a blockchain network with validators distributed across global data centers, that means a problem in one location can quickly become a problem for the entire network. This incident was a textbook example of how fragile the internet’s routing layer can be, and how heavily blockchain infrastructure depends on it.
Recovery Time, Missed Rewards, and the Cost of Downtime
Given the speed at which network failures can escalate, the response time in this incident was actually quite fast. Marinade said the routing problem was identified within approximately 10 minutes. That quick diagnosis likely prevented a much worse outcome. However, the recovery was not immediate. It took around 33 minutes for some validators to return to full normal operation, partly because routing changes need time to propagate across multiple regions and partly because validators may have needed to restart or resynchronize their nodes after the disruption. During that period, roughly 90 validators were unable to participate in consensus. For validators, downtime directly translates into missed staking rewards. Marinade calculated that the total rewards missed by the affected validators amounted to approximately 333 SOL. That is not an enormous sum in the broader context of Solana’s staking economy, but it is a meaningful reminder that even a short outage carries real costs. Beyond the financial impact, there is the issue of reliability. Validators are expected to maintain high uptime, and repeated disruptions can affect both their reputation and their attractiveness to delegators. The incident also highlighted a broader operational concern: a network that depends on a small set of infrastructure providers for a large share of its validators is only as resilient as the paths that connect those providers to the rest of the internet. Recovery may take minutes, but the exposure is constant. For Solana, the event reinforced the need for validators to think carefully about redundancy, failover connections, and what happens when their primary network path disappears.
Validator Concentration: A Deeper Problem Beneath the Surface
The incident also raised uncomfortable questions about how concentrated Solana’s validator infrastructure really is. According to Marinade’s analysis, approximately 118.89 million staked SOL was located on autonomous system number AS20326. An autonomous system is a collection of IP networks operated by a single organization, and its number serves as a unique identifier in the global routing system. That amount represented more than a quarter of the total stake on Solana. Even more significant, Marinade reported that approximately 94% of that stake was simultaneously offline during the incident. In other words, the network had allowed a large portion of its consensus power to become dependent on a single infrastructure provider, and when that provider encountered a routing problem, almost all of that stake went dark at the same time. The story does not end there. Marinade also noted that approximately 14.1 million SOL worth of stakes running on other platforms, including Latitude.sh, Limestone, Butterfly Research, and Allnodes, were offline at the same time. The organization said it could not determine from available data whether this simultaneous loss was caused by a shared infrastructure dependency or was simply a coincidence. However, the pattern suggested that concentration metrics based only on hosting provider labels may understate the true correlation risk. Two validators could be hosted at different providers and still depend on the same upstream network, the same exchange point, or the same physical region. In a proof-of-stake system, independence is not guaranteed by having different company names or different server locations. It requires a careful assessment of the entire chain of infrastructure dependencies that sit behind each validator.
Lessons From a Near-Finality Halt
The most important lesson from this episode is that decentralized networks are still built on highly centralized infrastructure. Solana is a blockchain designed to process transactions at high speed and support complex decentralized applications. Its technology is advanced, but its operations are tied to the physical world in ways that can be easy to overlook. A single routing error at a data center in Miami came close to triggering a finality halt that would have undermined confidence in the entire network. The network held, block production continued, and user funds were not lost. But the episode should serve as a wake-up call for the Solana community. Validators need to ask not only whether they have redundant hardware, but whether they have redundant network paths, diverse providers, and failover plans that would actually work under pressure. Developers and protocol stewards need to think more carefully about how stake concentration is measured and reported. The current focus on validator names and hosting providers may be insufficient. A more comprehensive picture of network risk would include autonomous system diversity, geographic distribution, and shared dependencies at the internet routing level. Marinade’s findings are not just a critique of one incident; they are a call for the industry to develop better tools for understanding and reducing correlation risk. As the crypto ecosystem continues to mature, the projects that endure will not necessarily be the fastest ones. They will be the ones that prove they can keep running even when the internet itself does not behave as expected. This article is for informational purposes only and should not be considered investment advice.
