Crypto Confirmations Explained

What one confirmation actually is

When a transaction is included in a block, it has one confirmation. Each block appended after that one adds another. The count is simply the depth of your transaction in the chain.

Depth matters because rewriting history means replacing every block from your transaction onward. On proof-of-work networks that requires redoing the accumulated work; on proof-of-stake networks it requires overriding or forfeiting staked capital. Either way the cost of reversal grows with depth, which is why services wait.

Why required counts differ

• Block interval — networks produce blocks at very different rates, so the same number of confirmations represents very different elapsed time and very different accumulated security.
• Consensus design — probabilistic settlement gets safer with depth; designs with explicit finality reach a defined irreversible point instead.
• Value at risk — services commonly require more confirmations for larger deposits.
• Asset and network — a service usually publishes a different threshold per asset, and per network for assets that exist on several.
• Risk appetite and policy — thresholds are commercial decisions, not protocol rules, and services change them.

There is no universal safe confirmation count, and any page that gives you one number for all networks and all amounts is simplifying something that is genuinely conditional.

Probabilistic vs explicit finality

• Probabilistic finality: reversal never becomes mathematically impossible, only progressively impractical as depth increases. This is how proof-of-work chains settle.
• Explicit finality: the protocol defines a point at which blocks are considered final, after which reverting them would require penalised actions by a large share of validators.
• Reorganisation (reorg): a short-lived competing chain replaces recent blocks. Shallow reorgs are normal events on some networks; they are the reason zero-confirmation transfers are not treated as settled.

Why your wallet and the service disagree

• The wallet reports the chain state: included in a block, with a confirmation count.
• The service reports its own internal crediting state, which starts only after its threshold is met and its systems process the deposit.
• Maintenance, manual review or compliance checks can delay crediting long after the chain shows the transfer as confirmed.
• A transfer to the wrong network or a missing memo can be confirmed on-chain and never credited at all.

What affects how long confirmations take

• The network's target block interval, which sets the floor.
• Whether your transaction was included in the first place — an underpriced fee leaves it in the mempool, where it has zero confirmations regardless of elapsed time.
• Congestion, which lengthens the queue rather than the blocks.
• Variance: block production is stochastic on proof-of-work networks, so intervals cluster around the target rather than matching it.

How to check your own status

1. Find the transaction hash in the sending wallet or service.
2. Open the block explorer for the network actually used.
3. Read whether it is pending or included, and the confirmation count if included.
4. If it is included and confirmed but not credited, the remaining delay belongs to the receiving service, not the network.
5. Contact that service with the hash, the network name, the amount and the timestamp.

Sources

• Bitcoin developer guide — Transactions
• Ethereum developer documentation — Proof of stake
• Ethereum developer documentation — Transactions