Builder API

A Builder API is a standardized RESTful interface defined by the mev-boost protocol that enables block builders to submit complete, fee-optimized execution payloads to validators (proposers). This separation of block building from block proposing is a core component of proposer-builder separation (PBS), designed to decentralize Maximal Extractable Value (MEV) extraction and improve network efficiency. The API allows specialized builders, who aggregate and order transactions, to compete to have their block included by the winning validator for an epoch.

The technical flow begins when a validator, using middleware like mev-boost, queries connected builders via the Builder API's getHeader endpoint. Builders respond with a block header and a commitment to pay the validator a fee (the bid). The validator selects the most profitable header and signs a commitment. Later, via the getPayload endpoint, the validator requests the full block body corresponding to the chosen header, which it then proposes to the network. This ensures the validator never sees the transaction order until after commitment, mitigating certain MEV-related risks.

Key endpoints of the Builder API include status, registerValidator, getHeader, and `getPayload**, which facilitate the auction mechanism for block space. Builders use sophisticated algorithms to construct blocks by including MEV opportunities—such as arbitrage and liquidations—bundled by searchers, alongside regular user transactions. The winning builder's payload is cryptographically committed to in the header, ensuring the validator cannot steal the bundle or alter the block after seeing its contents.

The adoption of the Builder API, primarily on Ethereum following The Merge, has created a competitive marketplace for block production. This has led to increased validator rewards from MEV and improved network security. However, it has also raised concerns about builder centralization, as a small number of entities often win the majority of blocks. Ongoing protocol developments, like enshrined PBS (ePBS), aim to further decentralize this layer by moving the auction mechanism into the core consensus protocol itself.

The Builder API is a standardized RESTful interface that allows specialized block builders to receive transaction bundles from users and submit complete, signed execution payloads to validators. It operates on a sealed-bid auction model, where builders compete by constructing the most valuable block possible—maximizing MEV (Maximal Extractable Value) and transaction fees—and submitting their block along with a bid to the validator. The validator, or a relay acting on its behalf, selects the highest-paying valid block to propose to the network. This separation of block building from proposal is the foundation of proposer-builder separation (PBS).

The workflow begins when a searcher or user submits a transaction bundle to a builder via the API's eth_sendBundle endpoint. The builder's complex optimization engine, often called the builder backend, then assembles these bundles with transactions from the public mempool. It simulates the block to calculate its total value, which includes standard gas fees and any extracted MEV. The builder cryptographically signs the completed block and submits it, along with a commitment to pay the validator (the bid), to a trusted relay using the eth_sendExecutionPayload endpoint. The relay validates the block's contents and the bid before making it available to validators.

Validators access these competing blocks through a separate proposer API, typically provided by the same relay. Using the eth_getPayload endpoint, the validator's consensus client requests the block header for the current slot. The relay returns the header of the highest-bid, valid block from its builder auction. The validator signs this header, committing to propose the associated full block, and receives the full execution payload from the relay to broadcast to the network. The builder's payment to the validator is often facilitated through the relay's payment contract on Ethereum.

This architecture creates distinct market roles: builders compete on capital and optimization skill, relays ensure censorship resistance and validity, and proposers (validators) simply select the highest reward. Key technical specifications for the Builder API are defined in Ethereum's Engine API and the community-driven builder-specs repository. The system is designed to be permissionless for builders, though in practice, validator software often integrates with a curated list of reputable relays to mitigate security risks.

The Builder API's primary impact is the professionalization of block production. By outsourcing construction to competitive, specialized entities, it aims to democratize MEV access, improve network efficiency, and reduce the computational burden and ethical risk on individual validators. However, it also introduces centralization pressures around dominant builder and relay services, an active area of protocol development with solutions like enshrined PBS being researched for future Ethereum upgrades.

The Builder API flow begins when a user signs and broadcasts a transaction to the network. Instead of being sent directly to a validator (or proposer), the transaction is routed to a specialized entity known as a block builder. Builders aggregate transactions from the public mempool and private order flows, constructing optimized execution payloads—candidate blocks designed to maximize revenue through transaction fees and MEV (Maximal Extractable Value) extraction strategies. This process is facilitated by the Builder API endpoint, which builders operate to receive bundles and bids.

Once a builder has assembled a candidate block, it submits a sealed bid to a relay. The bid contains the execution payload and a commitment to pay the validator (proposer) a specified amount for including it. The relay, acting as a trusted intermediary, validates the bid's correctness—checking fee payments, execution state, and compliance with consensus rules—and maintains a censorship-resistant marketplace. It then exposes this validated block data to validators via a separate proposer API, presenting them with the most profitable options.

The final stage occurs when a validator is selected to propose the next block. The validator's consensus client queries connected relays via the proposer API to receive the header of the highest-bidding, valid payload. The validator signs this header, committing to the block, and receives the builder's payment. The relay then reveals the full execution payload to the validator, who publishes it to the network. This flow decouples block construction from proposal, enhancing network efficiency and enabling specialized, competitive markets for block space.

A Builder API is a RESTful HTTP specification that defines how searchers (or users) submit transaction bundles and how block builders communicate block proposals to validators (or proposers). Its creation was driven by the need for a common protocol after Ethereum's transition to Proof-of-Stake, which separated the roles of block building and proposal. This standardization, notably through efforts like the mev-boost relay architecture, prevents ecosystem fragmentation and allows validators to efficiently access blocks built by specialized, competitive builders from a permissionless marketplace.

The API's core function is to facilitate a sealed-bid auction for block space. Searchers submit bundles—ordered sets of transactions with conditional execution logic—to builders via the API endpoint eth_sendBundle. Builders then aggregate these bundles, along with transactions from the public mempool, to construct the most profitable block possible. They submit their complete block header and a fee bid to a relay using eth_sendBlindedBlock. The relay validates the block's contents and forwards the most lucrative, valid header to the validator, which only learns the full block contents after committing to it.

Key technical components include blinded blocks and commit-reveal schemes. When a validator receives a blinded block proposal via eth_getHeader, it sees only the block header and the associated bid, not the transactions inside. This prevents the validator from stealing the builder's work. Upon choosing a header, the validator signs a commitment and requests the full block body via eth_getPayload. This process enforces Proposer-Builder Separation (PBS) by design, limiting the validator's role to selection and attestation rather than construction.

The evolution of the Builder API is closely tied to MEV (Maximal Extractable Value) infrastructure. It enables complex MEV extraction strategies like arbitrage and liquidations by providing a private, ordered channel for searcher transactions. Builders can optimize for total value, which includes both the transaction fee bid and any MEV captured within the bundle. Standards like those maintained by the Flashbots collective ensure interoperability, allowing the network of builders, relays, and validators to function as a cohesive, efficient market for block production.

Looking forward, the Builder API represents a transitional design. While it successfully organizes the block building market off-chain, Ethereum's roadmap includes in-protocol Proposer-Builder Separation (ePBS) as a potential future upgrade. ePBS aims to bring the commitments and anti-censorship properties of the builder ecosystem directly into the core consensus protocol, reducing reliance on trusted off-chain relays and further decentralizing the block production process.