Block Status

Overview

Meaning and scope

Block status describes where a block stands in the consensus lifecycle, such as proposed, canonical, confirmed, finalized, orphaned, or invalid. Status can change as consensus advances or a reorganization replaces recent history. A block at a known height is therefore not uniquely identified without its hash.

Mechanism and operation

Block status describes a block’s position in the local validation and consensus process. A node may know a header while waiting for the body, have the complete block but still be validating it, or accept it as part of a temporary competing chain. Other systems distinguish proposed, justified, finalized or rejected blocks. An application must define which statuses its node exposes and which ones correspond to usable transaction evidence. A block previously on the preferred chain can lose canonical status during a reorganization. Payment workflows should therefore connect block identifiers and transaction placements to a confirmation or finality policy, then change the customer-facing state only when those criteria are satisfied.

Practical payment example

A support dashboard distinguishes a proposed block from a validated or finalized block before marking its included transfers as secure.

Operational checks

Track node sync health, height and hash, validation flags, canonicality, finality signal and reorganization events. Reassess affected invoices after a status reversal. Block status expresses how a node or service currently classifies a block. Common states include received, validated, canonical, safe, finalized, stale, orphaned, skipped, or invalid, but the exact vocabulary and guarantees vary across networks and providers. Provider labels may also lag or map network-specific finality into simplified categories. Payment systems should define internal states from authoritative chain signals and retain block hash, height or slot, parent, and finality evidence.

Distinctions and limits

Block inclusion is not always block finality, and a locally received block is not automatically valid or permanently canonical.

Related reading

Related definitions: Block, canonical block.