Ethereum MEV-Boost: How Builders, Relays, and Validators Work

MEV-Boost is open-source middleware that Ethereum validator operators can run to request externally built block bids from builders through relays. A builder assembles transactions; relays check bids and make a blinded execution-payload header available; the proposer selects an offer, signs a blinded block, and the relay then returns the full payload. This is an off-protocol implementation of proposer-builder separation for proof-of-stake Ethereum. It can widen access to block-building competition, but it does not remove MEV, eliminate relay trust, or guarantee censorship resistance.

What MEV means on Ethereum

Ethereum.org defines maximal extractable value (MEV) as value captured from block production beyond the standard block reward and gas fees by including, excluding or changing the order of transactions. Searchers look for opportunities; builders and proposers influence which transactions make it into a block and where they appear.

MEV is not a synonym for fraud. Arbitrage and lending liquidations can help protocols correct price differences or keep loans solvent; sandwich trading can worsen a user’s trade execution. MEV-Boost changes how a proposer obtains a block. It does not decide whether every strategy inside that block is beneficial to users.

The four roles in the MEV-Boost pipeline

Role	What it does
Searcher	Finds a transaction-ordering opportunity and sends transactions or bundles through a public or private route.
Builder	Combines transactions into an execution payload, chooses their ordering and submits a bid to one or more relays.
Relay	Checks builder payloads and bids, aggregates offers and coordinates the blinded-header and payload handoff.
Proposer (validator)	Uses MEV-Boost to compare available bids, signs the selected blinded block and publishes the completed block after the payload is revealed.

These roles describe the infrastructure path, not a fixed company structure: one operator may run more than one component, and each participant may choose different software or counterparties.

How a block moves from bid to proposal

Transactions reach builders. Users and searchers send transactions or bundles through public or private transaction routes. Builders assemble candidate execution payloads using the proposer’s registered block parameters.
Builders submit bids to relays. A bid states the value offered to the proposer. A relay simulates and checks the submitted payload, including whether it satisfies the block attributes and pays the expected fee recipient.
MEV-Boost gathers candidate headers. The proposer’s MEV-Boost sidecar queries its configured relays. A relay returns an execution-payload header without the transaction contents; MEV-Boost presents the most valuable valid payload it has received from those relays.
The proposer signs a blinded block. The validator commits to the selected header before receiving the full execution payload. The relay verifies the proposer’s signature and returns the corresponding payload body.
The validator proposes the completed block. The validator combines the revealed execution payload with the consensus-layer block and broadcasts it to the network.

The “blinded” step is the key handoff: the proposer can select a bid without first inspecting the block’s transaction list. The relay, by contrast, sees the full blocks submitted by builders in order to check them and manage delivery.

What MEV-Boost changes—and what it does not

MEV-Boost separates block construction from block proposal through external software. Validator operators can connect to multiple relays, and a relay can aggregate bids from multiple builders. That gives proposers access to a marketplace of externally built blocks instead of requiring each validator to run its own specialized builder.

The trust trade-off is explicit in Flashbots’ relay documentation: builders rely on a relay for fair payload routing, while proposers rely on it for block validity, accuracy and data availability. Multiple relay connections can broaden the available set, but do not remove the need to assess relay operators, their policies and their reliability. Flashbots also notes that fallback or “circuit breaker” behaviour depends on the consensus client, so operators should check what their own client does when external block sourcing is unavailable.

MEV itself remains possible because transaction inclusion and ordering still affect outcomes. MEV-Boost is not a user privacy tool, does not automatically prevent sandwich trades and does not guarantee that builders or relays include every valid transaction. Separating roles can encourage competition; it is not a proof that the market is decentralised or censorship-resistant in every slot.

MEV-Boost and enshrined PBS are not the same thing

MEV-Boost is middleware that validators run outside the Ethereum consensus protocol. Enshrined proposer-builder separation (ePBS) is a proposed protocol-level design. EIP-7732 describes changes that would separate consensus and execution parts of a block and let a consensus proposer choose an execution proposer. As checked on 27 September 2026, the EIP page labels the proposal “Review”; that status is not evidence that ePBS is live on Ethereum mainnet.

For adjacent engineering context, our Glamsterdam gas-testing checklist covers execution-layer assumptions that can affect block construction, while our ERC-7730 clear-signing guide looks at what users can inspect when they approve a transaction. Those are related but separate layers: neither replaces relay-policy review.

A practical checklist for validator operators

Map the counterparties. Record which builders and relays your setup can reach, who operates them and what selection or filtering policies they disclose.
Review relay diversity. Multiple endpoints are useful only if they do not all depend on the same operator, infrastructure or policy assumptions.
Understand fallback behaviour. Check your consensus client’s circuit-breaker conditions, local block-production path and recovery behaviour against its own documentation.
Monitor delivery, not just bids. Track payload availability, response times and missed-proposal incidents alongside proposed value; an attractive bid is not useful if the handoff is unreliable.
Separate facts from assumptions. Treat a relay’s published policy and transparency data as evidence to inspect, not as a guarantee that every block is neutral or censorship-free.

Frequently asked questions

Does MEV-Boost remove MEV?

No. It changes how validators obtain execution payloads by connecting them to builders through relays. Transaction ordering and inclusion still create opportunities for value extraction, including strategies that may help protocols and strategies that can harm users.

Can a validator see the transactions before signing?

In the MEV-Boost blinded-block flow, the proposer receives an execution-payload header without the transaction contents and signs the blinded block first. After the relay verifies the signature, it returns the full payload. The relay itself can inspect builder payloads as part of its validation and delivery role.

Is enshrined proposer-builder separation already live?

EIP-7732 is a proposal for protocol-level PBS, distinct from MEV-Boost middleware. Its official page showed status “Review” on 27 September 2026; do not treat that label as a mainnet activation notice.

Sources

Ethereum.org: Maximal extractable value (MEV) — definition, searchers and examples of positive and negative effects.
Ethereum.org: MEV-Boost — validator sidecar and external block-building marketplace.
Flashbots Docs: MEV-Boost overview — middleware and proposer-builder separation context.
Flashbots Docs: Block proposal — header, blinded signature and payload-reveal sequence.
Flashbots Docs: Relay fundamentals — relay responsibilities, trust assumptions and fallback context.
EIP-7732: Enshrined Proposer-Builder Separation — protocol-level proposal and current status.

If your Ethereum product depends on transaction routing, wallet coordination or validator-side infrastructure, talk with SignorCrypto about a scoped integration review.