Confirmation Depth

Overview

Applications calculate depth by comparing the transaction’s block height with the current canonical chain tip. Some interfaces call the containing block one confirmation, while others describe later blocks as the additional depth. Documentation should make the convention explicit.

Depth is most meaningful in probabilistic-finality systems. Replacing a transaction becomes increasingly difficult as more work or consensus weight accumulates above its block. However, the relationship is not perfectly linear and can change during attacks, software failures, or major shifts in network participation.

In finality-based proof-of-stake systems, a transaction can reach a protocol checkpoint that provides stronger assurance than an arbitrary number of later blocks. Layer-two and cross-chain systems may require both local depth and settlement on another network.

Payment systems should not store confirmation count without the block hash used to calculate it. A reorganization can replace the block at the same height and reduce or reset depth. Confirmation policy should combine depth with transaction value, execution success, network health, and finality status rather than treating one number as universally safe.

Depth-based rules should be calibrated with historical reorganization behavior and economic security. A six-block requirement on one network cannot be copied to another merely because both use proof of work. Block interval, hash power distribution, checkpointing, and attack cost all matter. User interfaces should also explain when depth temporarily stops increasing because the network is producing blocks slowly rather than implying that the transaction itself has failed.

Depth should be interpreted together with network health. If validators are offline, miners are reorganizing frequently, or providers disagree about the tip, a normal-looking count can overstate confidence. Incident procedures may temporarily require stronger evidence.