Configure MEV Builder

caution

This guide is for advanced Prysm users to configure their client for the purposes of extracting MEV. There are risks to using a builder which may result in missed rewards, missed proposals, censored transactions or omitted transactions. The Prysm team does not provide guidance on which builders/relays are recommended but lists are available for you to make a judgment based on your own values.

From the Gloas fork, you configure builders on the validator client, and the beacon node needs no builder flag. This page explains what changes at the fork and how a proposal uses builders; the settings themselves are documented in Proposer settings. Until your network reaches the fork epoch, builders are reached through MEV-Boost and relays, described in MEV-Boost (before Gloas). If you use MEV-Boost today, your v1 builder settings stop working at the fork: Migrating from v1 to v2 shows the one change to make, and you can make it now.

The Gloas fork adds proposer-builder separation (ePBS) to the protocol. Builders become on-chain participants with their own index, public key, and staked balance, which backs their bids. MEV-Boost, relays, blinded blocks, validator registration, and --http-mev-relay work until the fork epoch and are not used after it.

What changes at the fork

	Before Gloas (MEV-Boost)	After Gloas (in-protocol)
Builders	Off-chain builders, reached through relays	On-chain builders with staked balances
Where you configure them	Beacon node --http-mev-relay, plus validator registration	Validator client: v2 proposer settings, the --builder-urls flags, or the keymanager builder API. No beacon node builder flag is needed.
Choosing builders	The relay chooses	You list builder URLs per key, and can limit each URL to specific builder public keys
Payment	The builder pays your fee recipient inside the payload; you rely on the relay's reputation	The bid value is paid by the protocol from the builder's on-chain balance. An extra execution_payment is a promise that counts only if you set max_execution_payment.
Fallback to local blocks	Circuit breaker and value comparison	Bids compete with your local block on every proposal, and each builder that fails to deliver is blacklisted individually (steps 4 and 6 below)
Registration	Periodic registerValidator calls sent through the relay	A signed request authentication per builder, sent through the beacon node before each proposal (step 2 below)

How a Gloas proposal uses builders

Numbers match the steps below. The dashed outline marks what you run: bid collection, valuation and blacklisting all happen inside your beacon node, and every arrow that crosses the outline is a call to something you do not control.

1. You configure builders on the validator client. List builder URLs, each with a max_execution_payment, in v2 proposer settings, with the --builder-urls flags, or through the keymanager builder_config endpoints. No beacon node flag is needed.
2. The validator client sends its preferences through the beacon node. From the epoch before each proposal, it signs a request-authentication for each builder and sends it with its max_execution_payment to the beacon node, which forwards it to the builders. The validator client never contacts a builder directly.
3. The beacon node collects bids. At proposal time, it requests bids from your builders in parallel (600ms budget by default, set with --builder-bid-timeout), adds trustless bids received over P2P, and checks each against the chain's rules: an active builder with enough stake, and a bid for your slot, parent block, fee recipient, and gas limit preference.
4. Bids compete with your local block. Each bid is valued at value plus execution_payment up to your max_execution_payment, filtered by min_bid, scaled by builder_boost_factor, and compared with your local payload; ties go to your own block. See How a bid is valued.
5. The winner reveals the payload. Your block commits to the winning bid. The beacon node sends the signed block to that builder, which reveals the payload later in the slot, and the protocol pays the bid value to your fee recipient from the builder's balance. If your own block won, your validator client publishes the payload envelope itself.
6. Builders that don't deliver are blacklisted. If a builder wins and doesn’t reveal its payload, it's blacklisted for the rest of the epoch, or for 256 epochs after a second failure within five; its bids are ignored and not forwarded to peers. If seven or more builders are blacklisted at once, the beacon node uses only its own block.

What you still need to run

• Your execution client. Prysm builds a local block for every proposal, as the fallback and as the baseline bids must beat. If it can't produce a payload, Prysm falls back to the best bid received over P2P.
• If one validator client uses several beacon nodes, Prysm turns on the --stateless validator flag: the validator requests the block and payload envelope together. It republishes the envelope itself, because only the beacon node that built a block can reveal its payload.

Frequently asked questions

Do I need MEV-Boost or relays after the Gloas fork?

No. After the fork, you configure builders in v2 proposer settings. If you don't configure any, your validator requests no builder bids; only trustless bids broadcast over P2P can still beat your own block.

I use MEV-Boost today and do nothing before the fork. What happens?

Everything keeps working until the fork epoch. At the fork, your v1 builder settings and --enable-builder stop having any effect, and your validator proposes its own blocks without requesting builder bids. To keep using builders, migrate to v2 proposer settings; you can do it now.