Setting Up MEV-Boost Relay Infrastructure for Validators

MEV-Boost is a middleware protocol that allows Ethereum proof-of-stake validators to outsource block building to a competitive marketplace of specialized builders. By connecting to a relay, a validator can access blocks that include maximal extractable value (MEV) from searchers, significantly increasing their staking rewards. While most validators use public relays like Flashbots, BloXroute, or Titan, running a private relay offers greater control over block data sources, censorship resistance, and potential fee optimization. This guide covers the core components and setup process for a self-hosted relay.

A relay's primary function is to act as a trusted intermediary. It receives block headers from builders, verifies their validity and payment, and forwards them to connected validators. The validator then signs a header commitment. Upon winning a block proposal slot, the validator requests the full block body from the relay. Key technical requirements include an execution client (e.g., Geth, Nethermind), a consensus client (e.g., Lighthouse, Teku), the MEV-Boost software itself, and a builder network connection. The relay must maintain low-latency connections to multiple builders to source competitive blocks.

Configuration begins with installing MEV-Boost from the official GitHub repository. A typical startup command for a relay looks like: mev-boost -relay-check -mainnet -relays http://builder1,http://builder2. The -relay-check flag validates builder endpoints. You must configure your consensus client to connect to the local MEV-Boost instance via its API port (usually 18550). For example, in Lighthouse, you would set --builder http://localhost:18550 and --builder-proposals. It is critical to use a fee recipient address you control in your validator client settings to receive MEV rewards.

Operating a private relay introduces responsibilities. You become the curator of the builder list, which impacts block quality and network health. You should connect to reputable, high-performing builders and monitor for censorship or exclusion of certain transactions. Reliability is paramount; downtime means your validator misses out on MEV opportunities. Implement monitoring for metrics like header reception rate, bid values, and latency. Tools like Prometheus and Grafana can be configured with MEV-Boost's metrics endpoint. Security practices, including firewall rules and running services under non-root users, are essential for a production setup.

For validators seeking redundancy without full self-hosting, a hybrid approach is viable. You can configure your validator to connect to both your private relay and a trusted public relay as a fallback using MEV-Boost's multi-relay support. This ensures continuous access to the builder market if your relay experiences issues. The ongoing evolution of proposer-builder separation (PBS) and potential enshrinement in the protocol means relay infrastructure may change. Staying updated with Ethereum client and MEV-Boost releases is necessary to maintain compatibility and optimal performance for your staking operation.

Running a MEV-Boost relay requires robust hardware to handle high-throughput payload processing and network communication. A dedicated server with at least 4 CPU cores, 8 GB of RAM, and 100 GB of SSD storage is recommended. The relay must maintain low-latency connections to hundreds of validators and builders, making a high-bandwidth internet connection (>100 Mbps) and a static public IP address essential. For production environments, consider using cloud providers like AWS, Google Cloud, or a dedicated bare-metal server to ensure uptime and mitigate DDoS risks.

The core software stack consists of three main components: the execution client (e.g., Geth, Nethermind), the consensus client (e.g., Lighthouse, Teku), and the MEV-Boost relay software itself. You must run a fully synced execution and consensus client pair on the same machine or a trusted private network. The relay software, typically built from source from the flashbots/mev-boost repository, acts as a middleware, forwarding block bids from builders to validators. Ensure all software is updated to the latest stable release compatible with the current Ethereum hard fork.

Network configuration is critical for security and functionality. The relay operates on standard Ethereum P2P ports (e.g., TCP 9000 for consensus layer) and exposes an HTTP API (port 18550 by default) for validator connections. You must configure firewall rules to allow inbound connections from validator clients worldwide. A critical prerequisite is access to a trusted block builder network. While you can connect to public builders, operating a competitive relay often involves establishing direct, private connections with major builder operators to receive the highest-value blocks.

Finally, operational readiness requires monitoring and key management. Set up logging (e.g., using Prometheus/Grafana) to track metrics like bid latency, payload delivery success rate, and builder participation. The relay needs an Ethereum validator key only for signing registrations with the builder network, not for proposing blocks. This key must be secured in a web3signer or similar remote signing service, separate from the relay machine, to minimize the attack surface. Thorough testing on a testnet (like Goerli or Holesky) is mandatory before any mainnet deployment.

