Solana came within roughly 20 million staked SOL of losing transaction finality on August 12, 2025, after an internet-routing failure took nearly 29% of the network’s stake offline. The 20-million-SOL figure was Marinade Finance’s estimate, reported in its account of the August 2025 incident, rather than a separately published snapshot of total voting stake at the moment of near-failure. It reflects the roughly 4.3-percentage-point gap between Marinade’s rounded 29% delinquency figure and the one-third threshold, applied to the total voting stake used in its calculation. The chain continued operating, but the incident exposed a less visible weakness in proof-of-stake infrastructure: validators can be spread across countries and data centers while remaining dependent on the same network providers, routes and failover systems.
The failure did not produce another prolonged Solana outage. Blocks continued to be produced, applications remained accessible and the network avoided the threshold at which it could no longer finalize transactions. But the event came close to something more consequential than a temporary slowdown.
According to staking platform Marinade Finance, almost 29% of Solana’s staked SOL briefly became delinquent when a routing problem at Teraswitch’s Miami facility disrupted connectivity to validators in Europe and Asia. Solana remained below the one-third threshold associated with a loss of finality by an estimated margin of about 20 million tokens.
Marinade separately identified AS2032 as an operator or network environment attributed with more than one-quarter of the SOL securing the chain. The available reporting does not state how much of that AS2032-attributed stake was included in the nearly 29% affected by the Teraswitch routing failure. It therefore establishes two large exposure figures, but not their overlap: nearly 29% exposed to the Teraswitch-related connectivity failure, according to Marinade, and more than 25% attributed to AS2032, also according to Marinade. The reporting does not provide separate stake totals for the affected cities, the failed route or the backup systems.
That distinction matters. The nearly 29% figure measures stake that became delinquent during the routing incident. The more-than-25% figure describes stake attributed to AS2032. The relationship between those figures remains unquantified, so the available evidence does not establish that AS2032’s stake made up the Teraswitch-affected stake or that operator concentration caused the event.
The episode therefore raises a question that is broader than whether Solana suffered another outage: how should the resilience of a high-performance blockchain be measured when its validators are geographically distributed but operationally connected through a relatively small number of infrastructure dependencies?
The answer matters to more than Solana users. It reaches staking providers, institutional delegators, infrastructure companies and developers building applications that assume a public blockchain will remain available. If validator redundancy exists mainly on paper, a single routing event can turn a diverse network into a correlated failure domain.
A network that stayed online, but nearly lost finality
Solana uses a proof-of-stake consensus system in which validators vote on the order and validity of blocks. The amount of SOL delegated to a validator determines the weight of its votes. A validator with a large stake has more influence over consensus than one with a small stake, although all validators still perform the underlying work of receiving, verifying and forwarding transactions and blocks.
The network can continue making progress when some validators disappear. That is expected. Internet connections fail, machines crash, software requires maintenance and data centers occasionally lose power. The protocol is designed to tolerate a portion of the validator set being unavailable.
The critical risk emerges when the unavailable voting stake approaches one-third of the total. In practical terms, Solana requires a supermajority of voting power to advance and finalize the chain. If enough stake is unable to participate, validators may still be producing or observing blocks, but the network can lose the ability to reach the agreement required for finality.
Finality is the point at which a transaction is considered irreversible under the protocol’s consensus rules. Before finality, a block can be replaced or abandoned as the network converges on the canonical chain. For an application processing a payment, exchange, game action or token transfer, the difference is important. A chain that continues producing unfinalized blocks may appear alive to users while becoming increasingly difficult to rely on.
Marinade said the August 12, 2025, failure took almost 29% of staked SOL offline and left the network roughly 20 million tokens short of the one-third threshold. Marinade’s 20-million-SOL number was an estimate derived from the reported stake percentages and the threshold, not an independently published exact measurement of the remaining margin. Using the rounded figures, the calculation is approximately (33.3% − 29%) × total voting stake; the available reporting does not provide the precise timestamped total voting-stake figure or a more detailed equation behind Marinade’s rounded estimate. The figure illustrates how close the system came to exhausting its available fault tolerance. It does not mean that 29% of all validators disappeared or that 29% of the machines stopped functioning. It refers to stake-weighted voting power affected by the connectivity failure.
The 29% and 20-million-token figures in this account come from Marinade’s 2025 reporting on the August 12 incident. The interpretation that follows about shared infrastructure and correlated failure is the author’s analysis. Marinade’s reported figures do not separately quantify the stake exposed to each data center, route, transit provider or failover system.
That distinction is essential. A network can have thousands of validator instances and still be exposed if a few operators control a large share of stake. Conversely, a smaller number of operators can provide meaningful redundancy if their systems are genuinely independent across providers, regions, power systems and network paths.
The August incident demonstrates the importance of examining those dependencies. It does not, based on the available reporting, establish that the stake attributed to AS2032 caused the routing event or that all of that stake was among the nearly 29% that became delinquent.
The route that linked distant validators to one failure
The reported origin was a bad route at Teraswitch’s Miami facility. The routing problem propagated across data centers in Europe and Asia, affecting validators in London, Amsterdam, Frankfurt, Singapore and Tokyo. North American operations remained online.
The geography makes the incident particularly instructive. Under a simple map-based assessment, validators in London, Amsterdam, Frankfurt, Singapore and Tokyo look diversified. They are separated by thousands of miles and operate in different national jurisdictions. But geographic separation does not automatically create infrastructure independence.
Data centers can share upstream transit providers. Operators can use the same cloud or colocation company. Network traffic can pass through common exchange points or depend on a single announced route. A facility in one country may rely on a remote provider in another for connectivity, monitoring or backup access. A validator fleet can also be administered through shared control systems, even when its individual machines are physically distributed.
The result is a form of hidden correlation. A network may appear decentralized because its nodes occupy multiple locations, but a failure at a shared provider can remove many of them at once.
In this case, the route was reportedly repaired in about 10 minutes. Yet many affected validators remained unavailable for approximately 33 minutes because backup systems did not switch over as intended. That detail changes the character of the event. The primary failure was an internet-routing problem; the prolonged exposure was partly a failover problem.
Redundancy only improves resilience when it activates reliably. A validator operator may have secondary links, backup routes or alternative facilities documented in an architecture diagram. If the system does not detect the failure quickly, if the backup route is misconfigured or if the failover path is itself dependent on the failed provider, the redundancy may not provide meaningful protection.
For a blockchain, timing also matters. Consensus operates continuously. A validator that reconnects after several minutes may need to catch up, rebuild its local state or reestablish its voting position. During that period, its stake may remain unavailable to the consensus process even though the underlying machine is healthy.
The incident therefore offers a practical lesson for infrastructure design: resilience is not measured by how many backup components exist, but by how much voting power remains online during a correlated failure and how quickly the rest can return to active participation.
The reporting quantifies the overall stake affected by the Teraswitch-related failure at nearly 29%, but it does not assign a separate stake amount to the Miami facility, the listed European and Asian locations or the failed and backup routes. Those dependency-level measurements are an analytical gap, not figures established by Marinade.
The concentration problem behind the outage
Marinade identified one network operator, AS2032, as controlling more than one-quarter of the SOL securing the chain. That level was reportedly above Solana’s prescribed safety limit.
An autonomous system number, or ASN, identifies a network or collection of networks that exchanges routing information under a common administrative policy. In this context, the reference to AS2032 points to an infrastructure relationship that may span multiple validators. The important issue is not simply the number of validator identities, but how much stake depends on the same operator or network environment.
The concrete figures are separate. Marinade reported that nearly 29% of staked SOL became delinquent during the Teraswitch routing failure. Marinade also attributed more than 25% of the chain’s securing SOL to AS2032. The reporting does not say whether AS2032’s more-than-25% stake was part of the nearly 29% affected stake, how much of it was affected, or whether AS2032 was responsible for the route failure. No separate stake amount is reported for the validators that remained unavailable during the 33-minute period because failover did not work as intended.
Accordingly, the evidence supports a claim about simultaneous exposure to two potential dependencies, not a claim of causation. Teraswitch-related connectivity affected nearly 29% of stake, according to Marinade. AS2032 was attributed more than 25% of stake, also according to Marinade. The author’s analysis is that the size of both figures makes overlap and common failure domains important questions for investigation; it is not established that AS2032 concentration produced the incident.
If a single operator controls more than a quarter of voting stake, it does not automatically have the power to halt or rewrite the chain. It does, however, become a major component of the network’s fault tolerance. If that operator experiences an incident affecting its connected validators, a large portion of voting power can become unavailable simultaneously.
This is the difference between validator count and effective decentralization. Counting machines can make a network look widely distributed. Counting independent failure domains provides a more useful picture.
Suppose 1,000 validator instances are divided among 100 operators, but 30% of stake is delegated to one operator running validators through a small group of common facilities and network providers. The network may report hundreds of active validators while retaining a single point of operational failure. If those validators disappear together, the consensus system experiences the event as one large outage, not as dozens of unrelated failures.
Stake concentration can arise for understandable reasons. Delegators want reliable operators with strong performance records. Staking platforms may select professional providers that can meet uptime requirements and manage hardware at scale. Large operators may offer lower fees, better monitoring and more consistent returns. Institutional investors may prefer counterparties that can provide reporting, compliance processes and operational support.
Those incentives can improve service quality while reducing infrastructure diversity. The most visible operators tend to attract more stake, and high stake can reinforce their reputation. Over time, a network may become economically decentralized in the sense that many users delegate their tokens, but operationally concentrated in the sense that a small number of companies run the systems receiving those delegations.
The August failure demonstrates why those two forms of decentralization must be evaluated separately. It does not, on the reported facts, demonstrate that AS2032’s attributed stake was the stake taken offline by Teraswitch.
What delegators may not see
For ordinary SOL holders, staking often appears to be a straightforward financial decision. A user chooses a validator or staking service, locks or delegates tokens, and receives rewards in return for helping secure the chain. The headline variables may include commission rates, historical uptime and expected yield.
Those metrics are useful, but incomplete. They do not necessarily reveal the infrastructure dependencies that determine whether a validator remains available during a regional or provider-level failure.
A validator can have excellent historical performance and still depend on a fragile architecture. A high uptime score may reflect normal operating conditions rather than resilience under stress. It may not show whether the operator runs through multiple independent internet providers, whether its backup link has been tested recently or whether its validators share a common control plane.
Delegators also may not know how much stake is already assigned to the same operator through other staking products. A staking interface can present several validator choices that appear separate while those validators are hosted by the same company or use the same network facilities. Conversely, a liquid-staking protocol may distribute stake across many validator identities without distributing it across enough independent businesses and infrastructure environments.
This creates an information problem. Users are making delegation decisions based on performance data, but the network’s safety depends on variables that are difficult to observe: ownership, hosting arrangements, upstream transit, power redundancy, software orchestration and tested recovery procedures.
Staking providers have an incentive to make these factors easier to evaluate. They could publish operator-level concentration data, disclose common hosting and network dependencies, and distinguish between physical location and actual infrastructure independence. They could also impose allocation limits when an operator approaches a risk threshold, even if that operator continues to deliver attractive rewards.
Such policies could reduce yield optimization in the short term. They could also improve the durability of the network on which the entire staking economy depends.
Why geographic diversity is not enough
Geographic distribution remains valuable. A network concentrated in one city or country faces obvious risks from power failures, natural disasters, regulation and connectivity disruptions. But geography is only one layer of resilience.
A more complete analysis would examine at least several forms of diversity.
The first is operator diversity. Are validators controlled by genuinely independent organizations, or are multiple identities managed by one company? Common ownership can mean common deployment decisions, shared monitoring and similar responses during an incident.
The second is facility diversity. Are machines hosted in separate data centers, or do many supposedly independent validators share a building, rack, power system or colocation provider?
The third is network diversity. Do validators rely on different transit providers and routing paths? Are their connections exposed to a common upstream failure? Can they continue communicating if a major route is withdrawn or misadvertised?
The fourth is software and configuration diversity. A common software release is generally important for protocol compatibility, but identical automation can create correlated failures if a configuration mistake is deployed across an entire fleet. Operators need consistent processes without turning every validator into a copy of the same operational risk.
The fifth is recovery diversity. Can validators restart independently? Are backups current? Can operators access machines if their primary management network fails? Have failover systems been tested under realistic conditions rather than merely installed?
These categories overlap, but they are not interchangeable. Ten validators in ten cities using one provider’s global network are not equivalent to ten validators in ten cities using independent providers and separately tested recovery systems.
The incident also shows why public dashboards can understate risk. A dashboard may display validator locations and uptime, but not the routes that carry traffic between those locations. It may show separate validator accounts, but not the corporate relationships behind them. It may list multiple data centers, but not the common transit or orchestration layer connecting them.
Improving transparency would require the ecosystem to treat infrastructure metadata as part of the security model rather than as proprietary operational detail.
The economic cost was small; the systemic risk was not
The immediate financial damage reported by Marinade was limited. About 90 validators were affected, losing a combined 333 SOL in rewards. Marinade said validator bonds would cover those losses.
That mechanism is useful for compensating operators for missed rewards, but it does not address the larger risk. Lost staking income is a relatively narrow cost. A failure of finality could affect exchanges, payment processors, decentralized applications, market makers and users attempting to settle transactions during the disruption.
For an exchange, uncertainty around finality can force deposits and withdrawals to be paused. For a decentralized finance protocol, price updates, liquidations or collateral movements may be delayed. For a consumer application, a transaction that appears complete but has not reached irreversible confirmation can create support, accounting and fraud problems. For institutions, the concern may be less about a few minutes of downtime than about whether service-level commitments can be trusted.
Solana’s design has attracted developers partly because high throughput and low fees make it suitable for frequent, user-facing interactions. Those same applications can increase the business cost of a consensus interruption. A blockchain used for occasional asset transfers may tolerate a short delay. A network supporting trading, payments, gaming and financial automation must provide predictable availability under stress.
The economic impact also extends beyond the chain’s direct users. Infrastructure companies, custodians and staking providers build products around assumptions about validator performance. If a single provider-level outage can remove a large portion of voting power, those businesses may need to maintain their own contingency systems, delay settlement or diversify their exposure across networks.
Reliability is therefore not an abstract engineering property. It is part of the product proposition. A chain that promises fast finality is also promising that the infrastructure behind that finality can continue communicating when normal conditions fail.
The February 2024 comparison
The August near-miss invites comparison with Solana’s February 2024 outage, which lasted approximately five hours. That earlier incident was associated with a software issue that halted the network and required validators to coordinate a restart.
The two episodes differ in important ways. A software bug can affect validators running the same code or configuration. A routing failure can affect validators that may be running correctly but cannot exchange information. One is primarily a protocol and release-management problem; the other is an infrastructure and dependency problem.
They are connected, however, by the same underlying question: how quickly can a large validator ecosystem detect, contain and recover from a correlated failure?
A network can reduce software risk through testing, staged releases, rollback procedures and careful incident response. It can reduce infrastructure risk through independent providers, diverse routes, multiple facilities and tested failover. Neither category can be solved by validator count alone.
The comparison also matters because repeated incidents can change how developers evaluate a platform. High throughput and low transaction costs may attract applications initially, but production users eventually ask whether the chain offers dependable settlement. A network’s reputation is shaped not only by whether failures occur, but by whether the causes are understood and whether the same class of failure can recur.
The August event provides a different diagnostic from the 2024 outage. It suggests that even if software remains stable, the network may approach a finality crisis through external infrastructure dependencies. That makes resilience an ecosystem-wide responsibility involving operators, delegators, hosting providers and protocol developers.
The challenge of fixing concentration without creating new concentration
Reducing correlated risk sounds straightforward: distribute stake more evenly and encourage operators to use more independent infrastructure. In practice, every solution introduces trade-offs.
Staking platforms can cap the amount of stake assigned to a single operator. This would limit the damage from an operator-level failure, but it could also push stake toward a larger number of smaller operators that lack the same operational maturity. A low stake threshold does not guarantee good monitoring, secure key management or reliable recovery.
Delegators can be encouraged to choose validators with distinct infrastructure profiles. Yet users cannot make that choice without accurate data, and collecting or verifying the data may impose costs on operators. Some infrastructure information may also create security concerns if disclosed too precisely.
The protocol could incorporate additional safeguards or incentives for stake distribution. But protocol-level rules that favor certain operator structures risk substituting one form of centralization for another. If the system rewards a particular set of approved providers, it may improve measured diversity while creating a new gatekeeping layer.
The most effective approach is likely to combine market incentives, transparency and operational standards. Staking products can publish risk-adjusted allocation policies. Validators can disclose their hosting and network arrangements at an appropriate level of detail. Independent monitoring services can evaluate common dependencies. Delegators can receive clearer information about operator concentration and correlated exposure.
Performance reporting could also evolve. Instead of showing only individual validator uptime, dashboards could show the percentage of total stake exposed to each operator, ASN, data center group or network provider. They could model the effect of losing a given dependency and identify whether the remaining stake stays comfortably below the finality-risk threshold.
This would not eliminate failure. It would make failure less likely to remove a dangerous share of voting power at once.
What a serious resilience audit should examine
The August incident gives Solana’s ecosystem a concrete checklist for follow-up investigations.
First, the network should establish exactly how the affected stake was related. Marinade reported nearly 29% of stake affected by the Teraswitch-related routing failure and more than 25% attributed to AS2032, but did not publish the overlap between those figures. How many validator identities were associated with AS2032? How much of that attributed stake was delinquent during the Teraswitch incident? Were the validators linked by common ownership, hosting, routing or some combination of those dependencies? Distinguishing those relationships is necessary for designing the right remedy.
Second, operators should document their failover procedures. Why did backup systems not switch over as intended? Was the problem detection delay, route selection, configuration, access to management systems or a limitation in the backup provider? Did operators test the procedure in advance, and did it work in a controlled exercise?
Third, the ecosystem should measure stake concentration by independent failure domain. Operator ownership is one metric. ASN exposure is another. Facility and transit-provider concentration may reveal risks that ownership analysis misses. The available account provides no separate stake totals for those categories beyond Marinade’s nearly 29% affected-stake figure and its more-than-25% AS2032 attribution.
Fourth, staking providers should explain how they allocate delegated assets. If a product distributes stake across many validators, does it also limit exposure to common operators and network providers? Are institutional customers given more detailed risk information than retail users?
Fifth, Solana should clarify what happens as the network approaches the one-third threshold. How are votes, delinquency and finality risk displayed in real time? What alerts are available to operators and delegators? Can the ecosystem identify the loss of a large correlated group quickly enough to coordinate a response before finality is affected?
Finally, the network should test the entire system, not just individual validators. A resilience exercise could simulate the loss of a major transit provider, a regional data center group or a large operator’s fleet. The objective would be to understand whether the chain remains finalizing and how quickly it returns to a healthy margin.
These tests would also reveal the difference between theoretical and operational decentralization. A network can claim thousands of validators, but the meaningful question during an incident is how many independent groups remain able to communicate and vote.
A product question for Solana’s next phase
Solana’s growth has been driven by a clear product proposition: applications can operate at high speed and low cost on a single, widely used network. That proposition is increasingly relevant as developers build consumer payments, trading venues, tokenized assets and interactive applications that require frequent settlement.
As usage expands, the standard for reliability rises. Users may accept that an experimental network sometimes requires intervention. They are less likely to accept uncertainty when the chain is positioned as infrastructure for mainstream financial and consumer products.
The August near-miss does not prove that Solana is fundamentally insecure, nor does it erase the progress made in validator operations and network performance. The chain continued through a serious disruption, and the route was reportedly restored quickly. The incident is valuable precisely because it revealed a weakness without becoming a full network halt.
That creates an opportunity to improve before a similar event becomes more severe. Solana can use the data to strengthen stake-distribution rules, improve infrastructure disclosures and make correlated dependencies visible to the market. Staking providers can treat delegation as an infrastructure-allocation decision rather than a simple yield product. Operators can view tested failover as part of consensus security, not just business continuity.
The central lesson extends beyond one blockchain. Proof-of-stake networks are often described in terms of token distribution and validator counts. Those measures remain important, but they do not fully capture how a network behaves under stress. Consensus depends on communication, and communication depends on physical and commercial systems that can fail together.
For developers and businesses choosing a blockchain, that analysis may become as important as transaction speed or fees. For investors and delegators, it may change how staking risk is evaluated. And for Solana’s builders, the event offers a practical design challenge: preserve the performance that made the network attractive while making its operational dependencies harder to correlate.
The next stage of blockchain infrastructure will not be defined only by how many transactions a network can process in ideal conditions. It will also be defined by whether operators, staking providers and delegators can distribute voting power across genuinely independent infrastructure. For Solana, the practical test is clear: ensure that the next major route, data-center or operator failure leaves enough independent stake online to preserve finality.