MEV-Boost

The core architectural principle of MEV-Boost is Proposer-Builder Separation (PBS), which decouples the roles of the block proposer (validator) and the block builder. This design allows validators to receive pre-built, MEV-optimized blocks from a competitive marketplace without needing to run complex MEV extraction software themselves. Key components include:

• Builder: Specialized entity that constructs blocks, bundling transactions and extracting MEV.
• Relay: Trusted intermediary that receives blocks from builders and delivers them to proposers, ensuring payload validity and censorship resistance.
• Proposer: The Ethereum validator who simply selects and proposes the most profitable block header.

MEV-Boost creates a permissionless, competitive auction for block space. Builders compete to create the most valuable block by including MEV opportunities like arbitrage and liquidations. They submit their complete block, along with a bid (the proposed validator payment), to relays. The validator (proposer) then selects the block header associated with the highest bid via the MEV-Boost software. This marketplace efficiently routes MEV profits to validators and stakers, increasing consensus participation rewards.

Relays are critical, trusted intermediaries in the MEV-Boost ecosystem. They perform several essential functions:

• Aggregate Bids: Collect block bids from multiple builders.
• Validate Payloads: Cryptographically verify that builder-submitted blocks are valid and comply with consensus rules before presenting them to proposers.
• Mitigate Censorship: By aggregating from many builders, relays help prevent transaction censorship. However, reliance on a small set of relays has raised concerns about centralization.
• Ensure Data Availability: Guarantee the full block data is available after a header is chosen.

To address trust assumptions in PBS, Ethereum core developers are working on in-protocol Proposer-Builder Separation. A key mechanism for this is the commit-reveal scheme with crLists (censorship resistance lists).

• The proposer commits to a block header without seeing the full block.
• The proposer also publishes a crList: a list of eligible, non-censored transactions from the mempool.
• The builder must include all transactions from the crList (if they fit), or prove they didn't fit. This protocol-level enforcement mitigates transaction censorship by builders.

MEV-Boost exposes the extreme variance in MEV rewards, where a few validators win highly profitable blocks while others get none. MEV smoothing refers to protocols and practices designed to distribute MEV rewards more evenly across all validators. Solutions include:

• Smoothing Pools: Validators can join a pool that shares MEV rewards proportionally.
• Distributed Validator Technology (DVT): Splits a validator's key among multiple operators, which can use MEV-Boost collectively.
• The goal is to reduce validator income inequality and improve network stability.

The Validator (or Proposer) is an Ethereum node operator selected to propose the next block. In the MEV-Boost model, the proposer does not build its own block. Instead, it outsources this task by broadcasting a signed blinded header to a network of Relays. It then selects and signs the most profitable block header received, committing to include the full block body later.

A Builder is a specialized actor that constructs full, execution-ready blocks to maximize Maximal Extractable Value (MEV). Builders compete in a first-price sealed-bid auction by:

• Aggregating transactions from the public mempool and private order flows.
• Optimizing transaction ordering for arbitrage, liquidations, and other MEV opportunities.
• Submitting their complete block and a bid (the proposed tip) to Relays. The builder whose block is chosen forfeits their bid to the winning proposer.

A Relay is a trusted, neutral intermediary that facilitates the block auction between Builders and Proposers. Its critical functions are:

• Censorship Resistance: Receives blocks from many builders, ensuring proposers see a diverse set.
• Bid Privacy: Holds builder bids in a sealed auction, preventing front-running.
• Block Validation: Verifies the correctness (e.g., pays fee recipient, is valid) of each submitted block before forwarding the header to proposers.
• Data Availability: Safeguards the full block body, delivering it to the proposer upon commitment.

A Searcher is an entity (often a bot or trading firm) that identifies and exploits MEV opportunities by crafting transaction bundles. They do not build full blocks. Instead, they submit these bundles to Builders (or directly to relays that accept them), paying a fee for inclusion. Common strategies include:

