Uncle Blocks

Uncle blocks — also called ommer blocks — are valid blocks that were mined at the same height as the block that ultimately made it into the canonical chain, then lost the race and were set aside. They are a feature of proof-of-work chains like the old Ethereum mainnet, where multiple miners can find competing blocks at once. Base does not produce uncle blocks at all. As an OP Stack rollup, Base orders transactions through a single Coinbase-operated sequencer rather than competing miners, so there is no race at a given height and no orphaned siblings to record. This guide exists to make that explicit: the Ethereum JSON-RPC uncle methods still exist on Base for compatibility, but on this chain they have nothing to return — and the rest of this page explains why, and what those calls actually give back so your code handles them correctly.

Understanding Uncle Blocks

• What would make a block an uncle — and why it cannot happen here: an uncle arises when two miners produce valid blocks at the same height and one loses the race. Base has a single sequencer producing one block every ~2 seconds in a deterministic order, so two competing blocks at the same height never exist and no block is ever set aside as an uncle.
• Why uncles exist on PoW chains: on proof-of-work networks, propagation latency lets miners briefly mine on different heads; rewarding the orphaned-but-valid blocks as uncles compensated that wasted work and discouraged centralization. Base solves ordering through sequencing rather than competition, so this mechanism is simply not part of the protocol.
• Reward structure: there is no uncle reward on Base because there are no uncles. Base also has no mining block reward of the Ethereum-PoW kind — the sequencer earns transaction fees (paid in ETH) and the protocol covers L1 data-posting costs, with no analogue to a main-block-plus-uncle reward split.
• Security and chain quality: on Base, security and ordering integrity come from the OP Stack design — sequencer ordering plus settlement of batches onto Ethereum L1 — not from an uncle-reward incentive. Chain quality is measured by sequencer liveness and L1 finality, so the absence of uncles is expected and not a sign of any problem.

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: on PoW chains a high uncle rate signals contention and means you should wait more confirmations; on Base that consideration does not apply. Base block confirmations should instead be sized around shallow reorgs and, for high value, L1 settlement — uncles play no role in your confirmation policy here.
• Monitoring "uncle rate": a healthy uncle rate on Base is exactly zero, every block, by design. The calculateUncleRate helper above will return 0 because block.uncles.length is always 0 — useful only as a sanity check that your node is behaving normally, not as a tunable network metric.
• Mining profitability: there is no Base mining and no uncle reward, so uncle rewards never enter any profitability calculation. Economics on Base are about transaction-fee revenue and L1 data costs for the sequencer, not block-or-uncle mining rewards — do not port a PoW profitability model here.
• Parsing block data: expect block.uncles to be an empty array, eth_getUncleCountByBlockNumber and eth_getUncleCountByBlockHash to return "0x0", and eth_getUncleByBlockNumberAndIndex / eth_getUncleByBlockHashAndIndex to return null on Base. Write code that treats these as the normal, expected result — never assume an uncle object exists, and do not branch on uncle presence as if it were possible on this chain.

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