Block Inclusion

Overview

Before inclusion, a transaction may exist only in a node’s mempool or private order-flow system. A block producer selects the transaction, verifies that it fits the block’s resource limits and ordering rules, and places it in a candidate block.

Inclusion gives the transaction its first on-chain confirmation, but it is not necessarily final. The block can be replaced during a reorganization, and some protocols distinguish an included block from a justified or finalized block.

Users influence inclusion through fees, transaction validity, nonce order, dependencies, and network propagation. A high fee does not guarantee immediate inclusion if the transaction is invalid, conflicts with another transaction, or depends on missing prior state.

For payment systems, inclusion is a major state transition: the payment moves from merely broadcast or detected to recorded in a block. The merchant must still apply the required confirmation or finality policy before considering the payment settled.

A transaction can be included after spending time in a public or private transaction pool, or it may be submitted directly to a producer or builder. Inclusion depends on validity, available block capacity, fee competitiveness, and ordering constraints such as account nonces.

Reliable payment systems record the block hash, block height, transaction index, and observed confirmation state. If the containing block is removed from the canonical chain, the payment should return to a pending or re-evaluation state rather than remain permanently marked as settled. Inclusion proofs can demonstrate that a transaction is committed to a block, but they do not by themselves prove that the block is canonical or finalized.