On August 12th, Solana came within four and a half percentage points of losing the ability to finalize blocks, and almost nobody noticed. The network kept producing blocks and processing transactions the entire time, the status page recorded nothing unusual, and for roughly half an hour the margin between business as usual and a network-wide stall was thinner than it has been in a long while.

It's curious that none of the consensus software misbehaved. The code responsible for deciding which blocks the network agrees on did exactly what it was designed to do, all the way through. The problem was that a hosting company sent out a misconfigured network route.

In Finality Wars: Why Reactive Network is building with CometBFT we argued that fast finality is hard for Ethereum because Ethereum has over a million validators, and squeezing a million votes through the network every few seconds is a physical bottleneck that no amount of protocol elegance can talk its way around. We still think that is right. But August 12th points at something the validator-count framing quietly misses, and on reflection we think it may be the more important number.

Short Version For Newcomers

Validators are the independent machines that run a proof-of-stake network, Solana and Ethereum included. Each one's say in decisions is weighted not by machine count but by how much of the network's token is staked behind it, so a hundred small validators can matter less than one large one.

Finality is the point at which a block is permanently settled and can’t be undone. Reaching it requires validators holding more than two thirds of the stake to vote for the block. Turn that rule around and you get its shadow: if more than a third of the stake stops answering, whoever is left can no longer clear the two-thirds bar, and the chain stops declaring anything final at all.

That behaviour is a design decision rather than a flaw. Refusing to finalize is the safe way to fail, whereas the dangerous way is to declare a block settled and then have it reversed afterwards, which is roughly how exchanges get tricked and bridges get drained. A chain that stalls has decided it would rather say nothing than say something it might have to take back.

Which makes one third of the stake a line worth watching. In August, Solana walked right up to it.

Four Points From Stopping 

For Solana that line sits at 33.34% of stake. Marinade Finance, which published a detailed reconstruction of the incident, reported that the fault pushed 28.83% offline, leaving a margin of 4.51 percentage points, or roughly 19.9 million SOL.

The cause was thoroughly unglamorous. Routers across the internet spend their time telling each other which paths traffic should take, and one hosting provider sent out a malformed announcement that spread through its own network. Equipment at a dozen of its sites across Europe and Asia accepted the broken path in preference to the working one, leaving those sites with no usable route to the rest of the internet while the same provider's North American locations carried on unaffected. Connectivity returned after around 33 minutes.

Throughout all of it, 597 of the network's 699 staked validators kept voting. That figure is the one we want to dwell on.

Headcount Versus Stake

Count the validators that went offline and you get one number. Count the stake behind them and you get almost double. Stake is the number consensus actually measures.

Both figures are accurate, and the distance between them is not a rounding error. It is the difference between how decentralized a network looks on a dashboard and how it behaves when a router misfires somewhere in Amsterdam. Marinade reported that 27.34% of all network stake sat behind a single network operator, and that 94% of that stake went dark simultaneously.

So for the duration of the fault, the question that mattered was never "how many validators does Solana have?" It was "how many things here can fail independently of one another?" and the answer to the second question turned out to be a great deal smaller than the answer to the first.

None of this is a mark against Solana in particular. Validators pick hosting for latency and cost like everyone else, providers and jurisdictions cluster together for perfectly good engineering reasons, and we are not aware of any chain that is genuinely immune to this. Solana's own response has been unusually open about what happened and why. What the incident gives us is the cleanest real-world demonstration we have seen of a gap that most discussion of consensus papers over entirely.

Wrong Denominator

Here is where we have to complicate our own argument.

In Finality Wars: Why Reactive Network is building with CometBFT we treated validator count as the thing that buys a network its decentralization and costs it its speed. Ethereum has over a million validators and pays for them in the delay it takes to bundle all those votes together, while chains built on CometBFT, the consensus engine we run, operate with somewhere between 50 and 175 and finalize in a second or two. More validators, more decentralization, slower finality. 

August 12th suggests that count measures participation rather than independence. A validator set is a list of signing keys, whereas a failure domain is a building, a router, a network operator, a jurisdiction. The first number is published everywhere and quoted in every comparison, while the second is rarely measured at all and is the one that decides whether a chain keeps finalizing when something breaks. A million validators spread across three cloud providers is not a million failure domains, it is closer to three. Whether that beats a hundred validators across sixty providers is genuinely open, and not a question you settle by comparing counts. 

