MEV-Boost for Ethereum validators: setup and relay configuration

What MEV-Boost changes for an Ethereum validator

MEV-Boost addresses a specific division of labor in proof-of-stake Ethereum. A validator normally operates more than one program: a validator client, a consensus client, and an execution client. MEV-Boost adds a sidecar for the beacon node that sends block-building requests to a marketplace of relays instead of requiring the validator stack to construct every proposed block itself.

The project is intended for PoS Ethereum node operators, including solo validators. Its README states that it is compatible with any Ethereum consensus client, although the operator still has to configure that client to work with MEV-Boost. It is not a standalone Ethereum node. The validator client remains responsible for validator duties, while the consensus client remains responsible for consensus-layer participation, and the execution client remains part of the execution-layer stack.

MEV-Boost therefore solves a routing and selection problem. Builders prepare full blocks from transaction orderflow, and relays collect submissions from multiple builders. A relay selects a block based on the fees it has seen, while MEV-Boost can query more than one relay for a validator. This can give the proposer access to competing block opportunities without coupling the validator operator to one builder.

That benefit also creates a trust boundary. The validator is not simply accepting a block from the consensus client. It is accepting an externally built proposal through a relay marketplace. The README describes the design as proposer-builder separation and links to the Ethereum Builder API specifications, but it does not provide a policy for choosing trusted relays. Relay diversity, endpoint validation, and monitoring belong in the operator's deployment plan.

The relay request path from builder to attestation

The documented request path starts with builders. Builders assemble complete Ethereum blocks, including transaction orderflow and a fee intended for the block-proposing validator. They submit those blocks to relays. A relay aggregates blocks from multiple builders and chooses the block with the highest fees, according to the README.

One MEV-Boost instance can be configured with multiple relays. That matters because relay competition is part of the design. Configuring several endpoints gives the sidecar more than one source of block submissions, but the README does not claim that all relays will see identical blocks, apply identical policies, or fail at the same time. The operator still needs to decide how many relays to use and how to interpret differences between them.

The consensus-layer client uses MEV-Boost when it needs a block proposal. The client selects the most profitable block that MEV-Boost has made available, then proposes it to Ethereum for attestation and block inclusion. MEV-Boost is consequently a request-forwarding and selection layer, not the software that signs attestations or finalizes blocks.

The project exposes a default server port of 18550. The repository includes a Dockerfile that exposes that port and uses the binary as its container entry point. The README also mentions a builder API and a test CLI, so operators can inspect the API surface during deployment planning, but the available project documentation does not provide a complete production request trace or a documented relay failover policy.

Installing MEV-Boost from Go or a release binary

The README lists binaries for Linux, Windows, and macOS at the project's releases page. For source installation, it documents `go install`, but the repository's current `go.mod` declares `go 1.24.0`. The README's source section says Go 1.18+, while the repository file requires a newer Go toolchain for a checkout. An operator building from the current branch should therefore follow the repository requirement rather than assuming the older README sentence is sufficient.

The shortest documented installation path installs the latest release and displays the command help:

go install github.com/flashbots/mev-boost@latest
mev-boost -help

The first command obtains the Go package, and the second checks that the installed executable can start far enough to print its options. The README does not show where `go install` places the binary or how to add `$GOPATH/bin` to `PATH`, so those steps depend on the local Go installation.

For a source checkout, the repository documents a stable branch and tagged release checkout before building with `make build`:

git clone https://github.com/flashbots/mev-boost.git
cd mev-boost
git checkout stable
make build
./mev-boost -help

Use the stable branch when the intent is the latest released version, according to the README. The default `develop` branch can include merged changes that have not yet become a release. The build command uses the repository's Makefile and produces a local `mev-boost` executable. The README does not give a production systemd unit in the visible text, so this build step verifies the binary but does not establish a complete validator service configuration.

A first local run with Docker and the default port

The repository publishes a Docker image under `flashbots/mev-boost`. The README gives a direct way to pull the latest image and ask the program for its help output. This is a useful first check before wiring the sidecar into a beacon client.

docker pull flashbots/mev-boost:latest
docker run flashbots/mev-boost -help

The Dockerfile builds the Go service in a builder stage, copies the resulting executable into an Alpine image, and sets `/app/mev-boost` as the entry point. It also exposes port 18550. The visible Dockerfile does not publish that port with `docker run -p`, so the command above checks the executable rather than starting a reachable service for another container.

