Every blockchain operator eventually runs into the same realisation. The chain you depend on is not a single canonical record. It is a working consensus over events, and that consensus can rearrange, fragment, or split outright with no warning to the systems built on top of it.
For node operators, validators, indexers, and RPC providers, fork events are routine. The question is never whether they happen. It is whether the infrastructure underneath responds correctly when they do. This piece walks through the four fork classes that matter operationally, and what each one means for the people running production infrastructure on top.
Chain reorganisations
A reorg occurs when a node's local view of the chain is replaced by a different, longer or higher-weight branch. The trigger is almost always network propagation: two valid blocks are produced near-simultaneously, propagation favours one for a few seconds, and a competing branch later overtakes it.
Most reorgs are shallow. On Ethereum's beacon chain, single-slot reorgs happen regularly under normal conditions. On Bitcoin, one-block reorgs are a daily occurrence. Deeper reorgs, three blocks or more, are rarer and usually indicate either a network partition, a propagation anomaly, or a coordinated reorganisation attempt.
The implication for infrastructure is that recent state is provisional. A balance read at the tip can be retroactively wrong. An RPC response that quoted block N may need to be re-served if block N is later replaced. Operators who treat the head of the chain as final will eventually serve incorrect data.
Uncle and ommer blocks
When two blocks are produced for the same height, only one wins. The losing block, valid but orphaned, is what Ethereum historically called an uncle and what newer designs sometimes call an ommer. Bitcoin discards orphaned blocks entirely. Pre-Merge Ethereum rewarded uncle producers, both to compensate for accidental forks and to discourage selfish mining.
Post-Merge Ethereum no longer produces uncles in the classical sense, because slot-based block production removes the race condition that created them. The underlying concept remains relevant on networks with shorter block times or weaker propagation guarantees. Polygon PoS, BNB Chain, and several L2s all surface orphaned blocks under load.
For infrastructure operators, uncles affect finality assumptions. A transaction included in an uncle is not in the canonical chain. Anything that depended on its inclusion, an index entry, a confirmation count, a downstream notification, has to be reversed.
Soft forks
A soft fork tightens the protocol rules. Blocks valid under the new rules are also valid under the old rules, but not the reverse. Un-upgraded nodes continue to follow the chain, occasionally accepting blocks the upgraded majority has already rejected.
Soft fork rollouts typically depend on miner or validator signalling. Bitcoin's BIP9 and BIP8 use version-bit signalling over a defined activation window. Cosmos SDK chains rely on governance votes plus coordinated halts. Ethereum has historically bundled soft-fork-style changes into hard forks for clean activation, though some EIPs introduce stricter validation that, in practice, behaves like a soft fork.
The operational risk during a soft fork rollout is asymmetric. Operators who upgrade are safe. Operators who do not are at risk of following a temporary fork, attesting on blocks that the rest of the network now considers invalid, and producing data that downstream consumers will eventually have to discard.
Hard forks
Hard forks change the rules in a non-backward-compatible way. Blocks valid under the new rules are invalid under the old, and vice versa. Unpatched nodes do not just lag behind. They follow a different chain entirely.
Most hard forks are coordinated upgrades: Ethereum's London, Shanghai, and Dencun, or any of the regularly scheduled upgrades on Cosmos chains. These are the easy case. Operators upgrade in advance, the entire network activates at the same height, and the old rules disappear.
The hard case is contested hard forks, where part of the network refuses to upgrade and the chain splits. Ethereum Classic, Bitcoin Cash, and Bitcoin SV are the canonical examples. For an operator running unpatched nodes during a contested split, the result is silent: the node keeps producing blocks and serving RPC responses on a chain that most of the ecosystem no longer recognises. Indexers ingest data that does not match anything the rest of the market sees. Validators on the wrong branch earn rewards that no longer exist on the dominant chain.
Even uncontested hard forks introduce a window of risk. Unpatched RPC endpoints serve answers from the old chain. Wallet integrations may submit transactions that are rejected by upgraded nodes. The cost of a missed upgrade scales with the volume of traffic the node was handling at the time.
Operational implications
For indexers, every fork event is a data integrity problem. The pipeline must be able to detect that a block previously processed has been orphaned, roll back any derived state that depended on it, and re-ingest the new canonical history. Indexers that write monotonically, and assume the chain never moves backward, produce silently incorrect datasets. Those failures are harder to detect than crashes, which is what makes them dangerous.
For validators, fork events translate directly into attestation risk and slashing exposure. Following the wrong branch can trigger surround votes on Ethereum, double-signs across forked chains on Cosmos, or a string of missed attestations during the window of confusion. Validator infrastructure has to detect divergence quickly and refuse to sign under ambiguity.
For RPC providers, the hardest problem is response consistency. Two requests to two endpoints, served seconds apart, can return different views of the chain head if one endpoint sits on a branch that was reorganised. Stale data from un-upgraded nodes is a related failure mode: an RPC that quietly serves data from the wrong fork is worse than one that goes offline, because consumers cannot tell the difference until reconciliation downstream.
Operational takeaways
Treat the head of the chain as provisional. Build confirmation depth into anything that depends on finality, and use the network's own finality gadget where one exists.
Detect orphaned blocks explicitly. Indexers and downstream pipelines should subscribe to reorg events, not infer them.
Upgrade nodes ahead of fork heights, not at them. The cost of being early is zero. The cost of being late is silent corruption of every response served from the unpatched node.
Monitor for divergence. Cross-check block hashes against independent sources, across geographic regions and client implementations, so that a node serving the wrong fork is caught before downstream consumers are.
Closing
Liquify operates bare-metal RPC, archive, and validator infrastructure across more than ninety networks, processing over 2 billion RPC requests per day. Fork handling, including reorg detection, upgrade coordination, and cross-region divergence checks, is built into the way the infrastructure is monitored, upgraded, and routed, not bolted on after the fact.
Builders who need RPC infrastructure that behaves correctly through fork events can start on the Liquify Portal with 50,000 free daily RPC requests.
