The block that won the race but still got paid
Picture two miners, one in Seoul and one in São Paulo, solving the same proof-of-work puzzle within milliseconds of each other. Both broadcast valid blocks. The network can only adopt one as the canonical chain tip. The other becomes an uncle: a valid, mined block that arrived too late to join the main chain. Before the Merge, Ethereum produced uncles at a rate that regularly sat between 6% and 12% of all mined blocks, depending on network load and propagation conditions. That number is not a rounding error. It is a structural feature with real security consequences.
Understanding why those orphaned blocks mattered requires understanding what they cost, what they paid, and how adversaries could have exploited them if Ethereum hadn't designed a partial remedy.
Why orphaned blocks are a security problem in the first place
In Bitcoin, a block that loses the propagation race is simply discarded. The miner who produced it gets nothing and contributes nothing to chain security. This creates a quiet but serious centralisation pressure: large mining pools with better network connectivity orphan fewer blocks, so their effective hashrate advantage over smaller, geographically distant miners compounds over time.
The deeper security concern is called selfish mining, formalised in a paper by Ittay Eyal and Emin Gün Sirer. The argument: a miner controlling roughly 33% of hashrate can, under certain conditions, withhold newly found blocks, force honest miners to waste work on stale chain tips, and capture a disproportionate share of rewards. A high uncle rate is precisely the environment where this strategy becomes more attractive, because it signals that propagation delays are long enough to exploit.
High uncle rates also dilute the security budget. If 10% of all mining work produces uncles that contribute nothing to the canonical chain, then the effective hashrate defending that chain is 10% lower than the raw numbers suggest. An attacker planning a 51% attack only needs to overpower the work that actually counts.
What Ethereum actually did about it: the GHOST protocol
Ethereum's answer was a modified version of the Greedy Heaviest Observed Subtree (GHOST) protocol, implemented from the network's genesis. The key innovation is that uncle blocks are not simply discarded. They are referenced by the miner who finds the next canonical block and included in that block's header, with both the uncle's original miner and the referencing miner receiving a partial reward.
The mechanics are specific. An uncle block miner received a reward calculated as `(uncle block number + 8 - including block number) / 8` multiplied by the base block reward. An uncle included one block later paid out 7/8 of the full reward, two blocks later paid 6/8, and so on down to a minimum of 2/8 at six blocks of depth. Uncles older than six blocks were ineligible entirely. The miner who referenced the uncle in a canonical block received an additional 1/32 of the base reward as a referencing fee.
Here is the wrinkle that makes this clever. By compensating uncle miners, Ethereum reduced the economic penalty for being geographically distant or less well-connected. A small miner who consistently found valid blocks but lost propagation races was no longer fully punished. This flattened, at least partially, the centralisation gradient that plagued Bitcoin mining.
The GHOST weighting also meant that uncle blocks contributed to the canonical chain's weight for fork-choice purposes. When the network evaluated which chain was the heaviest, uncle references added to the score. An attacker trying to build a secret competing chain could not simply ignore the uncle-inclusive weight of the honest chain.
A concrete scenario: what a 15% uncle rate actually means
Suppose a hypothetical Ethereum network is processing roughly 6,500 canonical blocks per day, a plausible figure during high-congestion periods under proof-of-work. A 15% uncle rate means approximately 975 uncle blocks produced in that same day. Each one represents real electricity, real hardware, real time spent solving a puzzle that didn't make the cut.
Now consider a miner controlling 30% of total hashrate. On a zero-uncle network, they need to race to 51% to threaten consensus. On a 15%-uncle network, the honest miners' effective contribution to the canonical chain is reduced. The attacker's own uncles also reduce their effective power, but if they operate a tightly coordinated private pool with superior internal propagation, they can keep their own uncle rate near zero while the honest network's uncle rate stays elevated. Their 30% of raw hashrate then translates to a higher percentage of canonical chain weight than the number implies. This is not hypothetical paranoia. It is the quantitative basis on which mining pool operators ran profitability models.
The honest counterweight is that Ethereum's block time ran roughly 13 to 15 seconds, much faster than Bitcoin's 10 minutes. Faster blocks mean more opportunities to confirm transactions, but they also mean propagation delays represent a larger fraction of the block interval. That is exactly why uncle rates ran higher on Ethereum than on Bitcoin historically.
What people get wrong about uncle blocks and the Merge
The most common misconception is that uncle blocks were purely a nuisance, a sign of inefficiency to be minimised. They were also, counterintuitively, a security signal. A sudden drop in uncle rate could indicate that the mining population was consolidating into fewer, better-connected pools rather than becoming more efficient. A spike could indicate a network partition or a propagation attack in progress. Monitoring uncle rates was a legitimate on-chain health metric (and, frankly, the part most retrospectives skip entirely).
The second misconception is that the Merge simply eliminated the problem by switching to proof-of-stake. It did eliminate uncle blocks as a category, because proof-of-stake validators are assigned attestation slots deterministically and the fork-choice rule, LMD-GHOST, which inherits some of the same conceptual DNA, handles equivocating validators through slashing rather than partial rewards. But the underlying tension between propagation latency and consensus security didn't vanish. It transformed. Under proof-of-stake, a validator who misses their attestation window due to latency simply loses the attestation reward entirely, a different kind of penalty that creates its own centralisation pressure toward low-latency, professionally operated nodes.
Still, the scale of the change is real. Post-Merge Ethereum has no uncle blocks. The partial-reward mechanism, the GHOST weighting, the uncle-rate monitoring: all retired. What replaced them is a validator set with deterministic slot assignments, where the equivalent of an uncle is a missed slot recorded on-chain and penalised in fractions of ETH rather than rewarded in fractions.
Uncle blocks were Ethereum's proof-of-work era compromise. An elegant patch on a genuine structural vulnerability, one that reduced centralisation pressure and blunted selfish-mining incentives without fully eliminating either. Engineers who designed the Merge knew exactly what they were replacing, and the slashing conditions baked into proof-of-stake reflect the lessons that years of uncle-rate data taught them.