Block Confirmations

On Base, the Coinbase sequencer includes your transaction in a block within a second or two, but inclusion is not the same as finality. Until the block is deep enough — and ultimately until its batch is settled on Ethereum L1 — the head can still be rewritten by a shallow reorg, so anything irreversible you do on a single confirmation is at risk. Counting confirmations is how you trade waiting time for safety. This guide explains how confirmations work on this OP Stack rollup and gives you the code to count them, wait for a chosen threshold, and choose that threshold sensibly for the value at stake.

Understanding Confirmations

• What a confirmation is: a transaction has one confirmation when it lands in a block, and gains one more for every block mined on top. The count equals the current head number minus the transaction's block number, as the getConfirmations helper computes. At ~2s per Base block, confirmations accrue roughly every two seconds.
• Why they matter: each additional confirmation buries the transaction deeper, making it exponentially harder for a reorg to displace. More confirmations mean stronger practical finality — the security guarantee you are buying with wait time.
• Recommended counts: scale to value. A handful of confirmations is fine for low-value UI feedback; wait deeper for moderate amounts; and for high-value settlement, do not rely on confirmation depth alone — wait until the transaction's batch is confirmed on Ethereum L1, the point at which an OP Stack rollup is truly final.
• Mainnet vs. testnet: the same mechanics apply on Base mainnet (chain ID 8453) and Base Sepolia, but a testnet's sequencer and L1 settlement give weaker real-world guarantees, so never treat testnet finality as representative of mainnet safety for production decisions.

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: set tiered policies — low value clears on a few confirmations, mid value waits deeper, and high value waits for L1 settlement. Encode these tiers explicitly so a large transfer can never be released on the same shallow threshold as a trivial one.
• When a reorg invalidates a confirmation: re-fetch the transaction receipt; if blockNumber is now null or the transaction sits in a different block, treat it as un-confirmed, roll back any side effects you applied, and restart the confirmation count from the new block. Always re-check rather than trusting a previously cached count.
• Network-specific factors: Base finality ultimately depends on Ethereum L1 settlement, not just sequencer inclusion, so its security profile differs from an L1 chain. The single-sequencer model makes ordinary reorgs rare and shallow but means liveness tracks the sequencer; size confirmations with the L1 settlement path in mind.
• Monitoring progress: poll the confirmation count (as in waitForConfirmations) or drive it from a newHeads subscription, surface progress to users, and alert if a transaction stops gaining confirmations — a sign of a stalled sequencer or a reorg that needs manual attention.

See also

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