• Arbitrage: Exploiting price differences across DEXs.
• Liquidations: Triggering and profiting from undercollateralized loan positions.
• Sandwich Attacks: Profiting from large DEX trades by placing orders before and after them.

The Block Auction is the core market mechanism of MEV-Boost. It is a first-price sealed-bid auction conducted for each Ethereum slot:

1. Builders submit full blocks and their bids to Relays.
2. The Relay validates blocks and presents only the block headers and associated bids to the Proposer.
3. The Proposer selects the header with the highest bid, signs it, and returns it to the relay.
4. The relay delivers the corresponding full block body to the proposer for propagation to the network. The winning builder's bid is paid to the proposer.

Proposer-Builder Separation (PBS) is the foundational design principle that MEV-Boost implements in practice. It formally separates the two key functions of a validator:

• Proposing: The right to choose a block (held by the validator).
• Building: The ability to construct a block (specialized by builders). This separation mitigates centralization risks by preventing validators from needing massive capital and infrastructure to capture MEV. PBS is intended to be enshrined directly into the Ethereum protocol in future upgrades.

MEV-Boost operates as a relay network sitting between validators (proposers) and specialized block builders. The validator runs MEV-Boost software, which connects to multiple relays. Builders construct full blocks with optimized transaction ordering and bundles, then submit sealed bids (block bids) to relays. The validator receives the header of the highest-paying block and proposes it, without seeing the block's contents, ensuring proposer-builder separation (PBS).

A competitive ecosystem of searchers and builders drives MEV extraction. Searchers run algorithms to identify profitable opportunities (e.g., arbitrage, liquidations) and submit transaction bundles to builders. Builders aggregate these bundles and regular mempool transactions, constructing the most valuable block possible. They then submit their block along with a bid (the proposed validator payment) to relays. This market ensures validators capture value from sophisticated MEV strategies without executing them directly.

Relays are critical, trusted intermediaries that:

• Receive and validate blocks from builders.
• Ensure blocks are valid (e.g., correct execution, pay the promised fee).
• Hold the full block in escrow.
• Transmit only the block header to the proposer.
• Release the full block upon a valid signature. This model introduces a trust assumption: the relay must not censor transactions or withhold blocks. The ecosystem relies on a decentralized set of reputable relays to mitigate this risk.

In Layer 2s (especially Optimistic and ZK Rollups), MEV dynamics shift to the sequencer. MEV-Boost's model inspires L2 solutions for fair sequencing. Key concepts include:

• Proposer-Builder Separation (PBS): Adopted to prevent sequencers from exploiting user transactions.
• Shared Sequencing: A neutral, decentralized network for ordering transactions across multiple L2s, creating a builder market similar to Ethereum L1.
• MEV Auction on L2: Sequencers can auction the right to build a batch, with proceeds potentially shared with the L2's decentralized protocol or its users.

The MEV-Boost model provides significant advantages:

• Increased Validator Rewards: Validators earn substantial extra income from block bids, improving staking yields.
• Network Efficiency: Professional builders optimize block space, increasing total value settled per block.
• Reduced Centralization Pressure: By outsourcing complex MEV capture, smaller validators can compete with large, sophisticated staking pools.
• Transparent MEV Redistribution: Makes MEV extraction a visible, auction-based process rather than a hidden, gas-price competition.

The model introduces new complexities and risks:

• Relay Centralization: A small number of relays handle most blocks, creating a potential censorship vector.
• Builder Centralization: The most sophisticated builders may dominate, reducing competition.
• Complexity & Latency: Adds operational complexity for validators and tight latency requirements for the builder-relay-proposer pipeline.
• In-Protocol PBS: The current model is "out-of-protocol." Ethereum's roadmap includes enshrining PBS (ePBS) in the consensus layer to mitigate trust assumptions.

The market for block builders can become highly concentrated, with a few dominant builders winning most auctions. This creates systemic risk, as a malicious or compromised builder could:

