Block Production

Overview

Block production begins when an eligible participant gathers valid transactions and required protocol operations, orders them, executes or verifies the resulting state transition, and constructs a candidate block. The candidate is signed, mined, or otherwise proven according to the network’s consensus rules. Peers independently validate the proposal before extending it. Competing proposals, missed slots, invalid payloads, network delay, or censorship can affect which transactions appear and which branch survives. Production therefore differs from finality. Payment operations should measure block intervals, inclusion delays, reorganization rates, and finalized progress. A chain may keep producing blocks while a particular transaction remains pending, fails during execution, or appears on a discarded branch. Monitoring must follow both transaction receipts and the canonical consensus state.

Monitoring should track construction time, failed candidates, propagation, inclusion, reorganization, and dependencies on relays or external builders. Payment systems should rely on canonical block evidence rather than internal production or auction events. Control of one stage does not necessarily imply control of every stage. Block Production should be described within the complete block-production pipeline: transaction intake, candidate construction, ordering, execution or validation, proposal, propagation, and canonical acceptance.

The incentives around Block Production can include fees, priority payments, MEV, builder or proposer payments, and missed-opportunity costs. Ordering policy, private transaction flow, censorship, and concentration should be evaluated alongside nominal block-production performance. A locally built or accepted candidate is not proof of final inclusion. Implementations of Block Production need deterministic validity checks, current protocol rules, capacity limits, and a defined response when a candidate becomes stale or conflicts with the canonical head.