Block Height

Overview

Block height provides an ordered position within a blockchain history. A transaction included at height 850,000 can be compared with the current chain tip to estimate how many blocks have followed it.

Height is not always a globally unique block identifier. During a fork or temporary reorganization, two different valid blocks can exist at the same height. A block hash is therefore required when the exact block must be identified.

Applications use height for confirmation counts, time-lock rules, checkpoints, historical queries, and synchronization progress. Because block intervals are variable, converting height differences directly into wall-clock time provides only an estimate.

In payment processing, confirmation count is often computed from the current height and the transaction’s inclusion height. Reorganizations can reduce or reset that count, so software should obtain it from a current node or trusted payment status rather than store it as a permanent value.

During a chain reorganization, two competing blocks can temporarily share the same height. Applications that save only the height may mistakenly assume the earlier block is still canonical. Payment systems should compare the stored hash with the current canonical block at that height.

Height is also commonly used to calculate confirmation count, schedule protocol upgrades, and define time-locked conditions. However, it is not a precise timestamp because block production intervals vary. Cross-chain systems should never compare heights directly as if they represented the same amount of elapsed time or security across different networks.

Explorers sometimes display a confirmation count derived from height, but the application should calculate it against a trusted canonical tip. A lagging provider can otherwise make a transaction appear less or more confirmed than it really is.