A consensus bug in several versions of Geth, the dominant Ethereum client, caused nodes on older builds to diverge from patched ones at block 11234873.
Because Geth ran on a large majority of the network, this was not a minor incompatibility. It was an unannounced chain split.
Infura, the API provider that most wallets and applications read the chain through, was running affected versions and went down. MetaMask, which used Infura by default, stopped working for a large share of its users. Binance and Bithumb suspended ETH and ERC-20 withdrawals.
The chain never stopped producing blocks. Service came back at 14:42 UTC.
Read what actually broke. Nothing happened to the blockchain. What happened is that two hidden dependencies turned out to be sitting underneath a system everyone described as having no single point of failure: one on a single client implementation, one on a single API provider.
Users had chosen neither. Users could see neither. Most did not know either existed.
You now know what a chain is, how it agrees, and what its decentralization does and does not buy. This lesson is about the gap between that picture and what happens when you actually open a wallet, because they are not the same thing and the difference is where the real chokepoints live.
Three words people use interchangeably
A node is a computer holding a copy of the chain and independently applying the rules. It does not trust anyone's summary. It has the data and it checks the arithmetic itself, which is the thing F101-01 said made trust unnecessary.
A client is the software a node runs. Multiple independent teams write clients for the same network, from the same specification, in different languages. Two clients are supposed to reach identical conclusions about every block, and when they do not, that is a consensus bug.
An RPC provider is a company running nodes and answering questions over the internet for a fee, or for free. Remote Procedure Call, meaning you ask the question and their machine does the work.
Here is the sentence that reorganises most people's mental model.
Your wallet is almost certainly not a node. It holds keys and signs transactions. When it shows you a balance, it asked somebody. When you send a transaction, you handed it to somebody to broadcast.
You are trusting an RPC provider. You probably never chose it.
What that party can and cannot do
Being precise here matters, because the alarming version and the dismissive version are both wrong.
They cannot move your funds. They never see your private key. Signing happens locally, on your device or your hardware wallet. This is the important limit and it is why the situation is uncomfortable rather than catastrophic.
They can show you the wrong thing. A wrong balance, a stale state, a transaction that appears confirmed and is not. You have no independent way to know, because checking would mean asking someone else, and most people ask the same someone.
They can refuse you. Decline to relay your transaction, or drop transactions with particular characteristics. Your transaction is only in the mempool if someone put it there.
They can go dark, taking every application that depends on them along, which is the autopsy.
They can watch you. Every query links your addresses to your IP address at a specific time. The chain is pseudonymous, and the party you ask about it holds exactly the correlation F106-04 spends a lesson telling you to avoid creating.
That last one is underrated. On-chain privacy work is largely undone by asking one company, from one IP address, about all of your addresses, all day, for years.
Client diversity is a safety property
The 2020 incident had two layers and this is the deeper one.
If one client implementation runs most of a network, a bug in that client is not an outage. It is a consensus event, because the majority defines what the chain is. The minority running correct software finds itself on a fork of one.
If no implementation exceeds a large share, the same bug takes some nodes offline and the network continues without them. Painful for those operators, survivable for everyone else.
Let a single client run share p of the network, and suppose it develops a bug producing an invalid state transition.
p above 2/3. On a chain needing a two-thirds supermajority to finalise, the buggy majority can finalise its own incorrect chain. The correct minority is now the fork. Worst case: a bug becomes the canonical history.
p between 1/3 and 2/3. Nobody reaches the supermajority, so the chain stops finalising. Blocks may continue but nothing is settled. Bad, loud, and recoverable, because the damage does not become permanent while everyone works it out.
p below 1/3. The affected nodes drop off. The remaining supermajority finalises normally. The bug is an incident for those operators, not for the network.
So the meaningful threshold is around one third, not one half, and it is lower than the number most people carry in their heads from 51 percent attacks. Notice that this is a different threshold from F101-02's, and it protects against a different thing: F101-02 was about a malicious majority, and this is about an honest majority that is simply wrong in the same way at the same time.
Shares change constantly, so look them up rather than trusting any figure printed here. The reasoning is what is durable.
Trace your own path
Do this once, for real. Open your wallet's settings and find the network configuration. There is an RPC URL in there. That is the company standing between you and the chain.
Then write out the chain of dependency:
- You, holding a key
- Your wallet, signing locally
- An RPC provider, answering questions and relaying transactions
- Their nodes, running some client
- The network, which is the only part everybody was thinking about
Steps 3 and 4 are invisible in the interface, were not chosen by you, and are the two that failed in 2020.
Then count how many things you use depend on the same step 3. For most people the answer is all of them, because the default is the same default everywhere.
Switching your RPC endpoint takes about two minutes: settings, networks, edit, paste a different URL, save.
Do it once even if you switch straight back. The value is not the alternative provider, which has the same properties as the first one. The value is that you have now seen the dependency exists, know where the setting lives, and can move if the default goes down or starts refusing your transactions. That is the difference between an outage being a mystery and being an inconvenience.
Get the alternative endpoint from the chain's own documentation, not from a message or a search result, per F111-04. An RPC URL from a stranger is a party that gets to answer all your questions and see all your addresses.
Should you run a node?
The honest answer is mostly no, and the industry is bad at saying so.
Running a full node means real disk, real bandwidth, and ongoing maintenance. For someone holding a moderate amount and transacting occasionally, the default path is acceptable, and pretending otherwise makes people feel guilty about a decision that is fine.
It genuinely earns its cost when:
- You need to verify rather than be told. Anyone accepting large payments, running a business on-chain, or making decisions from on-chain data should not take a single company's word for what the state is.
- Censorship is in your threat model. F106-01's model applies. If it is plausible that someone would want your transactions not to be relayed, you need a path that does not depend on their goodwill.
- Query privacy matters. A node you run does not report your addresses to anybody.
There is a middle option people miss: use your own node when you can, a provider when you cannot, and know which one you are on. That is available to almost everyone and it is most of the benefit.
Since I use a hardware wallet, none of this affects me.
A hardware wallet solves the part of this problem that matters most, and it solves exactly one part.
Your key stays offline and signing happens on the device, so no RPC provider can take your funds, and that is the important protection. But the hardware wallet still needs somebody to tell it what the state of the chain is, and its companion application is asking a provider like everything else.
Which means: a lying or broken provider can show you a wrong balance on a hardware wallet, a provider outage can leave you unable to transact with a hardware wallet, and a provider can correlate all your addresses whether or not the key is offline.
Different layers. The hardware wallet defends authorisation. The node question is about information and access, and they fail independently.
A node holds the chain and checks it, a client is the software that does the checking, and an RPC provider is the company that does both on your behalf and answers your questions, which is what your wallet is actually talking to. That party cannot take your funds, because it never sees your key, and it can show you wrong data, refuse to relay you, go dark, and log every address you own against your IP. Client diversity matters at a threshold near one third, not one half, because an honest majority that is wrong in the same way defines the chain. Find your RPC setting, change it once so you know how, and remember that in 2020 nothing happened to Ethereum and most people still could not use it.