Block

Overview

Why Block matters

If a network accepted transactions as an unordered collection, participants could disagree about which spend occurred first or which contract update should be applied. Blocks create a common sequence of updates, making it easier for nodes to reconstruct and verify the network's state. They also provide units of progress for confirmations or checkpoints.

How it works

A block producer gathers candidate transactions and constructs a block header and body under its protocol rules. In Bitcoin, the header includes a previous-block hash, a Merkle root commitment, a timestamp, a difficulty target representation and a nonce used in proof-of-work search. The body lists transactions, beginning with a special coinbase transaction. Nodes verify that the block obeys consensus rules and that transactions are valid in the context of the prior chain state. The network may briefly see competing valid blocks at the same height. Chain-selection and finality rules decide which history persists; this is why a recently included payment can be less settled than an older one.

A block is not simply a timer

A recurring mistake is to calculate settlement time by multiplying a nominal block interval by a required confirmation count. Bitcoin's target block interval is an average, not a schedule, and no network promises precisely timed inclusion. Even on chains with short slots, transaction execution, RPC indexing and finality can occur at different times. For payment systems, measuring observed broadcast-to-inclusion time and inclusion-to-acceptable-finality time provides more useful operational data than assuming a fixed clock. It is also important to track block identity, not only height: two competing branches can contain different blocks with the same height before consensus converges. When a reorganization occurs, a previously included transfer may temporarily or permanently disappear from the canonical history.

A real-world payment example

A shop receives a payment included in a newly mined Bitcoin block. An explorer shows one confirmation. For an expensive product, the store may wait for additional blocks according to its risk policy. The payment did not become a different transaction after the first block; confidence in its position in the accepted history increased.

Limits and common misunderstandings

Block height alone cannot prove a particular transfer succeeded, especially on smart-contract platforms where an included transaction can revert or fail. A block timestamp is not necessarily a precise wall-clock payment time. Do not assume all chains have ten-minute blocks or share one security model.

How it differs from related concepts

Transaction: a request for state change. Block: a batch or commitment containing updates. Confirmation: evidence that the transaction is part of an accepted history.

Explore further

Official background: technical documentation.

Related glossary terms: Confirmation, Transaction Finality, Chain Reorganization.