Uncle Blocks

Uncle blocks — also called ommers — are valid blocks that were mined at the same height as a canonical block but did not make it onto the main chain. They are a feature of Ethereum's old proof-of-work design, where two miners frequently solved a block at nearly the same time and the protocol rewarded the "losing" valid block to compensate for propagation delay and discourage centralization. Polygon PoS does not work this way. Blocks on chain 137 are produced by a rotating set of Bor validators on a deterministic schedule rather than by a mining race, so there is no competition to win a block slot and therefore no stream of stale-but-valid sibling blocks to fold back in. The practical answer for Polygon developers is: uncle blocks effectively do not occur, and the uncle-related RPC fields exist only for Ethereum compatibility. The rest of this guide explains what that means and how the uncle methods behave when you call them against https://polygon.therpc.io/YOUR_API_KEY.

Understanding Uncle Blocks

• What would cause an uncle — and why it does not on Polygon: On a proof-of-work chain, an uncle appears when two miners produce valid blocks at the same height and one loses the race. Polygon has no such race: Bor selects a single validator to produce each ~2-second block in turn, so there is no parallel competition and effectively no valid sibling blocks to become uncles. The rare shallow reorg that does happen simply discards the orphaned block — it is not preserved or rewarded as an uncle.
• Why uncles exist in the protocol at all: The uncle concept comes from Ethereum PoW, where it offset network propagation latency and reduced the centralizing advantage of well-connected miners by paying out blocks that arrived a moment late. Polygon inherits the Ethereum block fields and JSON-RPC surface for compatibility, which is why the uncle methods exist, but the underlying PoW incentive they served does not apply to Bor.
• Reward structure on Polygon: There is no uncle reward on Polygon. Validators are compensated through staking rewards and the priority-fee tips on the blocks they actually produce, paid in MATIC — there is no separate payout for stale or sibling blocks because none are produced. This differs fundamentally from Ethereum PoW, where uncle and uncle-inclusion rewards were a real part of miner income.
• Effect on security and chain quality: Polygon's security comes from staked validators and periodic Heimdall checkpoints to Ethereum L1, not from an uncle mechanism. Chain quality is measured by checkpoint cadence and the shallowness of reorgs rather than by an uncle rate, so on chain 137 a healthy chain is one with a steadily advancing head and timely checkpoints.

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 Ethereum PoW, a high uncle rate signaled contention and argued for more confirmations. On Polygon, base your confirmation thresholds on shallow Bor reorgs and Heimdall checkpoint finality instead — uncles play no part. Wait a handful of blocks for small MATIC actions and a checkpoint for high-value settlement, and ignore uncle count entirely as a finality signal.
• "Uncle rate" on Polygon: The healthy uncle rate on chain 137 is effectively zero, and the calculateUncleRate example will return 0 across any normal block range because Bor blocks carry no uncles. If you want a health metric, monitor reorg depth and checkpoint timing rather than uncle rate, which conveys no information here.
• Mining profitability: There is no mining and no uncle reward to model on Polygon. Validator economics are staking rewards plus MATIC priority tips on produced blocks; do not carry over any Ethereum PoW uncle-reward term into Polygon profitability math, as it would simply be zero and misleading.
• Parsing uncle references: Expect block.uncles to be an empty array and eth_getUncleCountByBlock* to return zero on Polygon. Write block-parsing code that handles an empty uncle list gracefully and does not assume web3.eth.getUncle will ever return data on chain 137 — treating a missing uncle as the normal case keeps your Ethereum-compatible code correct without special-casing failures.

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