Glossary

Confirmation Depth

The number of blocks mined on top of a transaction's block, indicating how secure and irreversible it is.

Key Takeaways

  • Confirmation depth is the count of blocks added after the block containing a transaction: a depth of 6 means five additional blocks have been mined on top of it, making reversal exponentially harder with each new block confirmation.
  • More depth means stronger protection against double-spend attacks: the probability of a successful chain reorganization shrinks exponentially as confirmation depth increases.
  • Different situations call for different thresholds: 1 confirmation may suffice for small payments, 3 for moderate amounts, and 6 or more for large transfers, while Layer 2 protocols like Spark bypass the wait entirely with instant finality.

What Is Confirmation Depth?

Confirmation depth measures how deeply a transaction is buried in the Bitcoin blockchain. When a transaction is first included in a block, it has a confirmation depth of 1. Each subsequent block mined on top of that block increases the depth by one. A transaction with a confirmation depth of 6 has five blocks stacked above it, meaning an attacker would need to re-mine all six blocks to reverse it.

The concept originates from Section 11 of Satoshi Nakamoto's 2008 Bitcoin whitepaper, which modeled double-spending as a catch-up problem using the Gambler's Ruin framework. The analysis showed that the probability of a successful attack decreases exponentially with each additional confirmation, establishing confirmation depth as the primary metric for transaction security on proof-of-work blockchains.

Unlike systems with deterministic finality, Bitcoin uses probabilistic finality: a transaction is never 100% irreversible, but becomes practically irreversible as confirmation depth grows. This trade-off is fundamental to how Nakamoto consensus works.

How It Works

Every Bitcoin block references the hash of the previous block, forming a chain. When miners extend this chain, they implicitly endorse all transactions in every preceding block. To reverse a confirmed transaction, an attacker must build an alternative chain that overtakes the honest chain, which requires re-doing the proof of work for every block from the target transaction forward.

  1. A transaction is broadcast to the network and enters the mempool
  2. A miner includes it in a new block (depth = 1, or "1 confirmation")
  3. The next block is mined on top (depth = 2): the transaction now has the cumulative work of two blocks protecting it
  4. Each subsequent block adds another layer of computational work that any attacker must match and exceed
  5. At depth 6, the transaction is considered sufficiently buried for most practical purposes

The Mathematics

Satoshi's original analysis used a Poisson approximation to model the race between an honest chain and an attacker chain. In 2018, mathematicians Grunspan and Pérez-Marco showed this approximation is slightly optimistic and provided an exact closed-form solution using the Regularized Incomplete Beta Function. The core insight remains the same: the probability of a successful reversal drops exponentially with depth.