• Censor specific transactions.
• Produce invalid blocks that cause validator slashing.
• Manipulate the auction to extract excessive value. Reliance on a single builder's software stack also creates a single point of failure.

Validators must trust the relayer to perform two critical functions honestly:

1. Data Availability: The relayer must deliver the full block data after the validator has signed the header.
2. Payload Attribution: The relayer must correctly attribute the builder's payload to the winning bid. A malicious relayer could perform a data withholding attack, causing the validator to sign for a block they cannot publish, leading to an equivocation slashing penalty.

The separation of block building and proposing enables new bribery attacks. A malicious actor could:

• Bribe a validator to select a specific builder's bid, even if it's not the highest, to enable censorship.
• Extort a validator by threatening to withhold the block data unless an additional payment is made (timeliness attack). These attacks exploit the time gap between header signing and data delivery.

Block builders have significant power to manipulate transaction ordering. Risks include:

• Sandwich attacks and frontrunning executed by the builder itself, stealing user MEV.
• Inclusion of malicious smart contracts or revert bombs designed to waste validator gas or disrupt the network.
• Time-bandit attacks, where a builder withholds a profitable block to reorg the chain if a more profitable opportunity arises later.

The MEV-Boost protocol itself has inherent complexities that can be exploited:

• Bid Spoofing: A builder could submit a high bid to win the auction, then fail to deliver the payload, causing the validator to miss a slot.
• Header vs. Body Mismatch: If the delivered block body does not correspond to the committed header, the validator is forced to propose an empty block, losing rewards.
• PBS (Proposer-Builder Separation) Weaknesses: The current implementation is permissioned and off-chain, relying on relays as trusted intermediaries.

The ecosystem is developing solutions to mitigate these risks:

• Validator Diversity: Using multiple, reputable relays to distribute trust.
• Minimum Bid Policies: Setting a floor to avoid accepting unprofitably low bids from malicious actors.
• Inclusion Lists: A protocol feature allowing proposers to mandate certain transactions be included, countering censorship.
• Encrypted Mempools & SUAVE: Future solutions aim to encrypt transaction content until execution, reducing builder extractable information.

A design paradigm that separates the roles of block building and block proposing to democratize MEV access and reduce centralization risks. In PBS:

• Builders compete to create the most profitable blocks by including transactions and MEV.
• Proposers (validators) simply select the most valuable block header from a marketplace. MEV-Boost is the primary implementation of PBS for Ethereum's consensus layer.

Specialized entities that construct execution payloads (blocks) by ordering transactions to maximize MEV revenue. They:

• Run sophisticated algorithms (arbitrage bots, liquidations) to identify profitable opportunities.
• Bundle these opportunities with regular user transactions.
• Submit complete block bids to a relay, competing to have their block chosen by a validator. Major builders include Flashbots, BloXroute, and Titan Builder.

The end-to-end flow of value extraction, from opportunity identification to block inclusion. Key participants are:

• Searchers: Find and simulate profitable on-chain opportunities (e.g., arbitrage).
• Builders: Aggregate searcher bundles and user transactions into optimized blocks.
• Relays: Operate the marketplace for block headers.
• Proposers (Validators): Finalize the block and earn the majority of the MEV revenue via the builder's bid.

The real-time, first-price auction mechanism at the heart of MEV-Boost. Each slot (12 seconds), builders submit sealed bids to relays, specifying:

• A block header (hash, parent hash, etc.).
• An execution payload (the full block data).
• A fee (in ETH) paid to the proposer. The proposer selects the header with the highest fee, commits to it, and later receives the full block from the winning builder's relay for execution.

A proposed long-term evolution where PBS is natively integrated into the Ethereum protocol, replacing the current trusted, off-protocol MEV-Boost design. Goals of ePBS include:

• Reducing trust assumptions by removing the need for permissioned relays.
• Enhancing censorship resistance through protocol-level guarantees.
• Improving efficiency and security of the block auction. This is a major focus of Ethereum protocol research.