Uncle Blocks

Uncle blocks — also called ommer blocks — are valid blocks that were mined at nearly the same height as another block on a proof-of-work chain like Ethereum's original execution layer, lost the race to become canonical, but were still referenced and lightly rewarded to compensate for propagation latency. Arbitrum One does not work this way and produces no uncle blocks at all. It is an Optimistic Rollup built on the Nitro stack with a single sequencer ordering transactions, so there is no competition between miners to win a block and therefore no stale, near-miss blocks to reference. As a result the uncles array on every Arbitrum One block is empty, the uncle-related JSON-RPC methods return null or zero, and there is no uncle reward to account for. This guide exists to explain that reality clearly — so you understand why the uncle methods behave the way they do on chain ID 42161 and do not build logic around a mechanism that never fires here.

Understanding Uncle Blocks

• Conditions on Arbitrum One: None. An uncle arises when two miners independently produce valid blocks at the same height and one loses the canonical race. Arbitrum One has a single sequencer assembling one ordered chain, so no two competing blocks ever exist at the same height and no block can become an uncle.
• Why the concept exists elsewhere: On proof-of-work networks uncles compensate for network propagation latency and discourage centralization by rewarding miners whose otherwise-valid blocks arrived a moment too late. That security incentive is meaningful only when blocks compete — a situation that does not arise under Arbitrum One's sequencer model.
• Reward structure: There is no uncle reward on Arbitrum One. There is no PoW block reward to begin with; the sequencer earns from transaction fees (the L2 execution plus L1 calldata-posting cost paid in ETH), and no separate ommer-inclusion reward exists.
• Security and chain quality: Arbitrum One's security comes from settling its ordered batches to Ethereum L1 and the optimistic challenge window, not from uncle inclusion. Chain quality here is measured by L1 finality and sequencer correctness, so the absence of uncles takes nothing away from its security model.

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 a PoW chain a high uncle rate signals contention and argues for more confirmations. That signal does not exist on Arbitrum One — base your confirmation thresholds on sequencer depth and, for high-value flows, on the finalized (L1-settled) tag instead of any uncle-rate consideration.
• Uncle rate to expect and monitor: The healthy and expected uncle rate on Arbitrum One is exactly zero. If you run the calculateUncleRate helper above against https://arbitrum.therpc.io/YOUR_API_KEY it will return 0; treat any nonzero result as a bug in your parsing or node, not a property of the network.
• Mining profitability: There is no uncle reward and no PoW mining on Arbitrum One, so uncle rewards never enter a profitability calculation here. Drop any uncle-reward term entirely when porting Ethereum mainnet mining math to this chain.
• Parsing uncle references: When reading block data, expect block.uncles to be an empty array, eth_getUncleCountByBlock* to return "0x0", and eth_getUncleByBlock* to return null. Write defensive code that handles those empty/null results gracefully rather than assuming an uncle object will be present.

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