For an attacker controlling 10% of the network hashrate (the assumption in Satoshi's analysis):

Confirmation DepthApproximate Reversal Probability
1~20.4%
2~4.6%
3~1.1%
4~0.26%
5~0.06%
6~0.02%

The probability shrinks by roughly a factor of 4 to 5 with each additional block. At 6 confirmations, the chance drops below 0.1%, which Satoshi deemed acceptable for most transactions.

Attacker Hashrate Changes Everything

The security guarantee depends on how much hashrate the attacker controls. The 6-confirmation convention assumes roughly 10% attacker share. With a larger share, the same depth provides weaker guarantees:

Attacker HashrateConfirmations for <0.1% Risk
10%~6
25%~21
30%~30+
40%~60

This relationship is why mining pool concentration is a security concern. If a single pool controls 30% or more of hashrate, the 6-confirmation rule offers weaker protection than commonly assumed. For a deeper analysis of how Bitcoin guards against block reversals, see Chain Reorganization Protection.

Checking Confirmation Depth

You can query a transaction's confirmation depth using Bitcoin Core's RPC interface or any block explorer:

# Query confirmation count via Bitcoin Core RPC
bitcoin-cli gettransaction <txid>

# Response includes:
# "confirmations": 6
# This means the transaction is 6 blocks deep

# You can also check raw transaction details
bitcoin-cli getrawtransaction <txid> true
# The "confirmations" field shows current depth

Common Confirmation Thresholds

There is no universal rule for how many confirmations are "enough." The right threshold depends on the amount at stake, the relationship between parties, and the acceptable level of risk. In practice, the ecosystem has converged on several informal tiers:

Small Payments (1 Confirmation)

For low-value transactions between reasonably trusted parties, a single confirmation is often sufficient. The cost of mounting a 1-block reorg to reverse a small payment far exceeds the value gained. Many wallets consider a payment "settled" after 1 confirmation.

Moderate Amounts (3 Confirmations)

Some exchanges credit deposits after 3 confirmations (roughly 30 minutes). At this depth, the reversal probability against a 10% attacker is approximately 1.1%, and the economic cost of attack is substantial. This threshold balances security with user experience for amounts that are meaningful but not life-changing.

Large Transfers (6 Confirmations)

The traditional standard for high-value transactions. Bitcoin Core's original client displayed a transaction as unconfirmed until it reached 6 blocks. Many exchanges and payment processors treat 6 confirmations (roughly 1 hour) as the threshold for large deposits.

Coinbase Transactions (100 Confirmations)

Coinbase transactions (the block reward paid to miners) have a special rule: they cannot be spent until they reach 100 confirmations. This protects the network from situations where a block is orphaned and its reward becomes invalid, which would otherwise create cascading invalid transactions.

Use Cases

Exchange Deposits

Cryptocurrency exchanges set confirmation thresholds to protect against double-spend attacks on deposits. A user could deposit Bitcoin, trade it for another asset, withdraw that asset, and then reverse the original deposit via a chain reorganization. Different exchanges set different thresholds based on their risk appetite and the value involved.

Payment Processors

Merchants accepting Bitcoin payments must decide how long to wait before considering a transaction final. A coffee shop might accept zero confirmations for a small purchase, while a car dealer would wait for 6 or more. Payment processors often let merchants configure their own finality thresholds based on the product or service being sold.

Smart Contract Settlement

Cross-chain bridges and atomic swap protocols use confirmation depth to determine when to release funds on the other chain. If the bridge finalizes too early, a reorg on Bitcoin could leave the bridge with unbacked assets. Most bridges require 6 or more confirmations before crediting the destination chain.

Why It Matters

Confirmation depth is the mechanism that turns Bitcoin's probabilistic consensus into practical payment finality. Without it, every transaction would remain perpetually reversible, making Bitcoin unusable for commerce. The concept also highlights the fundamental trade-off in proof-of-work systems: stronger security requires longer wait times.

This trade-off is one of the primary motivations for Layer 2 solutions. On Bitcoin's base layer, waiting for 6 confirmations takes roughly an hour. For many use cases (point-of-sale payments, micropayments, real-time settlements) that delay is impractical. Spark, for example, provides instant finality for Bitcoin transactions without requiring users to wait for any on-chain confirmations, while still inheriting Bitcoin's security model through its exit mechanisms.

For a broader comparison of how different systems handle finality, see Payment Finality Comparison Across Blockchains.

Risks and Considerations

False Sense of Security

The 6-confirmation rule is often treated as an absolute guarantee, but it was derived under specific assumptions: namely, that no single entity controls more than about 10% of the network hashrate. As mining has become more concentrated among large pools, the same confirmation depth provides weaker protection than Satoshi's original analysis suggested. Recipients of very large transactions may want to wait for more than 6 confirmations during periods of high pool concentration.

Time Cost

Each Bitcoin block takes approximately 10 minutes on average. Waiting for 6 confirmations means roughly an hour, and block times can vary significantly due to random variance in mining. Some blocks are found in seconds, others take over 30 minutes. This unpredictability makes confirmation depth unsuitable for time-sensitive applications.

Zero-Confirmation Transactions

Accepting transactions with zero confirmations (while still in the mempool) carries real risk. An attacker can broadcast conflicting transactions using replace-by-fee to redirect funds. While some merchants accept this risk for small in-person purchases, zero-confirmation transactions should never be treated as final for significant amounts. For more on this topic, see Zero-Conf Bitcoin Explained.

Reorg Depth vs. Confirmation Count

It is worth distinguishing between the two related terms. "Confirmation depth" refers to how deep a specific transaction sits in the chain. A chain reorganization of N blocks can invalidate any transaction with a confirmation depth of N or less. One-block reorgs occur roughly once every 45 days under normal network conditions and typically affect only the most recent block. Deep reorgs (3+ blocks) are extremely rare and have historically been caused by software bugs rather than deliberate attacks.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.