Proposer-Builder Separation (PBS) is a design paradigm that splits the role of a block proposer into two distinct entities to mitigate centralization and ethical risks from Maximal Extractable Value (MEV). In this model, specialized block builders compete to construct the most profitable blocks by including transactions and MEV bundles. The validator, acting as the block proposer, then simply selects the most valuable block header from a trusted relay. This separation prevents validators from needing to run complex, potentially exploitative MEV strategies themselves, democratizing access to block rewards.

Relays are critical, neutral intermediaries in the PBS ecosystem. Their primary function is to receive block headers from builders and deliver them to proposers. Crucially, relays perform attestation on the contents of a block—verifying its validity, ensuring it pays the proposer, and checking for harmful transactions—before the proposer signs the header. This protects proposers from signing invalid or malicious blocks. Major relays include the ultrasound.money relay, the Flashbots relay, and Agnostic Gnosis. Validators typically connect to multiple relays to maximize competition and block value.

Builders are sophisticated actors who construct complete block bodies. They source transactions from the public mempool and private order flows (like those from Flashbots Protect or bloXroute), aggregate MEV opportunities (e.g., arbitrage, liquidations), and craft the most financially optimal block. Builders submit only the block header and a commitment to its value to relays in a sealed-bid auction. The builder whose header promises the highest payment to the proposer wins. Popular builder software includes mev-boost-compatible setups and the mev-geth/mev-suite for advanced strategies.

For a validator, the practical workflow is managed by MEV-Boost middleware. After installing mev-boost, you configure it with a list of trusted relay URLs. When your validator is selected to propose a block, mev-boost requests header bids from all connected relays, selects the highest-value valid header, and passes it to your Consensus Layer client for signing. Your validator never sees the full block contents until after the header is signed and published, which is why relay trust is paramount. A basic configuration in a mev-boost systemd service file includes flags like -relays https://0x845bd072b7cd566f02faeb0a4033ce9399e42839ced64e8b2adcfc859ed1e8e1a5a293336a49feac6d9a5edb779be53a@relay.ultrasound.money.

The security model hinges on cryptographic commitments. The builder commits to a block by signing its header. The proposer signs this header, effectively outsourcing block construction while remaining responsible for the chain's consensus rules. The relay's attestation is a non-cryptographic promise; if a relay delivers a bad block, the proposer's only recourse is to slash the builder's bond (if one exists) and blacklist the relay. This makes relay reputation and optional builder bonding key considerations for validator node operators when choosing which infrastructure to trust.

MEV-Boost is a middleware service that allows Ethereum proof-of-stake validators to outsource block construction to a competitive network of builders via relays. This setup is crucial for maximizing validator rewards by capturing Maximal Extractable Value (MEV) from transactions like arbitrage and liquidations. By connecting to a relay, your validator's block proposal duties are forwarded to specialized builders who assemble more profitable blocks, with the relay ensuring the block's validity and delivering it back for signing and submission to the network.

Before you begin, ensure your validator client (e.g., Lighthouse, Prysm, Teku) is fully synced and operational. You will need to install and run the MEV-Boost client software on the same machine or a connected server. The core requirement is configuring your validator client to point its builder API to the local MEV-Boost instance, typically on http://localhost:18550. This redirects all block proposal requests through the MEV-Boost service.

The next critical step is selecting and configuring relays. You should connect to multiple reputable relays for redundancy and better bid diversity. Configuration is done via command-line flags when starting the MEV-Boost client. For example, to connect to the Flashbots, BloXroute, and Ultra Sound relays, your startup command would include: --relay https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3fa3d7262b0c7c3c21c2da6b7c5a5c6c@boost-relay.flashbots.net --relay https://0x8b5d2e73e2a3a55c6c87b8b6eb92e0149a125c852751db1422fa951e42a09b82c142c3ea98d0d9930b056a3bc9896b8f@bloxroute.max-profit.blxrbdn.com --relay https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money.

After starting MEV-Boost with your relay endpoints, you must reconfigure your validator client. The exact flag varies by client. For Lighthouse, add --builder http://localhost:18550 to your beacon node command. For Prysm, use --enable-builder and --builder-validator-coalesce=1. For Teku, set --validators-builder-registration-default-enabled=true and --builder-endpoint=http://localhost:18550. A successful connection is confirmed by logs showing INFO connected to relay in MEV-Boost and your validator client acknowledging the builder endpoint.

