Uncle Blocks

An uncle block — ommer in the protocol's gender-neutral terminology — is a valid block that was mined but lost the race to be the canonical block at its height. It's a real, well-formed block; it just didn't make it onto the main chain. The distinction only existed under Proof-of-Work, when two miners could solve a block at nearly the same time and one had to lose. The canonical chain could then reference the loser as an uncle.

Here's the part that trips people up on chain 1 today: uncle blocks are a Proof-of-Work artifact, and Ethereum left Proof-of-Work at The Merge in September 2022 (block 15537393). Under Proof-of-Stake, exactly one validator proposes one block per 12-second slot — there's no mining race to lose, so no uncles are produced. The mechanism's purpose under PoW was to reward miners for valid-but-stale work, which reduced the centralizing advantage of fast block propagation and kept the chain secure. Uncle methods still return meaningful data for historical pre-Merge blocks; for everything after, they report an empty list.

Understanding Uncle Blocks

• What made a block an uncle. Under Proof-of-Work, two miners occasionally solved a valid block at the same height within the propagation window. The fork-choice rule kept one as canonical; the other was a valid but stale block. The canonical chain could then include up to two such blocks per block as uncles, recording the work that didn't win.
• Why the protocol bothered. Block propagation across a global network isn't instant, so a miner with worse connectivity would lose more races through no fault of their hashpower. Rewarding uncles compensated that, which blunted the advantage of the best-connected pools and discouraged centralization, while the extra referenced blocks added weight that reinforced the canonical chain's security.
• The reward, and how it differed. A full canonical PoW block paid the standard block reward plus fees. An uncle paid a reduced reward that decayed with how many blocks back it was referenced, and the including block earned a small bonus for citing it. The uncle's transactions were not executed and earned no fees — only the block reward portion applied. None of this exists post-Merge, where validators earn issuance and tips for the one block they propose per slot.
• Effect on chain quality. A high uncle rate under PoW signaled propagation stress and meant security weight was being spread across competing branches rather than concentrated on one chain. Post-Merge this metric is gone: with one block per slot and no mining competition, sha3Uncles is the empty-list hash and the uncle count is 0x0 for every block after 15537393.

Implementation Examples

1// Get uncle count for a block
2const getUncleCount = async (blockNumber) => {
3  const block = await web3.eth.getBlock(blockNumber);
4  return block.uncles.length;
5};
6 
7// Get uncle block by index
8const getUncleBlock = async (blockNumber, uncleIndex) => {
9  return await web3.eth.getUncle(blockNumber, uncleIndex);
10};
11 
12// Monitor uncle rates
13const calculateUncleRate = async (blockRange = 100) => {
14  const latestBlock = await web3.eth.getBlockNumber();
15  const startBlock = latestBlock - blockRange;
16 
17  let totalUncles = 0;
18  for (let i = startBlock; i <= latestBlock; i++) {
19    const uncleCount = await getUncleCount(i);
20    totalUncles += uncleCount;
21  }
22 
23  return totalUncles / blockRange;
24};

Best Practices

• Confirmation safety no longer hinges on uncles. Under PoW, a high uncle rate meant the head was contested and confirmations were softer than their count implied. Post-Merge that reasoning is obsolete — base safety on the safe and finalized tags instead. For any historical analysis of pre-Merge blocks, do treat a stretch with many uncles as a period where head blocks were less settled.
• Monitor uncle rate only for historical context. A "healthy" PoW-era uncle rate sat in the low single-digit percent of blocks; spikes flagged network propagation problems. If you're indexing the pre-Merge chain you can compute it from uncle counts over a block range, but for live chain 1 the rate is flatly zero, so a live uncle-rate monitor will only ever read 0 and isn't worth running.
• Profitability math is now staking math. Uncle rewards only factor into pre-Merge mining accounting, where you'd add decayed uncle rewards and inclusion bonuses to canonical block rewards and fees. There's no mining on Ethereum today; validator economics are issuance plus priority tips plus any MEV, with no uncle component at all.
• Parse uncle fields defensively across the Merge boundary. When reading block data, expect a populated uncles array and a non-empty sha3Uncles only for blocks below 15537393. For anything at or after The Merge, uncles is empty and sha3Uncles is the empty-list hash — don't write code that assumes uncles are always present, or that treats their absence as an error.

See also

• eth_getUncleByBlockHashAndIndex - Retrieve uncle block by hash and index
• eth_getUncleByBlockNumberAndIndex - Retrieve uncle block by number and index
• Working with Blocks - General block handling