Blockchain State

Overview

Blockchain State represents the information a network currently accepts as valid after processing an ordered history of transactions. In an account-based system, it can include balances, nonces, code, and contract storage. In a UTXO system, the spendable output set is a central part of state.

Each valid transaction applies a State Transition to the prior state. Nodes execute or verify the same rules and reject a block if the resulting commitments do not match. Ethereum block headers include a state root that cryptographically commits to the global execution state after the block.

State is not identical to historical data. A current balance may be part of state, while an old transfer or log belongs to history. Archive nodes retain older state snapshots or the information needed to reconstruct them. Standard nodes may prune data that is no longer required for current validation.

Applications must specify which state they queried. A pending view may include unconfirmed transactions, a latest view can still be reorganized, and a finalized view follows stronger settlement rules. Payment decisions should use an appropriate confirmation policy and record the block hash associated with the observed balance or contract value.

Indexes and explorers can cache or derive state-related values, so their displays may lag behind a node. For high-value operations, systems can use a State Proof or direct node query and then perform State Verification. The key requirement is to bind every state claim to a specific canonical chain position.

The application should also define whether it needs current state or historical state. Support investigations often ask what a balance or contract value was when a payment occurred, not what it is now. Answering that question can require an archive node, retained proof, or state-difference data.