The implication cuts awkwardly toward compact validator sets, which is where we live. Small sets are obviously more concentrated and we have never pretended otherwise, but their concentration is at least legible: with a hundred validators you can enumerate the hosting and count the operators in an afternoon. With a million, nobody can hold that picture in their head, and the reassuring size of the number actively discourages anyone from trying. Which is the more honest position to be in, visible concentration or concentration hidden behind a big number?

Same Threshold, Different Bets

Three ecosystems are answering the same question right now in three different ways.

Solana is raising the tolerance. Its largest consensus overhaul since launch rebuilds how the network orders blocks and collects votes on them, targeting finality of around 150 milliseconds against today's roughly 12.8 seconds. Mainnet activation is scheduled to begin on September 28th, 2026, though two official sources give different timings, so the precise day is best treated as provisional. Asked about the August incident, one of the network's co-founders said the new design should keep finalizing with up to 40% of stake offline rather than a third. That was a remark on social media rather than a specification, but the direction of travel is unmistakable: the upgrade widens the very margin that a routing fault came close to consuming.

Ethereum is rehearsing the failure. Its next major upgrade has been running since August 20th on a test network built for it, and the plan is to stand up a second one designed specifically to simulate what happens when consensus struggles, before the code reaches the public testnets everyone uses. Deliberately building somewhere to practise not finalizing is a quietly impressive piece of engineering culture, and it follows from a design that would rather let finality lag behind than stop the chain.

CometBFT accepts the halt. There is no third option and no graceful degradation: once more than a third of the voting power is offline, block production stops. We wrote in June that this is the opposite call from Ethereum's, and it is. What August 12th adds is that the threshold is not an abstraction in a paper, but a real line that a real network walked up to this year, for reasons that had nothing whatsoever to do with consensus.

Three Ways to Stop

Which brings us to our own exposure, because it would be a bit rich to write all this and not turn the lens around. Reactive Network will soon run on CometBFT, and we’ve chosen it with our eyes open. Reactive finality is permanent the moment a block is validated, with no reorganizations, no probabilistic waiting and roughly one second of latency. The bill for that is precisely the one-third line Solana brushed against in August. 

We also have more than one surface on which things can stop, and this is the part that rarely shows up in discussions of finality: 

1. Reactive finality depends on our own validator set staying above the two-thirds mark. Below it, we stop finalizing.
2. Origin finality depends on chains we do not control. Our sequencer treats an event it has observed on an origin chain as canonical even if that chain later reorganizes, which is a deliberate choice and the thing that makes reactive contracts responsive, but it does mean another network's liveness becomes partly our concern.
3. Callback delivery depends on destination chains being available to accept a transaction, since a callback that cannot land is a callback that has not happened.

Any one of the three can stop without the other two noticing, and a user watching a cross-chain workflow stall has no way of telling which it was and little reason to care. This is the same borrowed-certainty problem we wrote about in  Intents, Solvers, and Borrowed Certainty, approached from the opposite side: solvers absorb origin-chain reorganization risk on behalf of users, and we absorb it on behalf of contracts.

What August 12th changes for us is not the architecture but the measurement. Counting our validators tells us remarkably little about whether all three of those surfaces could fail at the same moment, and neither we nor anybody else routinely publishes the number that would.

Question Pointed Back

The obvious response to an article like this is to ask the author how concentrated their own infrastructure is, and that is a fair question to ask us. Sequencer decentralization sits in a later phase of our roadmap, which means today the honest answer involves a shorter list of failure domains than we would like. Saying so is not a confession. It is the thing we are arguing everyone should be able to say precisely, including about themselves.

What would it take for chains to publish failure-domain counts next to validator counts? Not a standard, not a committee, just the habit of treating "how many separate things can break?" as a number worth knowing. Marinade produced it for Solana in a few hours because an incident forced the question. It would be better to have it before.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain execution. Reactive contracts subscribe to event logs across EVM chains and run Solidity logic automatically when a matching event fires, issuing cross-chain callback transactions once their conditions are met. The upcoming Omni fork moves the network to CometBFT consensus, bringing instant finality and roughly one-second blocks while keeping full EVM compatibility.

Build once, react everywhere!

Website | Blog | X | Telegram | Discord | Docs