Block Building

Overview

Block building turns pending transactions and required protocol data into a candidate block. A builder must respect gas or weight limits, nonce dependencies, validity rules, mandatory operations, and state conflicts while choosing an ordering that may maximize fees or other revenue.

Some networks let the validator build locally, while proposer-builder separation allows specialized external builders to compete. Private order flow, bundles, and maximal extractable value can influence which transactions appear and where, creating fairness, censorship, and concentration concerns. Applications should not assume that broadcasting guarantees prompt inclusion or first-seen ordering. Wallets need replaceable fee strategies and expiration controls. Payment monitoring should distinguish mempool visibility, builder acceptance, block inclusion, execution success, and finality, because each stage can fail Block Building should be described within the complete block-production pipeline: transaction intake, candidate construction, ordering, execution or validation, proposal, propagation, and canonical acceptance. Control of one stage does not necessarily imply control of every stage.

Ordering policy, private transaction flow, censorship, and concentration should be evaluated alongside nominal block-production performance. The incentives around Block Building can include fees, priority payments, MEV, builder or proposer payments, and missed-opportunity costs. Implementations of Block Building need deterministic validity checks, current protocol rules, capacity limits, and a defined response when a candidate becomes stale or conflicts with the canonical head. A locally built or accepted candidate is not proof of final inclusion. Payment systems should rely on canonical block evidence rather than internal production or auction events. Monitoring should track construction time, failed candidates, propagation, inclusion, reorganization, and dependencies on relays or external builders.