Chain Reorganizations

A chain reorganization on Arbitrum One is any event where the canonical sequence of blocks your node had accepted gets revised — a block you saw at a given height is replaced, so the transactions inside it are re-ordered, deferred, or dropped. Unlike a proof-of-work network where competing miners routinely orphan each other's blocks, Arbitrum One runs a single Nitro sequencer, so day-to-day deep reorgs are rare; the realistic causes are sequencer-side reordering before a batch is posted, node-level revisions while catching up, and the fact that L2 ordering is only economically locked in once the batch settles on Ethereum L1 and clears the challenge window. Reorgs are infrequent here, but when one does land it can leave your application crediting a balance, marking an order filled, or firing a webhook based on a transaction that no longer exists on the canonical chain — which is why backend and dApp code reading from https://arbitrum.therpc.io/YOUR_API_KEY must detect and recover from them rather than assume the latest block is permanent.

Understanding Reorgs

• Causes: On Arbitrum One reorgs stem from the sequencer reordering or revising unposted L2 blocks, from a node reconciling its view during sync, and ultimately from the rollup design where L2 state is provisional until its batch is posted to and finalized on Ethereum L1. There is no PoW-style race between competing forks and no uncle/ommer blocks.
• Shallow vs. deep: Practically all reorgs you will see here are shallow — affecting only the most recent, not-yet-finalized blocks. Deep reorgs of already L1-settled state would require a successful challenge against the rollup and are effectively a non-event in normal operation, so design for shallow reorgs near the chain tip.
• Effect on transactions: A reorg can push a "confirmed" transaction back to pending, change the block it lands in, alter its position relative to other transactions, or drop it entirely if it was replaced. Any state you derived from its receipt — balances, event-driven actions — becomes stale.
• Detection signals: At the JSON-RPC level you detect a reorg when the hash for a height you already recorded changes, when consecutive blocks fail the parentHash linkage check, or when eth_getTransactionReceipt for a transaction you tracked starts returning null. Comparing the finalized block tag against latest tells you which portion of the chain is still revisable.

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

• How many confirmations: For routine operations wait until a transaction is several dozen blocks deep; for high-value or irreversible actions wait for the finalized tag rather than a raw confirmation count, since only L1-settled state is immune to a reorg on Arbitrum One.
• Detecting reorgs: In a polling system, store the hash of each height you process and compare it on the next poll — a mismatch signals a reorg. In a subscription system, verify each incoming header's parentHash matches the hash of the block you last accepted; a break in that chain is your trigger.
• Resubmission without double-spending: Before resubmitting a dropped transaction, check the sender's nonce with eth_getTransactionCount — if the nonce already advanced past the transaction, it (or a replacement) landed and you must not send again. Resend with the same nonce to replace-by-fee rather than creating a second, independent transaction.
• Restoring consistency: Walk the parent chain back to the common ancestor (as in findCommonAncestor above), roll back every state change derived from blocks above that ancestor, then replay against the new canonical blocks so balances, order status, and emitted events match the chain again.
• Listeners vs polling: Use a newBlockHeaders WebSocket subscription for low-latency detection at the chain tip, where sub-second Arbitrum One blocks make polling wasteful; fall back to interval polling for backfilling, reconnection recovery, or environments where a persistent socket is impractical.

See also

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