Chain

Overview

A chain is the sequence of blocks, state transitions, or ledger records that a blockchain protocol accepts as connected history. Each new block normally references a predecessor, allowing nodes to verify ordering, continuity, and the accumulated evidence supporting the current state.

Nodes can temporarily observe multiple competing branches, so a locally visible chain is not always canonical or final. Consensus rules, validator votes, cumulative work, checkpoints, or finality proofs determine which branch applications should follow. Payment systems must bind every transaction to the intended network and track its position on the canonical chain. They should record block identifiers, confirmation or finality status, and reorganization handling rather than treating a transaction hash alone as permanent proof of settlement. Chain must be interpreted under the exact chain rules and software version that define its encoding and validation. For Chain, 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.

Verification of Chain 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. Operational use of Chain depends on node mode and data retention. 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. Settlement consideration: A chain becomes operationally meaningful only when its blocks are canonical, sufficiently final, and tied to the intended network.