External Block Builder

Overview

Traditional block producers both choose transactions and publish the block. External block building separates those functions. Builders gather public mempool transactions, private submissions, and bundles, then optimize the block for fees, maximal extractable value, or other objectives.

A relay or protocol mechanism can connect builders with proposers while hiding the full payload until the proposer commits to it. The proposer chooses among valid bids and signs the selected block. Full nodes still verify consensus rules, so a builder cannot make invalid content acceptable.

Specialization can increase revenue and reduce computational demands on validators. However, a small number of builders can gain influence over transaction ordering and access to private order flow. They may censor transactions, favor affiliated services, or create systemic dependency on relays.

Monitoring should measure builder concentration, inclusion behavior, failed payload delivery, and fallback performance. Protocol designs may add inclusion lists or local-building options to reduce censorship risk.

Users should distinguish an external builder from a sequencer or validator. The builder proposes transaction content, while another actor usually holds final block-proposal authority. The exact division varies by network and implementation.

Failure handling is important because the proposer may receive an invalid, late, or unavailable payload. Networks and validators need a fallback path for local block construction or alternate builders so one service cannot halt production. Economic incentives should reward timely valid delivery, not only high bids. Transparency around builder identity and relay policies helps operators understand whether nominal competition depends on the same underlying infrastructure.

Validators should verify payload validity independently before signing or publishing the proposed block.