Canonical Chain

Overview

Nodes can temporarily know several valid branches. The protocol’s fork-choice rule selects one branch as the chain to extend and use for current state. In proof-of-work, accumulated work is central. Proof-of-stake systems can combine votes, checkpoints, and proposer rules. The resulting sequence is called canonical because it supplies the accepted ordering for transaction execution, balances, and application queries.

Canonicality is time-dependent. A recent block can be part of the canonical chain and later be replaced if a competing branch gains more weight. Transactions may then be re-included in another block, return to the pending pool, conflict, or disappear. A Confirmed Block gains stronger assurance as descendants or finality evidence accumulate, but recent canonical status alone does not mean irreversible settlement.

Applications should identify canonical history using both block number and Block ID. Querying only by number after a reorganization can silently return a different block than the one previously processed. Event indexers should mark removed logs, reverse provisional accounting, and replay the replacement branch. Internal ledgers need idempotent state transitions so canonical updates do not create duplicate credits or unresolved order states.

For cross-chain and payment workflows, only events meeting the required canonical and finality policy should trigger irreversible actions. Providers can be stale or connected to different networks, so high-value systems should verify chain identifiers and compare independent observations. Historical audit records should preserve both the originally observed branch and the eventual canonical outcome. This makes reorganization handling explainable without rewriting what the system actually saw.

Canonical status should be treated as a versioned observation tied to a specific node state and time, not as an immutable property attached permanently to a block number.