In common Bitcoin usage, a transaction has one confirmation when it appears in a block on the accepted chain. Each subsequent block increases that count. A transaction still waiting in a mempool has zero confirmations. This convention includes its own block, which matters when reconciling an explorer with an exchange deposit policy. Confirmations describe position in a particular observed chain; they are not independent certificates issued by every miner or wallet that saw the transaction.

If a transaction is included at height 500 and the current accepted tip is height 504, it has five confirmations under this convention: 504 minus 500 plus one. If the network reorganizes and the original inclusion block is replaced, the count can change or the transaction can become unconfirmed. This arithmetic explains the display but does not choose the right acceptance policy. A service may require additional checks beyond a particular count, such as a supported token and destination.

Proof-of-work confirmations provide increasing depth under assumptions about the competing work an attacker can produce; they do not create an absolute mathematical cutoff where reversal becomes impossible. Other systems have explicit finality rules and checkpoints, so the same displayed number of blocks does not imply the same security. A useful status view distinguishes pending, included, and finalized states where applicable. Evaluate the chain's consensus rules and the application's settlement requirements instead of exporting one network's confirmation convention to every other network.