Use MEV-Boost

With MEV-Boost, your validator can propose blocks built by external builders, who bid for the right to fill your block. Bids reach you through relays. MEV-Boost runs alongside your beacon node, asks your relays for the best bid, and Prysm uses it if it pays more than the block your execution client builds. Most mainnet blocks are built this way.

Operating system

Linux or macOSWindows

Network

MainnetHoodi testnet

Until the Gloas fork

This page applies until your network forks into Gloas. After that, your beacon node gets bids from builders itself, and MEV-Boost is optional. See Use builders after Gloas (ePBS).

Before you begin

• A synced execution client, beacon node, and validator client. Your execution client stays required: Prysm always builds a local block too, as a fallback.
• A fee recipient. Builders pay it.

What you trust

Your validator signs a builder's block before seeing its transactions. If the relay then fails to publish the block, you miss the proposal. Relays also decide which transactions reach your blocks. Use relays you trust, and more than one. Building locally, without MEV-Boost, is always a valid choice.

Choose relays

The command below uses every working relay from the EthStaker relay list for your network. Prysm doesn't recommend relays: the list describes each one, so remove any you don't want to use. Compare them on:

• Filtering policy. Some relays exclude transactions from sanctioned addresses; others don't.
• Operator and track record. Who runs it, and how it behaved during past incidents.
• Diversity. Several relays from different operators limit the impact of a single failure.

To add a relay, get its URL from the relay’s documentation for the right network. A relay URL looks like https://0x<RELAY_PUBKEY>@<RELAY_HOST>.

Set up MEV-Boost

1. Install and start MEV-Boost from its releases (or the flashbots/mev-boost Docker image), with your relays:

   ./mev-boost \
     -mainnet \
     -color \
     -relay-check \
     -relay https://0xa15b52576bcbf1072f4a011c0f99f9fb6c66f3e1ff321f11f461d15e31b1cb359caa092c71bbded0bae5b5ea401aab7e@aestus.live \
     -relay https://0xa7ab7a996c8584251c8f925da3170bdfd6ebc75d50f5ddc4050a6fdc77f2a3b5fce2cc750d0865e05d7228af97d69561@agnostic-relay.net \
     -relay https://0xb0b07cd0abef743db4260b0ed50619cf6ad4d82064cb4fbec9d3ec530f7c5e6793d9f286c4e082c0244ffb9f2658fe88@bloxroute.regulated.blxrbdn.com \
     -relay https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@global.titanrelay.xyz \
     -relay https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@regional.titanrelay.xyz \
     -relay https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net \
     -relay https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money

   -color keeps the log colors even when the output isn't a terminal, such as in Docker or a service. MEV-Boost listens on localhost:18550. Run it as a service like your other components; its README has an example.

2. Point the beacon node at MEV-Boost. Add --http-mev-relay to your beacon node command and restart it:

   --http-mev-relay=http://127.0.0.1:18550

   The beacon node logs:

   INFO builder: Builder has been configured endpoint=http://127.0.0.1:18550

3. Register your validators. Add --enable-builder to your validator client command and restart it. The validator client needs a fee recipient, set with --suggested-fee-recipient or a proposer settings file.

   The validator tells the relays, through the beacon node and MEV-Boost, which fee recipient and gas limit each key wants. It repeats this every epoch.

To use MEV-Boost for some keys only, leave out --enable-builder and set builder.enabled per key in a proposer settings file. The flag turns the builder on for every key, overriding the file.

Local boost and builder boost factor

Prysm uses the builder block only if:

bid × builder_boost_factor > local_value × (100 + local-block-value-boost)

• --local-block-value-boost (beacon node, default 10) adds a percentage in favor of your local block.
• builder_boost_factor is a percentage the validator client can send with each block request (default 100, neutral; 0 means always local). Prysm's validator client sends the neutral value, so with Prysm you tune --local-block-value-boost instead. Other validator clients connected to a Prysm beacon node may send their own.

Example. With the defaults, the local block is worth 0.050 ETH, and the best bid is 0.054 ETH. The bid side is 0.054 × 100 = 5.4, the local side 0.050 × 110 = 5.5, so Prysm proposes the local block. A bid of 0.056 ETH (5.6) wins. With --local-block-value-boost=0, any bid above 0.050 ETH wins.

When Prysm builds its own block

For each proposal, the beacon node asks MEV-Boost for a bid and builds a local block at the same time. It proposes the local block when:

• MEV-Boost fails or is too slow. There is no valid bid within --builder-header-timeout (1 second). The beacon node proposes the local block, so a broken MEV-Boost costs you MEV, not the proposal. It logs:

  Could not get builder payload

• The chain is missing blocks. A circuit breaker stops using builders after --max-builder-consecutive-missed-slots (default 3) missed slots in a row, or --max-builder-epoch-missed-slots (default 5) missed slots in the last 32. It resets on its own, and logs:

  Circuit breaker activated ...

• The bid is too low. Below --min-builder-bid (Gwei, default 0), or not enough above the local block (see Local boost and builder boost factor).

In each case, the log explains the choice with a line starting:

Proposer: using local execution payload because ...

Check that it works

• Validator: none of these warnings:

  Failed to register validator on builder
  Beacon node does not utilize a custom builder via the --http-mev-relay flag. Validator registration skipped.

• Relays: most relays show your registration by public key:

  curl -s "https://<RELAY_HOST>/relay/v1/data/validator_registration?pubkey=<VALIDATOR_PUBKEY>"

• Proposals: when your validator proposes, the beacon node logs:

  Received header with bid

  If it doesn't, then log why it uses the local block (see When Prysm builds its own block), the builder's block was used. On a block explorer, a builder block usually ends with a payment transaction to your fee recipient.

Troubleshooting

The validator logs:

Beacon node does not utilize a custom builder via the --http-mev-relay flag

The validator has the builder enabled but the beacon node has no --http-mev-relay.

The beacon node logs at startup:

Failed to check builder status

MEV-Boost isn't running, listens elsewhere, or can't reach any relay. Check its logs.

Every proposal uses the local block. The beacon node logs why for each proposal (see When Prysm builds its own block): a low bid, the boost, the circuit breaker, or a timeout.

Missed proposal after signing a builder block. The relay didn't publish it in time. Check the relay's status and consider dropping it.

Don't raise --builder-header-timeout: a slow builder delays your block, which can get it orphaned.

Stop using MEV-Boost

Remove --enable-builder (and builder sections in proposer settings) from the validator, remove --http-mev-relay from the beacon node, restart both, then stop MEV-Boost.