Blockchains are designed to keep running without anyone in charge, but “without anyone in charge” is not the same as “never breaks.” Networks stall, split, and occasionally rewind a few blocks of recent history. These events have names, known causes, and well-understood fixes.
This guide covers the three failure modes you’ll run into most: chain halts, chain forks, and blockchain reorgs. For each one, you’ll get a plain definition, why it happens, a real example, and what it means if you’re building on the network or just holding assets there.
What Is a Blockchain Failure Mode?
A blockchain failure mode is a specific way a network can stop behaving as expected. It’s not one bug but a category of problem that tends to recur across different chains for similar reasons.
Most failures trace back to how a decentralized network stays in agreement. Thousands of independent machines have to agree on one shared ledger, using a set of rules called the consensus mechanism. When those machines fall out of sync — because of a software bug, a flood of traffic, or a deliberate attack — the network degrades in one of a handful of predictable ways.
Understanding these patterns is practical, not academic. If you run a wallet, an exchange, or a trading app, the difference between a chain halt and a reorg changes how you respond. One means wait; the other means re-check what you thought was settled.
What Is a Chain Halt?
A chain halt is when a blockchain stops producing new blocks. Transactions stop confirming, balances freeze in place, and nothing moves until the network restarts.
Think of it as the whole network hitting pause at the same moment. The ledger isn’t corrupted and funds aren’t lost, but no new activity can be recorded while block production is stalled.
Why do chains halt?
Halts usually come from the validators — the machines that propose and confirm blocks — getting stuck. The common triggers are a software bug that crashes nodes, a consensus failure where validators can’t agree on the next block, or extreme congestion that overwhelms the network.
Solana is the most-cited example because it has halted several times. Its last full mainnet outage was on February 6, 2024, when a bug locked nodes in an endless recompile loop and froze the chain for about five hours. An earlier 2021 outage was worse: bots flooded the network during a token launch and the chain went dark for roughly 17 hours.
What happens during a halt?
While a chain is halted, your transactions simply don’t go through. Pending transfers sit unconfirmed, and apps that depend on fresh on-chain data stop updating.
Recovery is a coordinated effort, not an automatic reset. Validator operators usually have to agree on a restart point, upgrade their software, and reboot the network together. That’s why halts tend to last hours rather than seconds.
One structural fix is client diversity — running the network on multiple independent software implementations so a single bug can’t freeze everyone at once. Solana moved in this direction when its Firedancer validator client reached full mainnet deployment in December 2025, giving the network a second major client alongside its original one.
What Is a Chain Fork?
A chain fork happens when a blockchain splits into two possible versions of its history. At the split point, part of the network follows one set of blocks and part follows another.
Forks sound alarming, but most are routine and resolve on their own within seconds. The ones that matter are the deliberate ones, which happen when the rules of the network change.
Hard fork vs. soft fork
A fork occurs when the consensus rules are altered, and the two ways to make that change behave very differently. The distinction comes down to backward compatibility — whether machines running the old software can still follow along.
A soft fork tightens the rules. Because the new rules are stricter than the old ones, nodes that haven’t upgraded still accept the new blocks, so the network stays as one chain. A hard fork loosens or changes the rules in a way the old software can’t understand. If some participants refuse to upgrade, the network can split permanently into two separate chains with two separate coins.
| Chain halt | Chain fork | Blockchain reorg | |
|---|---|---|---|
| What happens | Block production stops | History splits in two directions | Recent blocks get replaced |
| Typical cause | Bug, consensus failure, congestion | Consensus rule change | Two blocks found at once, or an attack |
| Duration | Minutes to hours | Permanent (hard fork) or instant (soft fork) | Usually seconds |
| Data lost? | No | No | Transactions in dropped blocks revert |
| Main risk | Downtime | Chain split, replay issues | Reversed transactions, double-spends |
The best-known permanent split is Bitcoin Cash, which hard-forked away from Bitcoin in 2017 over block size. Ethereum and Ethereum Classic are another pair created by a contentious hard fork.
Planned forks vs. accidental forks
Not every fork is a disagreement. Many hard forks are planned upgrades that the whole community adopts together, with no lasting split — Ethereum ships network upgrades this way on a regular schedule.
There’s also a third, short-lived kind: the accidental fork. When two validators produce a valid block at nearly the same time, the network briefly has two candidate chains. It picks one within moments, and that cleanup is where reorgs come in.
What Is a Blockchain Reorg?
A blockchain reorg, short for reorganization, is when the network replaces one or more recent blocks with a different version. A reorg event happens when nodes disagree on the order of the most recent blocks, and the chain resolves the conflict by dropping the losing ones.
Every reorg has a depth — the number of blocks that got replaced. A one- or two-block reorg is normal background noise on many networks. A deep reorg is a red flag.
How do reorgs happen?
Most reorgs are honest accidents. A reorg most commonly follows two blocks being produced at almost the same time, which creates a temporary fork. Nodes then apply their network’s fork-choice rule to decide which branch is the real one, and the transactions in the abandoned branch return to the pending pool to be reconfirmed.
The catch is that transactions in a dropped block are no longer settled. If you saw a payment confirm and then a reorg removes that block, the payment effectively didn’t happen yet — which is exactly what attackers try to exploit.
Reorg attacks and the 51% problem
A reorg becomes an attack when someone forces one on purpose to rewrite history. The classic version is the 51% attack, where a party controls more than half of a network’s block-production power and uses it to secretly build a longer chain, then swaps it in to reverse their own transactions and double-spend.
Ethereum Classic shows how damaging this can be on a smaller proof-of-work chain. In 2020 it was hit repeatedly: one August attack reorganized 4,236 blocks and double-spent about $1.68 million, with the attacker renting the needed power rather than owning it. Ethereum co-founder Vitalik Buterin argued at the time that such chains should abandon proof-of-work, saying “at this point making the jump seems lower-risk than not making it.”
The lesson is that security scales with how expensive an attack is. Large networks are protected because renting enough power to out-build them would cost a fortune; small ones are cheaper to overpower.
How finality stops deep reorgs
Finality is the guarantee that a confirmed block can never be reversed. It’s the direct defense against reorgs, and different networks reach it in different ways.
Proof-of-work chains like Bitcoin offer probabilistic finality — a block becomes practically irreversible as more blocks pile on top, which is why exchanges wait for several confirmations before crediting a deposit. Ethereum’s proof-of-stake design adds explicit, economic finality: a finalized block can’t be reversed without an attacker burning at least a third of all staked ETH.
That finality isn’t instant, though. On Ethereum, time is divided into 12-second slots and 32-slot epochs, and reaching finality takes two consecutive epochs — roughly 12.8 minutes. Reorgs can only touch blocks that haven’t finalized yet. A proposed upgrade called single-slot finality aims to shrink that window from minutes to a single slot, closing the gap where reorgs are even possible.
Notably, even dramatic reorgs don’t always break finality. When Ethereum’s Beacon Chain suffered a seven-block reorg on May 25, 2022 — its deepest in years, caused by a client-upgrade mismatch — finality held and wasn’t even delayed.
Who Needs to Care About Failure Modes?
These events hit infrastructure-dependent products hardest. Wallets, exchanges, DeFi protocols, and payment processors all read from and write to chains constantly, so a halt, fork, or reorg flows straight through to their users.
The practical defenses differ by failure mode:
- For halts: don’t assume a single network is always available. Apps that span multiple chains, or that can fall back gracefully, keep working when one chain pauses.
- For reorgs: wait for enough confirmations — or full finality — before treating a transaction as done. This matters most for high-value transfers and exchange deposits.
- For forks: track upcoming upgrades so your software is ready, and watch for replay issues when a chain splits.
A lot of this comes down to reliable node infrastructure. Running full nodes across many networks is expensive and operationally heavy, which is why teams often use a provider that handles uptime, software upgrades, and multi-chain coverage for them. NOWNodes offers access to 120+ blockchain networks through one API, with block explorer access for checking whether a given block has actually settled — useful precisely when you need to confirm a transaction survived a reorg, or that a halted chain has resumed.
Conclusion
Chain halts, forks, and reorgs aren’t exotic edge cases. They’re the normal ways decentralized networks strain under bugs, upgrades, congestion, and attacks, and each one has a recognizable shape: halts pause the chain, forks split it, and reorgs rewrite its recent tip.
The takeaways are simple. Halts mean wait for a restart. Forks mean follow the rule change. Reorgs mean don’t trust a transaction until it’s final. Build with those responses in mind — and lean on infrastructure that stays available across chains — and these failure modes become manageable events rather than surprises.
FAQ
Can a blockchain halt cause you to lose funds?
No. A halt freezes block production, but the existing ledger stays intact. Your balances are preserved exactly as they were, and pending transactions confirm once the network restarts.
Do all blockchains experience reorgs?
Most proof-of-work and proof-of-stake chains see small, shallow reorgs as a normal part of resolving blocks produced at nearly the same time. What varies is depth and frequency — well-secured networks rarely see reorgs deeper than a block or two.
How many confirmations are safe before a transaction is final?
It depends on the network and the amount at stake. On probabilistic-finality chains, more confirmations mean more safety, so exchanges often require several before crediting a deposit. On networks with explicit finality, waiting for a block to finalize gives a hard guarantee that it can’t be reversed.
Does a chain fork always create a new coin?
Only a permanent hard-fork split does, like Bitcoin Cash splitting from Bitcoin. Soft forks and planned upgrades keep the network as a single chain and don’t produce a second asset.
What’s the difference between a fork and a reorg?
A fork is a split in the chain’s history, which can be deliberate (a rule change) or temporary (two blocks at once). A reorg is the network resolving a temporary fork by discarding one branch and keeping the other.
