Block Confirmations

On OP Mainnet, a transaction included by the sequencer appears almost instantly — blocks come every ~2 seconds — but "included" is not the same as "final". OP Mainnet is an optimistic rollup (chain ID 10) that settles to Ethereum L1, so a block's strongest guarantee comes only once its L1 batch is finalized; before that, recent blocks can still be reorged. That gap between fast inclusion and true finality is exactly why confirmation counting matters: act too early and you risk treating a transaction as settled when it could still vanish. This guide enables you to measure confirmations against the OP Mainnet head, pick safe thresholds by transaction value, and verify finality so your application commits irreversible actions only when it is truly safe.

Understanding Confirmations

• What a confirmation is: one confirmation is added each time a new OP Mainnet block is appended after the block containing your transaction. The count is simply the current head block number minus the transaction's block number, as the getConfirmations example shows. At ~2s per block, confirmations accrue quickly.
• Why they matter: each additional block deepens the transaction in the chain and raises the cost of it being reorged out. For the strongest assurance on this optimistic rollup, finality is reached when the block's batch is finalized on Ethereum L1 — local block depth is a proxy, L1 finalization is the real guarantee.
• Recommended counts: scale to value. For UI feedback or low-value actions, a small number of OP Mainnet blocks is fine; for meaningful transfers, wait for more depth; for high-value settlement, wait for L1 finalization rather than a fixed block count, because that is what removes reorg risk entirely.
• Mainnet vs testnets: OP Mainnet settles to Ethereum mainnet, while OP Stack testnets (such as OP Sepolia) settle to a testnet L1. The mechanics are identical, but never treat testnet finality timing or stability as representative — validate confirmation logic on OP Mainnet itself before relying on it for value.

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: define explicit tiers — low value clears at a few blocks, medium at deeper confirmation, and high value only after Ethereum L1 finalization of the block's batch. Tie the threshold to economic risk, not a single global constant.
• Reorg invalidation: if a previously counted transaction's block is reorged out, re-fetch the transaction by hash. If it is no longer present (its blockNumber is null or it moved to a new block), roll back any state you derived from it and re-evaluate it against the new canonical chain ID 10 history before acting again.
• Network-specific factors: OP Mainnet's single-sequencer design means rapid, regular ~2s inclusion, but true finality is paced by L1 batch submission and finalization. Required confirmation depth should reflect that L1-settlement timeline, not just the fast L2 block rate.
• Monitoring progress: poll or subscribe to track confirmation depth as the head advances, surface it to users for transparency, and alert if a transaction stops gaining confirmations — a sign the head has stalled or a reorg removed it.

See also

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