Bitcoin confirmations count how many blocks have been built on top of the block containing a transaction. One confirmation means the transaction is in the current best chain. Each additional block makes replacing that history more difficult, but there is no protocol switch that turns a payment from reversible to permanently final at exactly three or six.
That distinction matters when a wallet says “confirmed,” an exchange asks for several confirmations or a merchant decides when to release goods. They are applying a risk rule to the same chain—not reading different kinds of transactions.
What the number actually counts
Before a transaction is mined, it normally sits in a node’s memory pool, or mempool. It may be visible to wallets and block explorers, but it has zero confirmations because it is not yet part of a block in the active chain.
When a miner includes it in a valid block and that block becomes the network’s current tip, the transaction has one confirmation. If another block is added after it, the count becomes two. The score keeps increasing as the active chain grows.
Bitcoin Core exposes that number directly. Its current gettransaction response reports the confirmation count for a wallet transaction; negative confirmations indicate that the transaction conflicted with a transaction in the active chain. The getblock response similarly reports -1 when a block is no longer on the main chain.
The number is therefore not a timer. Blocks target an average interval of roughly ten minutes, but they do not arrive on a fixed schedule. Six confirmations may take less than an hour or considerably longer.
Why more confirmations help
Bitcoin nodes follow the valid chain with the most cumulative proof of work. Replacing a recent transaction requires an alternative chain that omits or conflicts with it and then accumulates enough proof of work to become the active chain.
The first block gives the transaction a place in the ledger. Each later block adds more work on top of that history. An attacker trying to replace the payment has to catch up from further behind, while honest miners continue to extend the current chain.
This is why confirmation count works as a practical confidence score. It does not prove that a reversal is mathematically impossible. It tells you how deeply the payment is buried in the chain that nodes currently accept.
Zero confirmations: seen, not settled
A zero-confirmation transaction can be useful as a signal that a payer broadcast something, but it is the weakest state for accepting value.
Several things can still happen:
- the transaction may never be mined because its fee is too low;
- a conflicting transaction may be mined instead;
- the sender may replace it under the network’s replace-by-fee policy;
- a node may drop it from its mempool;
- different nodes may not have seen the same transaction.
A wallet can label an unconfirmed transaction “pending” or even “trusted” for its own spending policy. That label is local wallet judgement, not a network-wide guarantee.
For a coffee-sized in-person payment, a business might accept that risk to avoid making the customer wait. A service delivering an irreversible digital asset or a high-value withdrawal should use a stricter policy. The decision depends on value, fraud exposure, the ability to recover goods and the payment’s conflict or replacement signals.
If a payment remains pending, the relevant questions are usually about transaction fee and replacement mechanics. OSBBD’s guides to Bitcoin fees versus the amount sent and replace-by-fee explain those separately.
One confirmation: included in the current chain
One confirmation is a substantial change: a miner has included the transaction in a valid block that nodes currently treat as the best chain.
It is still the tip or close to the tip, where short reorganizations can occur. Two miners occasionally find competing blocks at about the same time. Different parts of the network may briefly extend different tips. Once one branch gains more cumulative work, nodes switch to it and the other block becomes stale.
A transaction from the stale block is not automatically lost. Bitcoin Core can return transactions from disconnected blocks to the mempool, after which they may be mined again. But a conflicting transaction in the winning branch can prevent the original payment from returning.
For routine transfers between your own wallets, one confirmation may be enough to move from “pending” to “received.” For releasing something valuable and irreversible, it may be too little. The protocol does not make that business decision.
Three confirmations: a policy, not a protocol milestone
Three confirmations are common in service policies because the transaction is now below the tip and a replacement would require a deeper reorganization. Nothing special occurs in consensus at block three.
An exchange might use three for one deposit and more for another. A merchant can use a different threshold again. Some services adjust the number by asset, deposit size, current network conditions or their own ability to absorb a loss.
The key is to read the platform’s current deposit page rather than assume that “Bitcoin always needs three.” The platform controls when it credits your account. Bitcoin only supplies the chain and confirmation data used in that rule.
Six confirmations: a conservative convention
Six confirmations are a long-standing convention for higher-risk Bitcoin payments. The Bitcoin developer guide describes the number as somewhat arbitrary, while noting that a transaction buried under six blocks would require a much more costly chain replacement than one near the tip.
Six is not universal finality. A service may wait for fewer, more or a dynamic number. A prolonged consensus failure, implementation bug or attacker with a large share of mining power changes the risk model. Deep reorganizations are unlikely under normal conditions, not forbidden by the protocol.
The useful question is not “Is six final?” It is “Is the remaining reversal risk small enough for this transaction and this action?”
Reorganizations can lower or remove the count
A chain reorganization, usually shortened to reorg, happens when a node switches from one valid branch to another with more cumulative proof of work.
When that occurs:
- one or more blocks at the old tip are disconnected;
- transactions from those blocks are reconsidered;
- replacement blocks are connected;
- transactions present in the new active chain regain confirmations;
- transactions that conflict with the new chain stay unconfirmed or become conflicted.
Bitcoin Core’s listsinceblock RPC can return wallet transactions removed during a reorg. Its documentation also warns that a removed transaction can appear again with a positive confirmation count if it was re-added to the active chain.
This is why payment software should track a transaction until it reaches the chosen threshold and continue to handle status changes. A single “payment seen” webhook is not enough for systems that ship goods, release a withdrawal or unlock another irreversible action.
The amount sent does not set the confirmation count
A transfer of 0.001 BTC and a transfer of 10 BTC are confirmed by blocks in the same way. The amount does not make one transaction accumulate confirmations faster.
The sender’s fee can affect how quickly miners include the transaction, because miners generally choose among pending transactions by fee rate and other policy rules. Once the transaction is in a block, the chain’s next blocks determine its confirmation count.
A recipient may choose a higher threshold for a larger amount, but that is risk management. It is not a different confirmation mechanism.
Wallet confirmations and exchange credit are not the same
A self-custody wallet can show that a transaction has six confirmations while an exchange still marks the deposit as pending. The exchange may require additional checks, wait for an internal sweep, pause deposits or apply a different threshold.
The reverse is also possible: a service can credit a deposit before the threshold shown by another wallet. That does not alter the blockchain record. It means the service accepted more risk.
When troubleshooting, separate three questions:
- Is the transaction visible in the mempool?
- Is it included in the active chain, and with how many confirmations?
- Has the receiving service credited the account under its own policy?
A wallet manages keys and reads chain state; it does not create finality by changing a label. See what a crypto wallet actually stores for that distinction.
A practical acceptance policy
A useful policy connects confirmation depth to the consequence of a reversal.
| Situation | Practical approach |
|---|---|
| Payment has zero confirmations | Treat as pending; check conflicts, replacement status and fee conditions |
| Low-value, recoverable purchase | Consider whether speed is worth the small reversal risk |
| Irreversible digital delivery | Wait for at least one confirmation and set a higher threshold when loss would matter |
| High-value deposit or withdrawal | Use the service’s published rule; six or more may be appropriate |
| Confirmation count falls | Pause fulfilment and investigate a reorg or conflict |
| Transaction disappears from one explorer | Check another source or your own node before assuming funds are lost |
There is no single correct number for every business. Write the threshold down, use it consistently and make the customer-facing status clear. If the action is irreversible, process the transaction again after every new block until the threshold is reached rather than trusting an old cached result.
