How Many Confirmations Does a Bitcoin Transaction Need?

A Bitcoin transaction confirmation is a new block added to the blockchain on top of the block containing your transaction, and most services consider a transaction "confirmed" once it has received at least one, though higher-value transfers typically require more confirmations to reduce the risk of the transaction being reversed by a chain reorganization.

What a confirmation actually is

When your transaction is included in a block, it has one confirmation. When the next block is mined on top of that block, your transaction now has two confirmations, and so on. Each additional confirmation makes reversing the transaction exponentially more computationally expensive, because doing so would require an attacker to redo the proof-of-work for that block and every block built on top of it, while simultaneously outpacing the honest network's ongoing block production — the same core security assumption discussed in our /blog/pow-vs-pos comparison.

Before a transaction has any confirmations, it sits in the mempool as described in /blog/what-is-the-bitcoin-mempool, and it isn't secured by proof-of-work at all — it could still be replaced or dropped.

Why more confirmations mean more security

Bitcoin blocks are occasionally produced almost simultaneously by two different miners, causing a temporary fork where two versions of "the latest block" compete. The network resolves this automatically: whichever chain gets the next block first becomes the accepted one, and the other block (along with any transactions unique to it) is orphaned. This is called a reorganization, or "reorg."

Reorgs of one block deep happen periodically and are a normal, harmless part of Bitcoin's design. Deeper reorgs — several blocks reversing at once — are far rarer and would generally require an attacker to control a very large share of the network's total computing power, since they'd need to out-mine the honest chain over multiple blocks. The deeper a transaction is buried (i.e., the more confirmations it has), the less realistic a reorg reversing it becomes.

Why different confirmation thresholds exist

Exchanges, custodians, and merchants set their own confirmation requirements based on the value at risk and their own risk tolerance, not a single protocol-mandated number. Bitcoin itself doesn't declare a transaction "final" at any specific confirmation count — that judgment is a policy decision made by whoever is receiving the funds.

Transaction value / context	Typical confirmations required
Small retail purchase	0-1 (often accepted unconfirmed for low-risk, low-value goods)
Standard exchange deposit	2-3
Large exchange deposit or withdrawal	6 or more
High-value institutional settlement	6-100+, depending on internal policy

The commonly cited "six confirmations" standard traces back to early guidance suggesting it made a successful reversal computationally impractical for all but an attacker with enormous resources. Many services still use six as a conservative default for meaningful transaction sizes, while adjusting up or down for very small or very large amounts.

Factors that affect the "right" number

There's no universally correct confirmation count — it depends on a few factors:

• Value at risk. Higher-value transfers justify waiting for more confirmations, since the cost of a successful attack needs to exceed the value being stolen for the security model to hold economically.
• Irreversibility of the associated action. If receiving the funds triggers an irreversible action on your end (like releasing goods or converting to another currency), you may want more confirmations than if the action itself could be undone.
• Network conditions. During periods of unusually high mining power fluctuation or contentious situations, some services temporarily raise confirmation requirements out of caution.

Confirmations and RBF/CPFP interplay

It's worth remembering that confirmation counting only starts once a transaction is mined. Before that, techniques like Replace-By-Fee (/blog/replace-by-fee-rbf-explained) and Child-Pays-For-Parent (/blog/child-pays-for-parent-cpfp-explained) can still alter or accelerate an unconfirmed transaction. This is precisely why serious counterparties don't treat zero-confirmation transactions as final — an unconfirmed transaction, however long it's been broadcast, remains provisional until it's actually included in a block.

Checking confirmations yourself

You can check how many confirmations any transaction has using a /blog/what-is-a-bitcoin-block-explorer, which typically displays the transaction's block height alongside the current blockchain tip, letting you calculate confirmations as the difference between the two. This is a useful habit before treating any incoming payment as fully settled, particularly for larger amounts.

How this compares to other blockchains

Confirmation-based finality is specific to proof-of-work chains like Bitcoin, where finality is probabilistic and improves gradually with each block. Many proof-of-stake networks use different finality mechanisms that can offer faster, more deterministic settlement guarantees — our /blog/pow-vs-pos article compares these approaches directly, and /blog/layer1-blockchains-compared looks at how various base-layer chains handle security and finality more broadly.

Bottom line

There's no fixed number of confirmations that's universally "safe" — it's a judgment call based on value at risk and the cost of a successful reorg attack. Small payments are often accepted with minimal confirmations, while significant transfers commonly wait for six or more. Understanding this trade-off, rather than treating any single number as gospel, is the more useful mental model for evaluating Bitcoin transaction finality.