The usual lesson from the November 2020 Infura outage is that Ethereum apps lean on one company. That is true. It is also the shallow reading.

The deeper lesson is about version numbers. Ethereum itself did not fail that day. A hosted provider kept running software that disagreed with the rest of the network. The chain moved on, and the provider’s view of it did not.

That difference changes what a good backup plan looks like. This article walks through what happened, why it matters for any app that reads the chain through a hosted RPC endpoint, and what to put in place before your own bad morning.

What actually broke on November 11, 2020

An RPC provider runs blockchain nodes and lets your app talk to them over an API. Your dApp, wallet or exchange asks the node for balances, logs and receipts. If the node is wrong, your app is wrong.

On November 11, 2020, a chain split began at block 11234873 at 07:08 UTC. Nodes running older versions of the Geth client went one way. Nodes on newer versions went another. The Ethereum Foundation’s own security notice says the event left about 30 blocks stranded on a sidechain and knocked Infura offline.

The ripple effects were wide. Binance and Bithumb disabled ETH and ERC-20 withdrawals, and MetaMask struggled because Infura was its default provider. Infura’s customer list at the time included Uniswap, Compound and MakerDAO.

Here is the part that gets lost. The bug sat in old Geth code. According to BlockCypher’s post-mortem, the fix brought Geth back into agreement with Besu, Nethermind and OpenEthereum, and with the specification itself. It also broke agreement with earlier Geth releases. The other clients were right all along. The stale Geth nodes were the odd ones out.

So this was not a hack and not a hardware failure. It was a mismatch between what a provider ran and what the network had quietly moved to.

The provider was following its own rules

Infura’s post-mortem is candid. Some internal systems ran Geth v1.9.9 and v1.9.13, and a consensus bug stalled block syncing across them. Asked why it was not on the latest release, Infura said it updates deliberately because of stability, backwards compatibility and patch management. It also said that for a known consensus bug it would update immediately.

The catch was that nobody had flagged this one. The Geth team had shipped the fix without announcing it. Infura wrote that it had expected consensus bugs to be highlighted prominently in release notes. BlockCypher, which was also hit, described the same policy: update when the maintainers say it is required.

This is a real debate, and both sides have a point.

• Geth’s side. The team hoped people would upgrade gradually so the bad behavior faded out. Announcing a live consensus flaw invites someone to exploit it. Looking back, the team said it still believed it was the right call.
• The operators’ side. Infrastructure companies pin versions because new releases break things too. If every patch might be a silent hard fork, careful operators cannot tell which upgrades are urgent.

Neither side was reckless. Each followed a sensible policy, and together the policies produced a multi-hour outage for apps that never chose either one. Your uptime was set by a patching decision made in someone else’s change window.

Why a second provider may not save you

The standard advice is to add a backup RPC. That is good advice, but it hides two traps that this outage exposes.

Trap one: shared software

If your primary and backup providers both run the same client at the same version, one bug can hit both. Provider diversity is not client diversity. A backup that runs Geth is not independent of a primary that runs Geth.

The same goes for layers underneath. During the AWS us-east-1 incident on October 20, 2025, Infura and Alchemy both posted AWS-related incident notes. Two brands can share one cloud region.

Decentralized networks are not automatically immune either. In 2020, some Pocket network nodes were affected because some nodes proxied to Infura and some operators ran outdated Geth themselves. For a time, some requests returned current data and others returned what Infura was serving.

Trap two: wrong answers are not errors

Most failover logic reacts to failures: timeouts, refused connections, bad status codes. A node stuck on a minority fork can keep answering. The answers are well formed and wrong.

Look at how the common tools behave. Viem’s fallback transport mostly redirects failed requests and can rank providers by stability and latency. Ethers.js’s FallbackProvider can instead wait for a weighted quorum of agreeing responses. Those solve different problems. One handles absence. The other handles disagreement.

Viem’s ranker also defaults to pinging with the net_listening method, though you can switch it to eth_blockNumber. My own inference, not something the docs claim: a node frozen on a bad block could pass a liveness check like that, since the process is up. A health check that compares block hashes across providers would catch more.

