Blockchain Confirmations: Why Your Deposit Waits
What a confirmation is, why different chains need different numbers of them, what a reorganisation actually does, and how to choose a depth for a payments system.
In short
A confirmation is a block built on top of the one containing your transaction. More confirmations make reversal more expensive, which is why deposits wait. The right number depends on the chain, not on caution.
Every crypto deposit interface shows something like "8/12 confirmations", and almost nobody explains what is being counted or why the wait exists. It is worth understanding, because the alternative — crediting instantly — is a well-known way to lose money.
What a confirmation is
When your transaction is included in a block, it has one confirmation. Each subsequent block built on top adds another. That is the whole definition.
The number matters because inclusion in a block is not permanence. Blockchains resolve competing versions of history by a rule — most work, most stake — and if a competing chain wins, blocks that were part of the accepted history stop being part of it. That is a reorganisation, and transactions in the displaced blocks return to being unconfirmed or vanish.
Why depth helps
Reversing a transaction means producing a competing chain longer than the current one from before the block that contains it. Each additional block makes that more expensive, because the attacker has to out-produce the entire honest network across every block since.
So confirmations do not make reversal impossible. They make it expensive, and the practical question is whether it costs more to reverse than the transaction is worth. That is why exchanges use higher depths for larger deposits — the calculation genuinely depends on the amount.
Why different chains need different numbers
Comparing confirmation counts between chains is meaningless without knowing block time and consensus.
| Network | ON5 confirmations | Rationale |
|---|---|---|
| Ethereum | 12 | Long-standing convention; roughly two to three minutes at current block times |
| BNB Smart Chain | 20 | Blocks arrive faster, so more are needed for comparable wall-clock assurance |
| Base | 30 | Fast blocks; the count is chosen for elapsed time, not the integer |
| Kaanch Network | 12 | Matched to the chain's own finality characteristics |
Thirty confirmations on a two-second chain is a minute. Twelve on a twelve-second chain is around two and a half. The larger number is the shorter wait, which is exactly why the integer is the wrong thing to compare.
What a reorganisation looks like from a payments system
This is where theory becomes an accounting problem. Suppose you credit on first sight:
- A deposit appears in a block. You credit $1,000.
- The user immediately issues cards and spends the balance.
- A two-block reorganisation removes the block containing the deposit.
- The deposit no longer exists. The spending does.
You are now short $1,000 with no counterparty. Small reorganisations of one or two blocks are routine on most chains — this is not an exotic attack scenario, it is ordinary operation.
Detected, then credited
The pattern that handles this cleanly is two states rather than one.
- Detected. Seen on-chain, recorded, not spendable. The user knows their money arrived and is being confirmed.
- Credited. Confirmed to the required depth, re-verified as still canonical, and spendable.
The second half of that — re-verifying — is what people skip. Reaching depth is necessary but you should still check the transaction is still in the canonical chain before crediting, and comparing the stored block hash against the current one at that height is what makes the check meaningful.
On ON5 both transitions are emailed, so a deposit is observable while it waits rather than an unexplained delay.
Choosing a depth
- Start from published guidance for the chain, not intuition.
- Scale with amount if your risk tolerance requires it. A $10 deposit and a $100,000 deposit do not need the same assurance.
- Measure in time, not blocks. Users experience seconds; the block count is an implementation detail.
- Re-verify at the end. Depth alone is a probabilistic argument; re-checking is a factual one.
The user-experience side
Waiting is a product problem as much as a security one. Showing 8/12 with no explanation reads as an arbitrary delay. Showing that the deposit was detected, that confirmations are accruing, and roughly how long remains, turns the same wait into visible progress. The wait is not negotiable; how it feels is.
Frequently asked questions
What is a blockchain confirmation?
A block built on top of the block containing your transaction. Each one makes reversing the transaction more expensive, because an attacker would have to out-produce the honest network across every block since.
Why do different blockchains require different confirmation counts?
Because block times and consensus differ. Thirty confirmations on a fast chain can be less elapsed time than twelve on a slower one, so counts are only comparable alongside block time.
What is a chain reorganisation?
When a competing version of the chain wins, blocks that were part of accepted history stop being part of it, and transactions in them become unconfirmed or vanish. Small reorganisations are routine rather than exotic.
How many confirmations does ON5 require?
12 on Ethereum and Kaanch Network, 20 on BNB Smart Chain and 30 on Base. Deposits are recorded as detected on sight and credited once they reach depth and are re-verified as canonical.
Issue your first card on ON5
Fund an account with USDT or USDC and issue a branded Visa or Mastercard virtual card. The minimum is $5.
Open the dashboard