Uncle Block (Ommer)

What Is an Uncle Block?

An uncle block is a valid block that was successfully mined but did not become part of the blockchain's canonical chain. This happens when two miners solve a block at nearly the same moment. Both blocks are valid, but the network can only extend one of them. The block that gets included in the longest (or heaviest) chain becomes canonical, while the other becomes an uncle.

The term "uncle" comes from a family-tree analogy: these blocks share a common ancestor (a grandparent block) with the canonical block but sit on a sibling branch. The Ethereum community later adopted the gender-neutral term "ommer" (meaning a parent's sibling regardless of gender), though "uncle block" remains the more widely recognized name.

Uncle blocks are distinct from orphan blocks in Bitcoin. While Bitcoin discards stale blocks entirely with no reward, Ethereum (during its proof-of-work era) explicitly recognized uncle blocks in its consensus mechanism and paid partial rewards to their miners.

How It Works

Uncle blocks are a natural consequence of short block times combined with network latency. Ethereum's proof-of-work block time averaged 13 to 15 seconds, compared to Bitcoin's 10 minutes. This meant that block propagation delays represented a much larger fraction of the block interval, making it common for multiple miners to find valid solutions before learning about each other's work.

The Fork Resolution Process

1. Two miners independently solve valid blocks at roughly the same height
2. Both blocks propagate through the peer-to-peer network, creating a temporary fork
3. Different nodes receive the blocks in different order, briefly following different chain tips
4. When the next block is mined, it extends one of the two competing blocks, resolving the fork
5. The block that was not extended becomes an uncle: valid but not canonical

Uncle Reward Formula

Ethereum paid uncle block miners a partial block reward based on how quickly the uncle was referenced by a subsequent canonical block. The formula:

uncle_reward = ((8 - D) / 8) * base_block_reward

// D = including_block_number - uncle_block_number
// D must be between 1 and 6 (inclusive)

With a 2 ETH base block reward (post-Constantinople), the uncle rewards by distance:

Nephew Reward

The miner who included an uncle block reference in their canonical block also received a "nephew reward" of 1/32 of the base block reward. With a 2 ETH reward, this was 0.0625 ETH per uncle included. Each canonical block could reference a maximum of 2 uncle blocks, and each uncle could only be referenced once. This incentivized miners to include uncle references rather than ignoring them.

Protocol Constraints

• Maximum uncle depth: 6 blocks back from the including block
• Maximum uncles per block: 2 uncle headers per canonical block
• An uncle must be a direct child of an ancestor (up to 6th generation) of the including block
• An uncle cannot itself be an ancestor of the including block

The GHOST Protocol

Ethereum's handling of uncle blocks was inspired by the GHOST protocol (Greedy Heaviest Observed Subtree), introduced by Yonatan Sompolinsky and Aviv Zohar in 2013. While Bitcoin uses the longest chain rule (most cumulative proof of work in a single chain), GHOST selects the chain whose entire subtree, including uncle blocks, has the most cumulative work.

This approach solved a critical problem with short block times. Under a pure longest-chain rule, large mining pools with well-connected nodes would have an outsized advantage: their blocks would propagate faster, reducing their uncle rate and concentrating rewards. Smaller miners would produce more uncles and earn less per hash, creating a feedback loop toward mining pool centralization.

By counting uncle blocks toward the weight of the subtree they belong to, GHOST ensured that a miner's honest work contributed to chain security even when their block lost the propagation race. Ethereum implemented a modified version of GHOST rather than the full protocol, but the principle of recognizing and rewarding uncle blocks remained central to its proof-of-work design.

Uncle Blocks vs. Orphan Blocks

Bitcoin and Ethereum handled competing blocks very differently during their respective proof-of-work eras:

Bitcoin's long block time makes stale blocks rare enough that the lack of rewards is not a significant centralization concern. For more on how block timing affects network security, see the research on mining centralization risks.

Historical Uncle Rate

During Ethereum's proof-of-work era, the uncle rate provided insight into network health and propagation efficiency:

• Early Ethereum (2015): approximately 7.4% uncle rate across the first 280,000 blocks
• Peak period (2017 to 2018): uncle blocks reached as high as 2,000 per day during periods of high network congestion
• Post-Constantinople (2019): uncle rate stabilized around 6 to 7% with approximately 250 uncle blocks per day
• Post-Merge (September 2022 onward): uncle rate dropped to 0%, as the concept no longer applies under proof of stake

Block Reward History

Uncle rewards scaled proportionally with Ethereum's base block reward, which changed over time:

• Genesis to Byzantium (October 2017): 5 ETH per block
• Byzantium (EIP-649): reduced to 3 ETH per block
• Constantinople (EIP-1234, February 2019): reduced to 2 ETH per block

At each stage, uncle miners received the same fractional share. A D=1 uncle was always worth 7/8 of whatever the current base reward was.

The Merge and the End of Uncle Blocks

Ethereum's transition from proof of work to proof of stake on September 15, 2022 (known as "The Merge") eliminated uncle blocks entirely. Under proof of stake, validators are deterministically selected to propose blocks for each 12-second slot. There is no mining race, so competing blocks for the same slot can only occur through validator misbehavior, which is handled by slashing rather than uncle rewards.

Per EIP-3675, post-Merge blocks must contain an empty uncle list. The ommers field is set to an empty array, and the ommersHash field is set to a constant value (the Keccak-256 hash of an RLP-encoded empty list). These fields remain in the block header for backward compatibility but carry no functional meaning.

The fork-choice rule also evolved: Ethereum now uses LMD-GHOST (Latest Message Driven GHOST) combined with Casper FFG, where validator attestations replace mining-based subtree weight for determining the canonical chain.

Why It Matters

Uncle blocks illustrate a fundamental tension in blockchain design: shorter block times improve user experience and throughput but increase fork rates and centralization pressure. Ethereum's uncle reward mechanism was an elegant solution that compensated miners for honest work even when their blocks did not make it into the canonical chain.

This same tension drives innovation in layer-2 scaling solutions. Protocols like the Lightning Network and Spark move transactions off-chain entirely, avoiding the block propagation race altogether. Rather than trying to reduce uncle rates through larger rewards or faster propagation, off-chain protocols sidestep the problem by settling transactions without requiring every payment to compete for block space.

Understanding uncle blocks also helps contextualize how different consensus mechanisms handle the tradeoff between speed and finality. Bitcoin accepts slower confirmation times to minimize stale blocks, Ethereum (pre-Merge) used uncle rewards to compensate for faster times, and modern proof-of-stake systems eliminate the problem through deterministic block production.

Risks and Considerations

Centralization Pressure

Even with uncle rewards, larger mining pools still had an advantage. Well-connected pools produced fewer uncles and captured a higher share of full block rewards. Research from 2018 found that during peak uncle production, certain large mining operations captured a disproportionate share of uncle rewards through strategic network positioning.

Uncle Manipulation

Miners could potentially withhold blocks to publish them as uncles later, earning the partial uncle reward while disrupting competitors. Although the reward reduction (uncle miners earned less than full block miners) made this strategy generally unprofitable, the incentive structure was not perfectly aligned in all scenarios.

Network Congestion Effects

Higher uncle rates indicated network strain. When blocks took longer to propagate (due to larger block sizes or higher gas limits), more miners would find competing solutions before learning about existing ones. Monitoring uncle rates served as an indirect health metric for Ethereum's proof-of-work network.

Historical Relevance

Since The Merge, uncle blocks are purely a historical concept on Ethereum. JSON-RPC methods like eth_getUncleCountByBlockHash still exist for backward compatibility but return zero for all post-Merge blocks. Developers working with historical Ethereum data should account for uncle block rewards when calculating pre-Merge mining economics.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.