Block Confirmations

A confirmation tells you how deeply a transaction is buried beneath the current Avalanche C-Chain tip, and that depth is your practical measure of how safe it is to act on. Avalanche reaches finality through Snowman consensus in roughly one to two seconds, so a transaction is irreversible far faster than on a proof-of-work chain — but a transaction that is merely submitted is not the same as one that is final, and treating the two as equal is how applications credit value that later disappears. This guide shows you how confirmations are counted on the C-Chain via https://avalanche.therpc.io/YOUR_API_KEY, and how to implement confirmation checks and value-scaled finality thresholds so your application only releases goods or credits balances once a transaction is genuinely settled.

Understanding Confirmations

• What it is: a confirmation is one block built on top of the block that contains your transaction. The count equals the current C-Chain height minus the transaction's block number; a transaction in the latest block has zero confirmations, and each new ~1-2s block adds one.
• Why it matters: more confirmations means more consensus weight behind the block, making reversal progressively harder. On Avalanche, Snowman finality means that weight accumulates almost immediately, so a confirmed transaction is effectively permanent within a second or two.
• Recommended counts: because finality is near-instant, the C-Chain needs far fewer confirmations than PoW chains. A small number suffices for everyday transfers; scale up the safety margin for high-value settlement, where the cost of being wrong justifies waiting until the height is well below the finalized tip.
• Mainnet vs testnet: the C-Chain mainnet (chainId 43114) and the Fuji testnet run the same Snowman consensus and finality behavior, but Fuji's validator set and traffic differ, so treat its timing and stability as a development convenience, not a measurement you can transfer one-to-one to mainnet.

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 confirmation requirements proportional to what is at risk. Low-value or reversible actions can proceed after a couple of C-Chain confirmations; high-value or irreversible settlement should wait until the transaction's height sits comfortably below the finalized tip, trading a second or two of latency for certainty.
• If a reorg invalidates a confirmation: although Snowman finality makes this exceedingly rare on Avalanche, handle it anyway — re-check the transaction receipt, confirm the transaction still appears in the canonical chain at the expected block, and if it was orphaned, reverse any dependent state and treat the transaction as pending again.
• Network factors: required counts depend on transaction value, current C-Chain load and base fee conditions, and whether you are on mainnet (43114) or Fuji. Heavier network activity or fee spikes can delay inclusion, so confirm inclusion before you even begin counting confirmations.
• Monitoring progress: in production, poll the receipt and compute confirmations as tip-minus-block-number, surface the live count to users for high-value flows, and set a timeout that flags a transaction as stuck if it has not gained confirmations within a reasonable window so you can resubmit with a higher fee.

See also

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