Monitor your setup to ensure it's functioning and profitable. Use the MEV-Boost metrics endpoint (default localhost:18550/metrics) or relay-specific dashboards like Flashbots Relay Stats to track performance. Key metrics include the number of received headers and submitted bids. Remember that using MEV-Boost introduces trust assumptions in the relay's honesty; they must not censor transactions or steal MEV. Mitigate this by using multiple relays from different entities and staying informed about relay reputations through community resources.

MEV-Boost is middleware that allows Ethereum proof-of-stake validators to outsource block building to a competitive marketplace of specialized builders. By connecting to a relay, your validator client receives execution payloads from builders who aggregate transactions and extract Maximum Extractable Value (MEV). This setup is critical for validator profitability, as blocks built by professional searchers typically yield higher rewards than locally constructed blocks. The relay acts as a trusted intermediary, ensuring the validity of blocks before they are proposed.

The core of the setup involves configuring your consensus client (e.g., Lighthouse, Prysm, Teku) to use the mev-boost software. After installing mev-boost, you must start it with a list of trusted relay URLs. A typical command includes: mev-boost -relays https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3fa3d726d11d2b@relay.ultrasound.money. Each relay URL contains the relay's public key for authentication. It's a security best practice to use multiple relays from different providers to increase resilience and access to diverse builder markets.

Once mev-boost is running, you must reconfigure your validator client to connect to it. This is done by setting the --builder and --mev-boost-url flags (or their client-specific equivalents) to point to your local mev-boost instance, usually at http://localhost:18550. The validator client will then route all block proposal duties through MEV-Boost. No changes are required for attesting duties. It's crucial to verify the connection in your logs; you should see entries confirming successful registration with the relay and receipt of payloads when a proposal duty occurs.

Validator registration with the builder market requires signing a validator registration message. This message, containing your fee recipient address and a timestamp, is signed with your validator's BLS key and submitted to relays. Most consensus clients handle this automatically upon startup when MEV-Boost is enabled. You can verify your registration on sites like mevboost.org to see which relays have your signed registration. A correct registration is mandatory; without it, relays will not provide you with builder blocks, causing you to propose empty or locally built blocks.

For production environments, consider high-availability setups. This can involve running multiple mev-boost instances behind a load balancer or using a service manager like systemd to ensure automatic restarts. Monitoring is also key: track metrics such as getPayload request counts, relay connectivity status, and the value of received execution payloads. Using a diverse set of relays—such as those operated by Ultrasound Money, BloXroute, and Agnostic—helps decentralize the network and mitigates the risk of a single relay's failure impacting your reward stream.

Finally, understand the trust assumptions. While MEV-Boost increases rewards, you are trusting relays to faithfully deliver the highest-value block and to censor transactions only within the constraints of the relay's policy. The relay also sees your public IP address upon block proposal. The ongoing development of PBS (Proposer-Builder Separation) aims to bake this functionality directly into the protocol, reducing these trust assumptions. Until then, a properly configured MEV-Boost setup is the standard for responsible and profitable Ethereum validation.

Running a private MEV-Boost relay allows a validator or staking pool to act as their own trusted intermediary between block builders and the consensus layer. This setup is critical for validators who prioritize data availability and censorship resistance, as it prevents reliance on third-party relays that may filter transactions. The core components are the relay software itself, a connection to a builder network (like the builder0x69 or ultrasound network), and a secure, low-latency execution client (e.g., Geth, Nethermind) for simulating payloads. Validators communicate with their relay via the standard MEV-Boost middleware running alongside their validator client.

The primary security consideration is ensuring the relay receives and validates block builder payloads correctly. The relay must verify the execution payload header received from a builder against the full block body. This involves checking that the transactions in the body hash to the transactions root in the header and that the block's overall execution is valid. Failure here could lead to proposing an invalid block, resulting in a penalty. Relays typically connect to multiple builders via a builder network to source competitive bids, requiring robust networking and logic to select the most profitable, valid payload.

Data availability is enforced by the relay's requirement for a full, unblinded block body from the builder. When a builder wins an auction, they send the validator's relay a blinded header containing a commitment to the transactions. To unblind it and make the block proposable, the relay must receive the corresponding execution payload body. The relay software, such as the official Flashbots relay, will not sign the header for the validator client unless it has received and locally validated this full payload, ensuring the validator never commits to a block whose contents are unknown.

