Block Confirmations

Seeing a transaction in the BNB Smart Chain mempool is not the same as settlement. It counts only once sealed into a block, and even a freshly sealed block can in theory be displaced before the network commits to it. Confirmations measure that commitment. Each subsequent block stacked on top makes reversal harder, and that is precisely why exchanges, bridges, and payment flows on BSC gate value-bearing actions behind a confirmation threshold. This guide covers three things: counting confirmations from a transaction receipt, waiting for a target depth before you credit funds, and choosing thresholds that fit BSC's roughly three-second blocks and PoSA fast finality instead of blindly copying Ethereum's defaults.

Understanding Confirmations

• What a confirmation is. It is the gap between the current head height and the block height that included your transaction. Subtract the receipt's blockNumber from eth_blockNumber and you have the live count, as the helper above does.
• Why they matter. A deeper transaction sits behind more validator-sealed blocks, so reversing it would mean unwinding all of them at once. Confirmations turn probabilistic inclusion into practical irreversibility.
• Recommended counts on BSC. Low-value transfers are generally safe at around three confirmations. Mid-value activity like a PancakeSwap trade sits comfortably near ten to twelve. Large bridge or treasury movements warrant fifteen or more. The logic is simple: the cost of a reversal climbs with the amount at stake, so bigger sums earn longer waits.
• Mainnet versus testnet. Mainnet (chainId 56) has a large, economically committed validator set plus PoSA fast finality, so a handful of confirmations holds up well. Testnet 97 runs on thinner validator participation and gets reset periodically. Treat its confirmations as a development convenience, never a security guarantee.

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

• Scale thresholds to value. Tie the required depth to the BNB amount or BEP-20 value in motion. A tiered policy that asks for more confirmations as exposure rises balances user experience against settlement risk far better than one fixed number ever will.
• Recover from a reorg. When a previously counted transaction vanishes because its block got replaced, mark any credit you issued as provisional, roll back the dependent state, then re-verify against the new canonical chain before you re-credit.
• Network-specific factors. Validator availability, momentary propagation delays, short-lived forks: each nudges the safe count. Heavy Venus or PancakeSwap load that fills blocks can also delay inclusion, so widen thresholds when the chain is congested.
• Monitor in production. Poll the receipt on an interval and expose current-versus-target confirmation depth as a metric. Alert when a watched transaction stalls or its including block hash changes, and confirm finality on bscscan.com during reconciliation.

See also

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