Block Status

Overview

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. 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. 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. They must reverse or suspend credits when a previously canonical block becomes orphaned. Interfaces should explain what confirmed means instead of presenting every status as irreversible settlement.

Field names can appear similar across networks while using different byte order, commitment schemes, size limits, activation heights, or relationships to the block header and body. Block Status must be interpreted under the exact chain rules and software version that define its encoding and validation. Verification of Block Status should begin with a canonical block identifier rather than a height alone. Competing blocks can temporarily occupy the same height, and a reorganization can replace data that was previously observed, so applications should retain hashes and update dependent records when canonicality changes. Pruned, archive, light, and indexing services may expose different historical fields or proofs. Teams should document which component supplies the data and how missing, malformed, or version-unknown records are handled. Operational use of Block Status depends on node mode and data retention.