QWE AI Academy The idea that you always need six Bitcoin confirmations is one of the most over-taught rules in crypto. It started as a convenient default in early software, not a law of physics. Treating it as gospel wastes hours on small payments and still under-protects you when the stakes or the attacker model change.
How many confirmations for Bitcoin should you wait for? A risk policy you set yourself – value at stake, counterparty trust, and whether you mean pure chain depth or an exchange crediting a balance. Below: build that policy, check a live TX, and avoid the traps that actually burn time.
Quick context: what a confirmation really measures
Once your transaction lands in a block, it has 1 confirmation. Each block mined on top adds one more. Depth makes a reverse (reorg / double-spend) harder because an attacker must redo the proof-of-work for that block and everything after it, then outpace the honest chain.
Six was never protocol law. The classic client treated txs as unconfirmed until six deep – per the Bitcoin Wiki – under assumptions of an attacker with at most ~10% hashrate and under 0.1% risk tolerance. Both knobs are arbitrary. The chain does not hard-code “six = final.”
Think of confirmations like locks on a door after a delivery. One lock stops casual thieves. Six locks is overkill for a pizza and still useless if the attacker owns a tank. You pick lock count from package value and neighborhood, not from a poster on the wall.
Hands-on: build your confirmation policy and check a live TX
Skip “what does the internet say.” Start from three questions, then read the chain yourself.
- What is at risk if this reverses? A $20 tip vs a $50k OTC trade are different math.
- Who is the other side? Known friend, or anonymous counterparty with a reason to cheat?
- Chain depth or platform credit? Those clocks are not the same.
Starting matrix (push deeper if the counterparty is hostile or the goods are irreversible):
| Scenario | Starting depth | Why |
|---|---|---|
| Tiny peer payment, trusted, low value | 0-1 | Economic incentive to attack is near zero |
| Everyday wallet-to-wallet | 1-2 | First inclusion is already the largest security step |
| Unknown counterparty, mid value | 3 | Common practical band many services sit near |
| Large transfer / self-custody move | 6 | Classic high-assurance retail default |
| Very large or nation-state-level concern | 60+ | Wiki: ~60 confs for <1% odds vs ~40% hashrate |
| Spending a fresh miner reward (coinbase) | 100 | Consensus rule – COINBASE_MATURITY; not optional |
Grab the TXID from your wallet. Then:
- Open mempool.space (or another explorer).
- Paste the TXID.
- Status will be unconfirmed (mempool) or confirmed with a count and block height.
- Watch the count climb. Target average is ~10 minutes per block – but discovery is not a kitchen timer.
Pro tip: Depositing to an exchange? Read their number before you send, and re-check the help page when you move size – policies change. As of the public help pages cited here, Coinbase lists 2 for BTC; Kraken states 4 (~40 minutes on average block times). Binance’s FAQ (updated 2025) notes a network minimum of 1 but unlocks after at least 2 for safety. Explorer at 3 while the venue still says Pending is normal: platform credit is a separate policy from chain depth.
Write one sentence you’ll actually use – “Under $500 trusted → 1 conf; over $10k or unknown → 6; exchange deposits → whatever that venue publishes today” – and keep it with your wallet notes so you don’t renegotiate under stress.
Common pitfalls that burn time (and sometimes money)
- Chain confirmed ≠ exchange available. Funds can be deep on-chain while the venue still holds a credit lock. Match the platform’s published count, not a generic blog chart.
- High fees do not guarantee a fast first confirmation. Fees buy priority in the next block template. They do not force miners to find a block. Discovery is memoryless (Poisson). The Wiki notes ~5% of intervals can run past 30 minutes; hour-scale waits for a single block happen even when the fee looks “fine.”
- 0-conf with strangers is a different game than 0-conf with a friend. Unconfirmed transactions can still be raced or replaced. If you cannot claw the goods back, wait for at least one inclusion.
- Fresh coinbase outputs. Pay you from a brand-new mining reward? Consensus blocks spending those outputs until 100 confirmations. Urgency does not override COINBASE_MATURITY.
None of these are exotic. They’re why support queues spike at 2 a.m.
What the numbers actually buy you
Security here is probabilistic. Whitepaper Section 11 models attacker catch-up probability falling exponentially with depth z. The familiar “six” line grew from early minority-hashrate assumptions – not from a sacred constant. Wiki framing is blunt: six is overkill against casual attackers and thin against far more than 10% hashrate.
| Depth (approx @ 10 min/block avg) | Practical read |
|---|---|
| 0 (seconds after broadcast) | Seen by the network; still reversible via race-style tricks |
| 1 (~10 min average) | In a block – largest single security step |
| 2-4 (~20-40 min) | Band where several major exchanges credit BTC under current public policies |
| 6 (~60 min) | Long-standing high-assurance retail convention; bitcoin.org FAQ compares the comfort level to waiting months on a card charge |
| 100 (~16-17 hours) | Coinbase maturity for miner rewards |
Times are averages. One confirmation can land in under a minute or after an hour. Plan buffers, not stopwatches.
When waiting for “enough” confirmations is the wrong move
Don’t freeze a low-value trusted payment for an hour out of cargo-cult habit. Don’t take 0-conf for high-value irreversible goods from a stranger either.
Need near-instant retail settlement? Base-chain depth is the wrong tool – Lightning and other layers exist because blocks are slow by design. Confirmations address double-spend risk on L1. They are not a general speed feature.
Is there a single number that will still feel right in five years as hashrate and attack economics shift? Probably not – and that uncertainty is why a written personal policy beats a memorized slogan.
FAQ: how many confirmations for Bitcoin
Is 1 confirmation ever enough?
Yes – for small amounts between parties who already trust each other. Inclusion already costs real work to reverse. Larger or adversarial? Go deeper.
Why does my exchange still say pending when the explorer shows 3+ confirmations?
The explorer shows chain depth. The venue runs its own credit rules, risk engines, and sometimes extra internal checks after the on-chain threshold. Wait for their published count (re-check the help article – numbers move), then open a ticket only if that bar is clearly met and the balance is still missing. “Confirmed on-chain” vs “credited” mismatch is usually policy, not a lost TX.
Do I need 6 confirmations because the whitepaper says so?
No. Section 11 is a formula under stated assumptions; early clients picked six as a UI threshold for a ~10% attacker model. The Wiki: nothing special about six – set your own threshold. Against much higher hashrate you may want far more (on the order of 60 for low odds vs ~40% power). Six stays a solid conservative default for large retail transfers. It is not holy writ.
Next: open mempool.space, paste your last TXID (or any public one), note the count. Then three lines for your wallet sheet – small/trusted, medium/unknown, large/exchange. Use that sheet the next time someone asks “is it confirmed yet?”