BNB Smart Chain

BNB Smart Chain

Uncle Blocks

On a proof-of-work network, an uncle (or ommer) is a valid block that two miners produced at nearly the same height. Only one wins the canonical slot; the runner-up is recorded as an uncle so its proposer still collects a partial reward. BNB Smart Chain does not work that way. BSC runs Proof-of-Staked-Authority (PoSA) consensus, where a small rotating set of validators takes scheduled turns sealing blocks roughly every three seconds. One authorized validator owns each slot, so no two competing blocks ever get mined for the same height, and BSC produces no uncle blocks at all. The Ethereum-compatible uncle fields stick around purely for tooling parity, not because the original goal of rewarding stale PoW work means anything here.

Understanding Uncle Blocks

• No conditions produce one. The validator assigned to a height is the only party PoSA permits to seal it, so the simultaneous-discovery scenario behind a PoW uncle simply never arises on chainId 56 or testnet 97.
• Propagation latency is absorbed elsewhere. PoW chains tolerate uncles to soak up gossip delay. BSC handles a late or missing turn through validator rotation and slashing instead, so latency never spawns an orphaned-but-rewarded block.
• There is no uncle reward. A validator collects gas fees from the block it seals plus any protocol incentives tied to its stake. Stale blocks do not exist, so there is no separate, reduced ommer payout to distribute the way Ethereum once did.
• Chain quality comes from finality, not uncle inclusion. PoW security leans partly on uncle rate as a health metric. The equivalent signal on BSC is fast deterministic finality: validator attestations confirm a block within a couple of slots, rather than the chain relying on accumulated uncle weight.

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 does not depend on uncles here. BSC never reorganizes around competing siblings, so base your confirmation counts on fast PoSA finality instead of discounting for uncle-driven instability the way you would on Ethereum mainnet.
• Expect a flat zero uncle rate. A "healthy" rate on BSC is just zero. Run the calculateUncleRate helper above against bscscan.com block ranges and it should return 0 every time; any non-zero result points to a malformed response, not real ommers.
• Drop uncle rewards from profitability math. Model validator economics for BSC from sealed-block gas revenue and staking returns only. Bolt on an Ethereum-style uncle-reward term and you will overstate income, because no such payout exists.
• Parse the empty array defensively. block.uncles is reliably an empty array on BSC. Guard against code that assumes entries exist, and skip eth_getUncleByBlockNumberAndIndex in loops where the count is always zero.

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