Configuration involves setting key parameters for security and performance. The MIN_BID variable defines the minimum bid (in wei) to accept from builders, filtering out non-profitable blocks. BLACKLISTED_ADDRESSES can be used to reject blocks containing transactions from sanctioned addresses, a compliance feature. Network timeouts (GETPAYLOAD_TIMEOUT_MS) must be tuned for reliability. Crucially, the relay must be configured with the correct GENESIS_FORK_VERSION and BELLATRIX_FORK_VERSION for the network (Mainnet, Goerli, etc.) to validate fork-specific data.

A sample systemd service configuration for a Go-based relay illustrates a production deployment. This setup assumes the relay binary, a trusted execution client RPC, and a connection to a builder network are available.

bashCopy
[Unit]
Description=MEV-Boost Relay Service
After=network.target

[Service]
Type=simple
User=validator
ExecStart=/usr/local/bin/mev-boost-relay \
  --network mainnet \
  --execution-endpoint http://localhost:8551 \
  --builder-network "https://builder-relay-mainnet.flashbots.net" \
  --min-bid 0.05 \
  --relay-check \
  --addr 0.0.0.0:9062
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

The --relay-check flag enables the critical validation of payload availability before signing.

Operational monitoring is essential. Logs should be tracked for successful payload deliveries, bid amounts, and any validation errors. Metrics like relay_bid_received and relay_getpayload_response_time help gauge performance and profitability. Validators must also keep the relay software updated to adhere to new Ethereum hard forks, like Deneb, which introduced blob transactions and changed payload validation rules. Running a private relay adds operational overhead but provides maximal control over the MEV supply chain, aligning with Ethereum's credibly neutral and permissionless ideals.

MEV-Boost is a middleware service that allows Ethereum proof-of-stake validators to outsource block building to a competitive network of specialized builders via relays. When you run a validator client (like Prysm, Lighthouse, or Teku) with MEV-Boost enabled, your validator no longer constructs its own blocks. Instead, it receives a pre-built, MEV-optimized block from a relay just before its turn to propose. This block includes the validator's fee recipient address, which receives the transaction priority fees and MEV rewards generated by that block. The core components are your validator client, the MEV-Boost software, and one or more relay endpoints.

To begin, you must install and configure the MEV-Boost client on the same machine as your validator. The most common implementation is flashbots/mev-boost. After installation, you start the service with a command specifying which relays to connect to, such as mev-boost -relays https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net. Each relay URL is unique and cryptographically signed. It's critical to use multiple relays from reputable providers (e.g., Flashbots, BloXroute, Ultra Sound) to ensure liveness, maximize competition for your block space, and decentralize trust.

The most important configuration is setting your fee recipient address. This is the Ethereum address (EOA or smart contract) that will receive all standard priority fees (tips) and MEV rewards from blocks you propose via MEV-Boost. You typically configure this in two places for redundancy: first, in your validator client's configuration (e.g., --suggested-fee-recipient=0x... in Lighthouse), and second, when you register your validator with the relay network. The relay will use the fee recipient you provide during registration to populate the feeRecipient field in the block header. Always verify that payments are being sent to the correct address by checking block explorers like Etherscan for your proposed blocks.

Understanding the proposal flow is key. When your validator's turn to propose approaches, MEV-Boost requests a block header from its connected relays. Relays solicit bids from builders, who compete by offering a payment to the validator. MEV-Boost selects the header with the highest bid, signs it, and returns it to the relay. The relay then delivers the full block body to your validator client for propagation to the network. Your validator never sees the transactions inside the block until after it is signed, which preserves proposer-builder separation (PBS) and reduces the risk of frontrunning or censorship by the validator.

For security and reliability, monitor your MEV-Boost service and relay performance. Use logs and metrics to ensure connections are healthy and you are receiving bids. Be aware of censorship resistance; some relays may filter certain transactions. To mitigate this, include at least one censorship-resistant relay (CRR) in your list, which commits to including all compliant transactions. Also, keep your MEV-Boost client updated to patch vulnerabilities. Finally, track your earnings. Rewards from MEV-Boost are not added to your validator balance automatically; they are sent directly to your fee recipient address and must be tracked separately from your consensus layer staking rewards.