Uncle Block
Pronunciation: UHN-kuhl BLOCK
Also known as: Ommer Block, Ommer
Definition
An uncle block, more precisely called an ommer in historical Ethereum proof-of-work terminology, is a valid competing block that was not included in the canonical chain but was referenced by a later canonical block under the old protocol. Ommers received partial rewards and contributed to security accounting.
Overview
How it works
Under Ethereum’s former proof-of-work design, miners could create valid blocks at nearly the same height. Network delay caused one block to enter the Canonical Chain while another became a valid side block. A later canonical block could reference the side block as an ommer, commonly called an uncle, allowing limited recognition rather than treating all of its work as completely unrewarded.
An uncle was not the Parent Block of the referencing block and its transactions did not become canonical through the reference. The mechanism mainly rewarded useful proof-of-work and reduced the disadvantage faced by miners with slower propagation. Protocol rules limited ancestry, age, and reuse so the same ommer could not be claimed repeatedly.
The term is historical and should not be applied broadly to every stale or competing block. Bitcoin typically describes non-canonical mined blocks as stale blocks, while proof-of-stake Ethereum uses different consensus objects and fork-choice rules. After Ethereum’s transition to proof of stake, execution-layer block fields associated with ommers remain for compatibility, but no new proof-of-work ommer rewards are created.
Indexers handling historical Ethereum data should preserve ommer references and avoid counting their transactions as canonical execution. Analytics should distinguish canonical blocks, historical ommers, and generic Competing Chain blocks. Payment confirmation should always follow canonical-chain and finality status, never the existence of an uncle reference.
A reliable evidence trail includes the historical chain, block hash, height, referencing canonical block, reward data, and canonicality of its transactions. It becomes important because an ommer reference recognizes past proof-of-work but does not make its transaction execution part of accepted history. Operational controls should exclude ommer transactions from balances and apply modern proof-of-stake terminology to current Ethereum blocks.
What matters in practice
Historically, Ethereum's proof-of-work design recognized some valid but noncanonical near-tip blocks through an 'uncle' mechanism, partly compensating miners and influencing security incentives. After Ethereum moved to proof of stake, this historical terminology should not be taught as if new PoW uncle blocks still arrive on Ethereum mainnet. Other chains may use different stale-block reward rules. When reading historical data, distinguish an uncle's header from canonical transaction inclusion: transactions in a noncanonical block must not be treated as finalized customer payments.
Related glossary concepts
Example
An explorer of historical Ethereum data displays an uncle reference in an old PoW block. A merchant checking an archived transaction must verify the canonical transaction's later inclusion, not assume that appearing in an uncle proves payment.
Comparison
An uncle (historical Ethereum PoW terminology) is not equivalent to a canonical block, a reorged transaction or a proof-of-stake attestation.
Key Takeaway
An uncle or ommer was a rewarded non-canonical block in historical proof-of-work Ethereum, not a source of canonical transaction execution.
Sources
- Proof-of-Work Mining and Ommer Blocks — Ethereum.org (2026-08-02)
- Ethereum Glossary — Ethereum.org (2026-08-02)
- Proof-of-Stake (PoS) — Ethereum.org (2026-08-02)