Bitcoin Confirmations Explained: 0, 1, and 6+

The count starts when a block includes the transaction

A Bitcoin transaction can be broadcast and visible to a wallet or explorer before any block includes it. That is zero confirmations: the transaction has not yet been included in a block on the chain being counted. Inclusion in a block is its first confirmation. Each later block built on that history adds one more.

There is no single network-wide pending list: individual full nodes may keep different temporary mempool views. One wallet or explorer can show a broadcast transaction that another does not.

Think of the number as a measure of depth in the current chain, not a universal approval stamp. A service may use its own rule before it credits a deposit or releases an order. That internal decision is separate from the transaction's on-chain count.

What zero, one, and more confirmations mean

• 0: The transaction has been broadcast but is not yet included in a block. A wallet or explorer may know about it, but that display does not mean the receiver's service has credited it.
• 1: A block on the current chain includes the transaction. A competing block can still cause a short reorganization, so the displayed count can change.
• 2 or more: Additional blocks have been built after the containing block. More accumulated proof of work makes replacing that history harder, but no count proves that a payment is risk-free or that a seller will deliver.

If competing blocks are found, nodes may first follow the block they saw and later converge on the most-work valid chain. If a reorganization replaces the block containing a transaction, its count on the selected chain can fall back to zero. Bitcoin Core may return that transaction to its mempool if it remains eligible, as its v31.1 reorganization code shows; other nodes, wallets, and explorers can show different temporary views. The transaction may later be included in another block.

Is six confirmations always enough?

No. Six is a familiar rule of thumb in some Bitcoin references. There is no universal confirmation number or protocol setting that guarantees finality. A merchant, exchange or wallet service chooses its own acceptance policy. The right threshold depends on that service's risk and the consequences of accepting a payment too early; this guide cannot set it for them. Look up the recipient's current deposit or payment rule rather than assuming a familiar number applies.

More confirmations increase confidence that the transaction will remain in the selected history. They do not verify a person's identity, prove a product will arrive, or establish that a transaction was intended. Bitcoin confirmations are not the same as a bank chargeback window or a service's internal balance update.

Why the wait has no exact timer

Bitcoin targets an average block interval of about ten minutes over time, but blocks are found probabilistically. One confirmation might arrive much sooner or much later; there is no guaranteed countdown. Transaction fees and changing competition for block space can also affect whether a transaction is included promptly. A fee estimate is not a promise of a particular confirmation time.

If a wallet says “sent” but the count is still zero, check the transaction reference on the correct Bitcoin network and read the receiver's own policy. Do not send a duplicate payment just because a screen has not updated. For the wider lifecycle, see how Bitcoin transactions work; for current fee mechanics, read Bitcoin fees explained.

Practise with a fictional payment

A fictional explorer shows a transaction in a block, followed by two more blocks. What is its confirmation count? Three: one for the block that contains it, plus one for each later block. That count describes chain depth only. Before treating a real deposit as available, check the actual receiving service's policy.

For network status versus a provider's internal credit, continue to pending, confirmed and finalized. To interpret the fields on an explorer, see how to read a blockchain transaction.