For a real service deployment, the operator needs more than the image name. It must connect the beacon client to MEV-Boost, provide relay endpoints, and ensure that the listen address is reachable only where intended. The `.env.example` records `BOOST_LISTEN_ADDR=localhost:18550`, which binds the service to localhost by default. That is a safer starting point for a sidecar on the same machine than exposing the API broadly, but the file is an example and does not by itself configure a running process.

The README says the most common setup places MEV-Boost on the same machine as the beacon client, and that multiple beacon clients can use one MEV-Boost instance. A first real use should therefore include the full client-to-sidecar connection configuration, which is not shown in the visible README excerpt.

Relay configuration and minimum bid controls

Relay selection is the main operational decision in MEV-Boost. The `.env.example` defines `RELAYS` as a single entry or a comma-separated list in the form `scheme://pubkey@host`. This means that a plain host name is not the documented shape of a relay entry. The relay endpoint includes a scheme, public key, and host, which allows the sidecar to identify the relay while making requests.

The example file also defines `MIN_BID_ETH=0`. This is a minimum bid value expressed in ETH, and the README has a dedicated section for setting a minimum bid with `-min-bid`. A zero minimum does not impose a documented positive threshold. An operator using a minimum bid should confirm the command-line or configuration path that actually supplies the value in the deployed release, because the visible README excerpt does not include the full argument list.

Several timeout and retry settings are exposed in the example environment file. `RELAY_TIMEOUT_MS_GETHEADER` is set to 950, `RELAY_TIMEOUT_MS_GETPAYLOAD` to 4000, and `RELAY_TIMEOUT_MS_REGVAL` to 3000. `REQUEST_MAX_RETRIES` is set to 5. These are concrete configuration knobs, but they also show that relay behavior depends on network timing and retry decisions. The README does not document whether retries can duplicate validator registration requests or whether a failed relay causes a particular selection outcome, so those details require checking in the chosen version's API documentation and logs.

Network selection is separate from relay selection. The example file provides `MAINNET=true`, `SEPOLIA=false`, and `HOLESKY=false`, along with `GENESIS_FORK_VERSION` and `GENESIS_TIMESTAMP` for custom genesis settings. A misconfigured network can prevent a sidecar from matching the validator's expected chain, even if its relay endpoint is reachable.

Operational limits, trust assumptions, and alternatives

The first limitation is architectural: MEV-Boost cannot make a validator function by itself. The README requires a validator client, consensus client, and execution client, with MEV-Boost acting as a beacon-node sidecar. Operators must still handle client compatibility, beacon configuration, keys through their normal validator stack, and chain monitoring. The README's claim of compatibility with any consensus client does not remove the need to configure that client correctly.

The second limitation is relay dependence. The sidecar selects from blocks obtained through relays. A relay outage, an endpoint mistake, an invalid public key, or a network mismatch can affect block availability. The README explains how relays aggregate builder submissions, but it does not document a complete retry, failover, or relay-reputation policy. For that reason, multiple relays should be treated as a configuration choice with explicit monitoring rather than as an automatic guarantee of censorship resistance.

A real alternative is to omit MEV-Boost and let the validator's existing proposer path construct blocks through its configured clients. That approach keeps the block-production path within the validator stack but does not give the operator access to the competitive builder marketplace described by MEV-Boost. Another architectural alternative is a different proposer-builder separation implementation, but the project documentation here does not describe enough about another implementation to make a reliable product comparison.

MEV-Boost's recent release history and repository status suggest that the project is still receiving releases, but the last push was on 2026-06-30. Maintenance cost includes tracking releases, checking Go and container dependencies, and reviewing changes to relay and builder API behavior. The MIT license permits use and modification under its terms, subject to the license text, but operators remain responsible for their deployment and relay decisions.

Editorial conclusion

MEV-Boost is appropriate for PoS Ethereum operators, including solo validators, that want access to a competitive builder marketplace and can operate a sidecar connected to their beacon client. It is not a replacement for a consensus or execution client, and it is a poor fit for operators who cannot manage relay selection, signing-related trust assumptions, and service monitoring. Verify the beacon client connection, relay URLs and public keys, network settings, and the exact release behavior before moving a validator to MEV-Boost.

Frequently asked questions

Official sources

1. flashbots/mev-boost on GitHub
2. License: MIT
3. Project website
4. README
5. Releases