Block Confirmations

On Arbitrum One the sequencer hands back a soft confirmation in well under a second, which feels instant but is not the same as irreversible settlement — economic finality only arrives once the transaction's batch is posted to Ethereum L1 and clears the rollup's challenge window. Confirmations are how you measure the distance between "the sequencer accepted it" and "this can no longer be reversed," and getting that distinction right is what keeps an exchange deposit, a bridge withdrawal, or a high-value swap on GMX or Uniswap from acting on state that could still change. This guide shows you how to count confirmations against https://arbitrum.therpc.io/YOUR_API_KEY, pick value-appropriate thresholds, and wait for finality safely before releasing goods or crediting funds.

Understanding Confirmations

• What a confirmation is: A confirmation is one block built on top of the block containing your transaction. You count it as currentBlockNumber - transactionBlockNumber; zero means the transaction is included but no block sits above it yet.
• Why they matter: More confirmations mean more sequencer-published blocks would have to be discarded to undo your transaction, and ultimately the underlying batch moves closer to being settled on Ethereum L1. Confirmations are your proxy for how reversible a result still is.
• Recommended counts: Because Arbitrum One runs a single sequencer, low-value reads stabilize quickly — a handful of confirmations is fine for small transfers or UI updates. For mid-value operations wait for several dozen blocks, and for high-value flows (large bridge withdrawals, treasury moves) do not rely on confirmation depth alone — wait for the finalized tag, which tracks L1-backed state. Thresholds scale with value because the cost of acting on a reversed transaction scales with value.
• Mainnet vs testnets: On Arbitrum One mainnet, finality is anchored to Ethereum mainnet through batch posting and the challenge window. On the Arbitrum Sepolia testnet the same mechanics apply but settle against a test L1, so finality timing and reliability are weaker — never calibrate production confirmation thresholds on testnet behavior.

Implementation Examples

1// Check number of confirmations
2const getConfirmations = async (txHash) => {
3  const tx = await web3.eth.getTransaction(txHash);
4  const currentBlock = await web3.eth.getBlockNumber();
5  return tx.blockNumber ? currentBlock - tx.blockNumber : 0;
6};
7 
8// Wait for specific number of confirmations
9const waitForConfirmations = async (txHash, confirmations = 6) => {
10  while ((await getConfirmations(txHash)) < confirmations) {
11    await new Promise((resolve) => setTimeout(resolve, 1000));
12  }
13  return true;
14};

Security Considerations

• Thresholds by value: Tier your logic — near-zero confirmations for cosmetic UI feedback, a few blocks for small ETH transfers, dozens for significant DeFi positions, and the finalized tag for anything where a reversal would be costly to unwind. Codify the tiers rather than hard-coding one magic number.
• When a reorg invalidates a confirmation: If a transaction you had treated as confirmed disappears or moves, re-read its receipt; if eth_getTransactionReceipt returns null, treat it as no longer included, roll back any dependent state you wrote, and resubmit only after checking the nonce has not already been consumed.
• Network-specific factors: Required counts on Arbitrum One are shaped by the single-sequencer model (which makes shallow reorgs rare but not impossible before L1 settlement) and by the L1 challenge window that governs true finality — not by PoW-style block competition, since Arbitrum One produces no uncle blocks.
• Monitoring progress in production: Poll or subscribe to track currentBlock - txBlockNumber, surface live confirmation depth to the user, and trigger your business action only when the configured threshold (or the finalized tag) is reached, with a timeout and alert if a transaction stalls.

See also

• eth_getTransactionReceipt - Get transaction confirmation status
• Working with Blocks - General block handling
• Chain Reorganization Guide - Handling blockchain reorganizations