Where client diversity stands now

Ethereum’s answer to this class of failure is having several independent implementations. If one has a bug, the others keep the chain honest. Ethereum.org notes that alternative clients without the vulnerability let the network keep running during a Geth flaw. It suggests no execution client should hold more than 33% of the network.

The picture has improved but depends on who is counting. Stakefish’s 2026 review puts Geth at roughly 50%, down from 85%. A newsletter citing clientdiversity.org gave Geth at 41% and Nethermind at 38% in April 2026. Either way Geth is above the ideal line. Stakefish also notes that a supermajority client above 66% with a bug could halt finality or cause a split.

One caution. These figures describe nodes and validators on the network. I could not find a public breakdown of which clients the big RPC providers run. That is a gap, and it is a question you can ask your provider directly.

Infura’s own fix list from 2020 pointed this way. It promised to use more OpenEthereum and re-introduce Besu for client diversity. Coinbase later said it would move toward multi-client staking infrastructure, after noting that Geth had been the only client meeting its requirements when it started staking in 2020.

A checklist for fallback providers and your own light infrastructure

Providers

1. Use at least two providers that do not share a parent company or cloud. Ask each which region and host they run on.
2. Ask which execution clients and versions each runs. Prefer a pair that differs. If an answer is vague, treat that as information.
3. Add disagreement detection. Query two providers for the latest block hash and compare. Use a quorum setup for reads that move money.
4. Make the health check meaningful. Check block height and hash against peers, not just whether the endpoint answers.
5. Keep the RPC layer swappable. One production guide advises wrapping the transport in your own module so you can add or change providers without touching UI code.
6. Subscribe to client release notes and security advisories yourself. The 2020 lesson is that you cannot assume your provider has the timeline you need.
7. Tell users what to do. MetaMask’s default is Infura, but analyst Larry Cermak noted during the outage that many users did not know they could switch. A help-page link to custom RPC steps costs little.

Your own light infrastructure

1. Run a node you control for critical reads. It does not need to carry all traffic. It can be the tie-breaker. Choose a minority client so it differs from most hosted setups.
2. Consider a light client for verification. a16z’s Helios turns data from an untrusted RPC provider into a verifiably safe local RPC. It syncs in around two seconds and needs no storage, according to its authors.
3. Know its limits. Helios still needs a source for consensus data. An early version of its README warned that a malicious consensus endpoint could push it onto the wrong chain. Configure that endpoint thoughtfully, and check current documentation.
4. Rehearse the failure. Point a staging app at a deliberately stale node and see what your UI shows. Blank screens are better than confident wrong balances.

The argument that is still open

Running your own infrastructure has costs. Full nodes need hardware, monitoring and someone on call. Small teams reasonably choose a managed service, and the managed services do offer uptime commitments that most solo operators cannot match.

There is also a fair point on the other side. A hosted provider with many customers may see a bug sooner than you would. It also has staff whose job is to react.

The 2020 outage does not settle that trade. It shows that the reliability you buy depends on choices you cannot see: which client, which version, which patching policy, which cloud. Those choices belong to the provider until you ask about them.

So treat your RPC provider the way you would treat any dependency that can return wrong data. Know what it runs. Run a second opinion. Keep a way to verify. An app reads the chain through whatever it connects to, and the decentralization that counts is the part you can check.

Sources

• Infura Mainnet Outage Post-Mortem 2020-11-11
• Geth security release (Ethereum Foundation Blog, republished)
• BlockCypher Ethereum Outage Post-Mortem 2020-11-11
• Ethereum Service Providers Scramble to Update Software After 'Unannounced Hard Fork' (CoinDesk)
• Ethereum Developers Allegedly Suppressed Knowledge of Infura Bug (Crypto Briefing)
• Client diversity (ethereum.org)
• The State of Ethereum in 2026 (stakefish)
• If Web3 is decentralized, why do DeFi dApps still break when the cloud goes down? (CryptoSlate)
• Fallback Transport (Viem docs)
• Building Helios: Fully trustless access to Ethereum (a16z crypto)
• Rivet's Operational Process is not Just a Talking Point