Chain Reorganizations

A chain reorganization, or reorg, happens when the block your application saw as the head of Base gets replaced by a different block at the same height, so the canonical history is rewritten and some transactions you thought were included move, change order, or vanish. On Base this is far less common than on a proof-of-work chain because a single Coinbase-operated sequencer orders transactions, so there is normally no competing fork at the L2 head — most reorgs you encounter are shallow, affecting only the most recent block or two, and stem from propagation timing or the L1 derivation pipeline rather than miners racing. Rare as they are, they are not impossible, and if your app credits a balance, fires a webhook, or updates a database the moment it sees a transaction, a reorg can leave your off-chain state describing a chain that no longer exists. That is why any backend or dApp reading the Base head must detect reorgs and recover from them rather than assume the head is permanent.

Understanding Reorgs

• Causes on Base: with one sequencer ordering transactions, classic miner-versus-miner forks do not occur at the L2 head. Reorgs here come from propagation timing and from how the OP Stack derives the canonical chain from data posted to Ethereum L1 — a brief divergence in what a node believes is the head, resolved as it follows the canonical sequence.
• Shallow vs. deep: shallow reorgs touching only the last block or two are the realistic case on Base; deep reorgs are extremely unlikely given the single-sequencer model and L1 settlement. Build for shallow reorgs as the norm and treat anything deeper as an incident worth alerting on.
• Effect on transactions: a reorg can return a pending transaction to the mempool, place a recently confirmed transaction in a different block, or reorder transactions within the rewritten range — which can also flip the success or revert outcome of a dependent call. Any state you derived from those blocks must be re-derived.
• JSON-RPC detection signals: at the RPC level a reorg shows up when the parentHash of a new block does not match the hash of the block you last processed, when the block at a known height returns a different hash than before, or when a transaction receipt's blockNumber changes or becomes null. The monitorReorgs and findCommonAncestor helpers below build on exactly these signals.

Implementation Examples

1// Monitor for reorgs
2const monitorReorgs = async (callback, checkInterval = 5000) => {
3  let lastBlock = await web3.eth.getBlockNumber();
4  let lastBlockHash = (await web3.eth.getBlock(lastBlock)).hash;
5 
6  return setInterval(async () => {
7    const currentBlock = await web3.eth.getBlockNumber();
8    const currentBlockHash = (await web3.eth.getBlock(lastBlock)).hash;
9 
10    if (currentBlockHash !== lastBlockHash) {
11      // Reorg detected
12      callback({
13        oldBlock: lastBlock,
14        oldHash: lastBlockHash,
15        newBlock: currentBlock,
16        newHash: currentBlockHash,
17      });
18    }
19 
20    lastBlock = currentBlock;
21    lastBlockHash = currentBlockHash;
22  }, checkInterval);
23};
24 
25// Get common ancestor block
26const findCommonAncestor = async (hash1, hash2) => {
27  let block1 = await web3.eth.getBlock(hash1);
28  let block2 = await web3.eth.getBlock(hash2);
29 
30  while (block1.number > block2.number) {
31    block1 = await web3.eth.getBlock(block1.parentHash);
32  }
33  while (block2.number > block1.number) {
34    block2 = await web3.eth.getBlock(block2.parentHash);
35  }
36  while (block1.hash !== block2.hash) {
37    block1 = await web3.eth.getBlock(block1.parentHash);
38    block2 = await web3.eth.getBlock(block2.parentHash);
39  }
40  return block1;
41};

Mitigation Strategies

• Confirmation depth: wait enough Base block confirmations before treating a transaction as settled — a few blocks for low-value actions, and for high-value flows wait until the transaction's batch is confirmed on Ethereum L1, where the OP Stack rollup is truly final and beyond reorg.
• Detecting reorgs: in a polling system, on each tick re-fetch the head and compare its parentHash to the last hash you stored, as in monitorReorgs; in a subscription system, check parentHash continuity on every newHeads event. Either way, on a mismatch use findCommonAncestor to locate where the old and new chains diverge.
• Resubmission without double effects: when a transaction is orphaned back to the mempool, it usually re-includes on its own; only resubmit with the same nonce if it is genuinely dropped, never as a fresh transaction, so you do not double-spend. Guard every off-chain side effect with an idempotency key tied to the transaction hash so a re-inclusion cannot apply the same effect twice.
• Restoring consistency: after detecting the divergence point, roll back the side effects of every orphaned block above the common ancestor, then reprocess the new canonical blocks from that ancestor forward. Keep enough recent block history buffered to perform this rollback cleanly.
• Listeners vs. polling: prefer a newHeads subscription for prompt detection at Base's ~2s cadence, since it pushes each new head immediately; fall back to polling for backfill and as a safety net when the WebSocket connection drops. Combining both gives low latency plus resilience against missed events.

See also

• eth_getBlockByHash - Retrieve block by hash
• Block Confirmations Guide - Understanding transaction finality
• Working with Blocks - General block handling