Run an Ethereum validator without MEV-Boost and you leave money on the table. Every block your validator proposes without it goes through local building only, which means you miss the competitive builder auctions that route extra value to solo stakers. Staking analytics from 2026 put the gap at roughly 0.4 to 1.0 percentage points of additional annualized yield, and some estimates describe MEV-Boost as adding 10% to 30% on top of base validator rewards. On 32 ETH, that is not pocket change.
This tutorial walks through installing MEV-Boost, picking relays, wiring it into your consensus client, and running the whole stack in production with monitoring and fallback protection. By the end you will have a working Docker Compose deployment, a relay configuration that balances yield against censorship exposure, and a troubleshooting checklist for when bids stop flowing. Expect about 90 minutes for a first-time setup on a machine that already runs a synced execution and consensus client.
None of this requires touching your validator keys, moving your 32 ETH, or trusting a third party with custody. MEV-Boost is a local process you control, and every relay in your list is swappable at any time by editing a single flag. If you get partway through and decide a relay is behaving badly, you drop it from the list and restart the service. That reversibility is part of why solo stakers adopted MEV-Boost so widely once builder auctions became competitive.
What Is MEV-Boost and Why It Matters for Validators in 2026
MEV-Boost is open source middleware built by Flashbots that sits between your consensus client and a network of block builders. Instead of your node assembling a block from its own local mempool, MEV-Boost asks a set of relays to forward bids from competing builders, picks the highest-value one, and hands it to your validator to sign. The validator never sees the transactions inside the block until after it commits, which is what keeps the process resistant to front-running by the proposer itself.
The software has been part of mainnet Ethereum staking since the Merge in 2022, and by 2026 the vast majority of validators run it rather than build locally. Relay monitoring services like Rated Network and MEV Watch track which relays are producing blocks and how they treat sanctioned addresses, a distinction that matters more now than it did in the early days of proposer-builder separation. A September 2026 Rated Network snapshot found neutral, non-filtering relays building roughly 70% of MEV-Boost blocks, with the remainder going through relays that apply OFAC-style transaction screening. That split is the reason relay choice is no longer just about yield.
If you already run a validator and skipped MEV-Boost at launch, nothing about adding it later is destructive. You are changing how blocks get built, not how your keys are stored or how your deposit is staked. That makes this one of the lower-risk upgrades you can make to an existing setup.
Why Proposer-Builder Separation Exists
Before MEV-Boost, a validator’s own client software built every block it proposed. That sounds harmless until you consider what block building actually involves: deciding transaction order inside a block, which is exactly the lever that sandwich bots, arbitrage searchers, and liquidation bots fight over. A validator running unsophisticated local building software captured only a fraction of the value available in a given slot, because it lacked the specialized infrastructure that professional builders run to simulate thousands of transaction orderings in milliseconds.
Flashbots’ original pitch, dating back to the pre-Merge Ethereum mempool wars of 2020 and 2021, was to pull that competition out of the public mempool and into a private auction. Proposer-builder separation formalizes the split: builders compete to construct the most valuable block, relays act as trusted intermediaries that verify a builder’s block before showing it to the proposer, and the proposer (your validator) only ever sees a header describing the block’s value, never its contents, until it has already committed to that header by signing it. That blind-signing step is what prevents a validator from stealing a builder’s ordering ideas and resubmitting a copycat block.
Ethereum’s own roadmap has discussed folding this relay-based system into the protocol itself, a change generally referred to as enshrined proposer-builder separation, or ePBS. As of September 2026 that remains a research and testnet-stage proposal rather than a live mainnet feature, so relay-based MEV-Boost is still the mechanism every solo validator actually uses today.
Prerequisites: Hardware, Software, and ETH You Need
You need a working solo validator before MEV-Boost does anything useful. That means an execution client, a consensus client, and a validator client already synced to mainnet, plus the 32 ETH deposit that remains the protocol minimum for running your own validator in 2026. If you are staking through a pool instead of solo, this guide does not apply to you since your operator controls relay selection.
- Operating system: Linux (Ubuntu 22.04 or 24.04 LTS is the most common choice for validator hosts), though the same binaries run on macOS for testing.
- CPU: 4 modern physical cores or the cloud equivalent. Sync and client upgrades are the moments that actually stress the CPU.
- RAM: 16 GB as a working baseline, 32 GB if you are also running monitoring and a remote signer on the same box.
- Storage: a 2 TB NVMe SSD is a safer baseline in 2026 than the 1 TB figures floating around from 2022, given execution-client database growth.
- Network: stable, low-latency broadband with meaningful upload capacity. MEV-Boost adds outbound HTTPS calls to every configured relay on every slot where your validator proposes.
- Go: version 1.21 or newer if you plan to build MEV-Boost from source rather than use a prebuilt release.
- A synced consensus client that supports the Builder API: Lighthouse, Prysm, Teku, Nimbus, or Grandine all qualify.
Check your consensus client’s release notes before you start. Lighthouse v8.2.2, Prysm v7.1.8, Teku 26.8.0, and Nimbus v26.8.0 were the versions circulating in staking guides as of late August 2026, but client teams ship updates on a cadence tied to network upgrades, so confirm the current release on the project’s own GitHub page rather than trusting a fixed version number from any single article, including this one.
Two more things to have ready before you open a terminal. First, a firewall rule allowing outbound HTTPS (port 443) traffic from your validator host, since every relay call goes out over standard HTTPS and a locked-down egress policy will silently break bid retrieval. Second, if you are running a fresh validator setup rather than adding MEV-Boost to an existing one, generate the JWT secret shared between your execution and consensus clients first. MEV-Boost does not need its own copy of that secret, but your consensus client does, and a mismatched JWT is a common source of confusing errors that get blamed on MEV-Boost when the actual fault sits one layer down.
How MEV-Boost Fits Into Your Validator Stack
The data flow looks like this: your execution client stays exactly where it was, your consensus client gains one new outbound connection, and MEV-Boost becomes the broker in between.
Execution Client (Geth / Reth / Nethermind / Besu)
|
Consensus Client (Lighthouse / Prysm / Teku / Nimbus / Grandine)
| Builder API, localhost:18550
MEV-Boost
| HTTPS, multiple relays in parallel
Relay 1 (e.g. Ultra Sound Money) Relay 2 (e.g. Aestus) Relay 3 (e.g. Titan)
|
Builders competing to submit the highest-value blockMEV-Boost runs as its own lightweight process, usually on the same machine as your consensus client, and exposes a local Builder API endpoint on port 18550 by default. Your consensus client is configured to treat that local endpoint as its builder source. When your validator is due to propose a block, the consensus client asks MEV-Boost for the best available bid, MEV-Boost fans that request out to every relay you configured, and it returns the highest-value signed header back to the consensus client within a tight deadline. If no relay responds in time or every bid falls below a threshold you set, the client falls back to building the block locally so a slow relay never costs you a missed proposal.
Timing matters more here than in most parts of validator operation. Ethereum slots last 12 seconds, and MEV-Boost’s request for a header typically has to complete somewhere around one second before the slot boundary to leave enough time for the consensus client to sign and broadcast. That is why the request-timeout settings covered later in this guide are not cosmetic. A relay that takes too long to respond is worse than a relay that fails fast, because a slow response can eat into the window your validator has to fall back to local building before it simply misses the slot.
What You’re Trusting When You Run MEV-Boost
Adding MEV-Boost changes your trust model, and it is worth being clear-eyed about that trade before you flip it on. Your validator no longer sees the contents of the block it signs until after commitment, which means you are trusting the relay to have honestly verified that the builder’s block is valid and that it actually pays your fee recipient the amount promised in the bid. Relays exist specifically to make this trust reasonable: a relay simulates the builder’s block before forwarding the header, confirming the payment is real and the block doesn’t break consensus rules, and reputable relays have strong incentives not to lie since getting caught ends their business.
That said, “reasonable trust” is not “zero trust.” A relay could theoretically go offline mid-slot, which is why the fallback-to-local-building path matters so much. A relay could also apply content policy you disagree with, which is the entire reason the neutral-versus-OFAC-screening distinction gets its own table further down this guide. Running multiple relays from different operators is less about squeezing out marginal extra yield and more about not putting your validator’s block-building process in the hands of a single organization’s uptime and policy decisions.
None of this changes your custody of your staked ETH or your withdrawal credentials. The trust MEV-Boost introduces is scoped narrowly to block construction for the slots your validator proposes, nothing more.
Step 1-3: Install MEV-Boost and Pick Your Relays
Step 1: Download or build MEV-Boost
The fastest path is a prebuilt binary from the official Flashbots MEV-Boost GitHub repository. Pull the latest tagged release rather than the default branch, since main can contain unreleased changes.
wget https://github.com/flashbots/mev-boost/releases/download/v1.12/mev-boost_1.12_linux_amd64.tar.gz
tar -xzf mev-boost_1.12_linux_amd64.tar.gz
sudo mv mev-boost /usr/local/bin/
mev-boost --versionCheck the actual release list on GitHub before running this, since v1.12 was the tag circulating in February 2026 guides and a newer patch release may exist by the time you read this. If you prefer building from source, clone the repository and run go build from inside it, which also lets you verify the code you are compiling.
Step 2: Decide how many relays to run and why
Running a single relay is the single biggest mistake new operators make, covered in more detail below. For now, plan on at least three relays from different operators. MEV-Boost queries all configured relays in parallel and takes the best bid, so adding relays costs you nothing in latency and only increases the odds that at least one relay is healthy and competitive on any given slot.
Step 3: Choose relays based on yield and censorship posture
Relay policy differs in a way that actually shows up in your validator’s behavior. Some relays screen out transactions touching addresses on U.S. sanctions lists, and others explicitly do not. This is not a hypothetical distinction, it is published relay policy that monitoring sites track daily. There is no single correct answer for which posture to run. Some operators care primarily about maximizing yield and are indifferent to relay filtering policy, while others treat neutral, non-filtering relays as a matter of principle regardless of any yield difference. Decide where you land before you build your relay list rather than defaulting to whatever the first tutorial you read happened to recommend.
| Relay | Approx. share (Sept 2026) | Filtering posture | Endpoint pattern |
|---|---|---|---|
| Ultra Sound Money | 35.1% | Neutral, non-filtering | relay.ultrasound.money |
| Titan Relay | 30.1% | Neutral, non-filtering | titanrelay.xyz |
| bloXroute Regulated | 20.1% | OFAC-screening | bloxroute.regulated.blxrbdn.com |
| Aestus | 8.6% | Neutral | aestus.live |
| Flashbots | 2.6% | OFAC-screening | boost-relay.flashbots.net |
| bloXroute Max Profit | 1.5% | Non-filtering | bloxroute.max-profit.blxrbdn.com |
| Agnostic Gnosis | 1.1% | Neutral | agnostic-relay.net |
Those shares come from a Rated Network 30-day snapshot dated September 22, 2026, and a same-week MEV Watch snapshot showed similar proportions with Ultra Sound and Titan leading. Relay share moves week to week as builder competition shifts, so treat this table as a starting point for research rather than a fixed ranking, and check MEV Watch or Relayscan for current numbers before you finalize your list.
Step 4-6: Configure Relays, Start MEV-Boost, and Connect Your Consensus Client
Step 4: Launch MEV-Boost with your relay list
Pass relay URLs as a comma-separated list to the -relays flag, or repeat the -relay flag once per relay. Both forms work, and the comma-separated version is easier to read in a systemd unit file.
mev-boost \
-mainnet \
-addr 0.0.0.0:18550 \
-relays https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net,https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf67a04c8ae3cf0e1a2c4b6a7e6b9d7e7c9e7c9e7c9e7@relay.ultrasound.money \
-min-bid 0.03Each relay URL includes the relay’s public key as the username portion, which lets MEV-Boost verify the relay’s signature on every bid. Copy the exact URL from the relay operator’s own documentation rather than typing it by hand, since a single wrong character in that key breaks signature verification silently.
Step 5: Point your consensus client at MEV-Boost
Every major consensus client needs two things: a flag telling it that builder blocks are enabled, and a URL pointing at MEV-Boost’s local address. The exact flag names differ by client.
| Consensus client | Builder-enable flag | Builder endpoint flag |
|---|---|---|
| Lighthouse (v8.2.2) | –builder-proposals | –builder=http://localhost:18550 |
| Prysm (v7.1.8) | –enable-builder | –http-mev-relay=http://localhost:18550 |
| Teku (26.8.0) | –validators-builder-registration-default-enabled | –builder-endpoint=http://localhost:18550 |
| Nimbus (v26.8.0) | –payload-builder | –payload-builder-url=http://localhost:18550 |
Restart your consensus client and validator client after adding these flags. Check the client’s log output for a line confirming a successful connection to the builder endpoint before you assume it is working.
Step 6: Confirm validator registration with relays
Your validator has to register its fee recipient and public key with each relay before that relay will build blocks for it. Most clients handle this automatically once builder flags are set, sending a signed registration message on a recurring interval so relays always have a current record even if you change your fee recipient later. Grep your validator client’s logs for “registration” or “builder” to confirm registrations are going out rather than silently failing. This step is separate from bid retrieval, which is why a misconfigured registration can leave MEV-Boost technically running while every relay quietly ignores your validator’s proposals.
Step 7-9: Set a Minimum Bid, Run as a systemd Service, Verify Connectivity
Step 7: Set a sane minimum bid floor
The -min-bid flag rejects any relay bid below the ETH value you specify, falling back to local block building instead. CoinCashew’s community staking guide recommends starting around 0.03 to 0.05 ETH as a floor, low enough that you rarely fall back but high enough that a misbehaving relay returning a near-zero bid does not get selected. Tune this over time by watching how often your node actually falls back.
Step 8: Run MEV-Boost as a systemd service
Running MEV-Boost in a foreground terminal is fine for testing and useless in production. Create a unit file so it restarts automatically and starts on boot.
[Unit]
Description=MEV-Boost
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=mevboost
ExecStart=/usr/local/bin/mev-boost \
-mainnet \
-addr 127.0.0.1:18550 \
-relays https://RELAY1,https://RELAY2,https://RELAY3 \
-min-bid 0.03 \
-request-timeout-getheader 950
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.targetBind to 127.0.0.1 rather than 0.0.0.0 once you move past testing. MEV-Boost’s Builder API endpoint has no authentication of its own, and exposing it publicly lets anyone on the internet query it or attempt to interfere with your block proposals.
sudo useradd --no-create-home --shell /usr/sbin/nologin mevboost
sudo systemctl daemon-reload
sudo systemctl enable mev-boost
sudo systemctl start mev-boost
sudo systemctl status mev-boostStep 9: Verify relay connectivity end to end
MEV-Boost logs every relay call, including timeouts and rejected bids. Watch the logs during a slot near your validator’s next proposal window.
journalctl -u mev-boost -f | grep -E "getHeader|getPayload|error"A healthy log shows successful getHeader calls returning bids from multiple relays, followed by a getPayload call after your validator signs the winning header. If you see nothing but timeouts, the fix is almost always a relay URL typo, a firewall blocking outbound HTTPS, or a relay that has quietly gone offline.
Step 10-12: Monitor Rewards, Configure Fallback, and Test Before Mainnet
Step 10: Monitor bids and rewards over time
MEV-Boost exposes a Prometheus metrics endpoint you can scrape alongside your existing Grafana stack. Add a scrape target and track bid values, relay latency, and fallback frequency over weeks, not single slots, since MEV value is bursty and any one proposal tells you little.
# prometheus.yml
scrape_configs:
- job_name: 'mev-boost'
static_configs:
- targets: ['localhost:18550']
metrics_path: /metricsStep 11: Confirm your fallback to local building actually works
Temporarily point MEV-Boost at an unreachable relay address and confirm your consensus client still proposes a locally built block rather than missing the slot entirely. This is the single most important failure mode to test, since a validator that cannot fall back gracefully can miss proposals whenever every configured relay is briefly unavailable.
Step 12: Rehearse the whole stack on a testnet first
Run the identical configuration against Hoodi or another current Ethereum testnet before you touch a mainnet validator with real ETH at stake. Testnet relays exist specifically for this, and Kurtosis’s local Ethereum package can spin up a full execution, consensus, and MEV-Boost stack on a laptop for practice runs.
Complete Working Project: Docker Compose MEV-Boost Stack
If you would rather containerize the whole thing instead of managing systemd units by hand, here is a working Compose file covering MEV-Boost alongside Lighthouse’s beacon node. Adjust the execution client endpoint and fee recipient address for your own setup. This assumes your execution client, whether that’s Geth, Reth, Nethermind, or Besu, is already running as a separate container or service reachable at the hostname referenced in the execution-endpoint flag, since this Compose file intentionally covers only the MEV-Boost and consensus-client layer rather than the full validator stack end to end.
version: "3.8"
services:
mev-boost:
image: flashbots/mev-boost:1.12
container_name: mev-boost
restart: unless-stopped
command:
- -mainnet
- -addr
- 0.0.0.0:18550
- -relays
- https://RELAY1,https://RELAY2,https://RELAY3
- -min-bid
- "0.03"
ports:
- "127.0.0.1:18550:18550"
networks:
- validator-net
lighthouse-beacon:
image: sigp/lighthouse:v8.2.2
container_name: lighthouse-beacon
restart: unless-stopped
depends_on:
- mev-boost
command:
- lighthouse
- bn
- --network=mainnet
- --execution-endpoint=http://execution:8551
- --execution-jwt=/jwt/jwt.hex
- --builder=http://mev-boost:18550
- --builder-proposals
- --http
volumes:
- beacon-data:/root/.lighthouse
- ./jwt:/jwt:ro
networks:
- validator-net
volumes:
beacon-data:
networks:
validator-net:
driver: bridgeTwo details in that Compose file are easy to overlook. The ./jwt:/jwt:ro volume mount has to point at the same JWT secret file your execution client is configured to use, mounted read-only, or the beacon node will fail to authenticate against it on startup. And the fee recipient address, which does not appear directly in the MEV-Boost service block, still needs to be set on your validator client so that builder payments land in a wallet you actually control rather than a placeholder address left over from a config template.
Bring the stack up, then confirm both containers see each other on the internal Docker network before you check external relay connectivity.
docker compose up -d
docker compose logs -f mev-boostHow Much Extra Yield Does MEV-Boost Really Add
Do not expect a fixed number here, because there isn’t one. Staking analytics from 2026 put the added yield anywhere from roughly 0.4 to 1.0 percentage points of annualized return on top of base validator rewards, with wide swings driven by proposer luck, how many slots you get assigned, and whether a builder happens to be sitting on an unusually valuable block during your specific proposal window. A separate estimate frames the same effect as MEV-Boost adding 10% to 30% on top of base rewards rather than as a flat APR bump, which is really the same variability described a different way.
The practical takeaway for a solo staker running one or two validators: do not judge whether MEV-Boost is working based on a single week of rewards. Track it over at least a full month, ideally longer, and compare your realized yield against your pre-MEV-Boost baseline rather than against someone else’s number from a different relay set and a different proposal schedule.
A rough worked example helps make the math concrete, with the caveat that every number here is an illustration, not a guarantee. A single validator staking 32 ETH at a base annualized yield of roughly 2.78% earns close to 0.89 ETH a year before any builder rewards. Layer in an additional 0.5 percentage point from MEV-Boost, near the middle of the 0.4 to 1.0 point range cited above, and annual yield rises to about 3.28%, or roughly 1.05 ETH. The table below breaks that out at three points along the reported range.
| Scenario | Effective APR | Approx. annual ETH on a 32 ETH validator |
|---|---|---|
| Base rewards only, no MEV-Boost | 2.78% | ~0.89 ETH |
| Base rewards + low end of MEV-Boost range (+0.4 pt) | 3.18% | ~1.02 ETH |
| Base rewards + high end of MEV-Boost range (+1.0 pt) | 3.78% | ~1.21 ETH |
Treat this as a rough planning tool, not a promise. Actual results depend heavily on how many slots your validator gets assigned in a given period, which relays you run, and whether a high-value block happens to land during one of your proposal windows.
5 Common MEV-Boost Pitfalls (and How to Avoid Them)
Most MEV-Boost problems trace back to one of a small number of configuration mistakes, and almost none of them show up as a loud error message. The software fails quietly by default, which is exactly why the verification steps earlier in this guide matter as much as the installation steps themselves.
- Running a single relay. One relay is one point of failure. If it goes down, has a bad day, or simply loses a builder auction to someone else’s relay, you either fall back to local building or miss out on better bids entirely. Run at least three relays from different operators, and periodically check that all of them are still actually responding rather than assuming a working config stays working forever.
- Exposing the Builder API publicly. Binding MEV-Boost to 0.0.0.0 instead of 127.0.0.1 leaves an unauthenticated API reachable from the open internet. Bind to localhost and let your consensus client reach it over the loopback interface only.
- Skipping fee recipient configuration. If your validator client isn’t configured with the correct fee recipient address, builder payments can end up going somewhere you didn’t intend. Double-check this value matches the wallet you actually control.
- Mixing relay URLs with wrong public keys. A single mistyped character in a relay’s public key breaks signature verification for that relay silently, and MEV-Boost simply stops using it without a loud error. Copy relay URLs directly from the operator’s own page.
- Never testing the fallback path. Operators who never simulate a relay outage find out the hard way, mid-mainnet, whether their consensus client actually falls back to local block building cleanly. Test it on a testnet before you need it on mainnet.
Troubleshooting: 8 Common MEV-Boost Issues
Work through these in order the first time something looks wrong. Connectivity issues are far more common than configuration bugs, and it is worth ruling out the network before you start editing flags.
| Symptom | Likely cause | Fix |
|---|---|---|
| MEV-Boost logs show constant timeouts | Firewall blocking outbound HTTPS, or a relay endpoint that’s down | Test each relay URL with curl directly, then drop any relay that fails consistently |
| Consensus client won’t recognize builder flag | Wrong flag name for your client version | Check the client’s own –help output, since flag names change between major versions |
| Validator always falls back to local blocks | –min-bid set too high for current relay bid levels | Lower the min-bid value temporarily and watch whether bids start clearing it |
| No registration confirmations in validator logs | Validator client not configured with builder registration enabled | Add the client-specific registration flag and restart the validator client |
| One relay never returns a bid | Incorrect public key in the relay URL | Re-copy the full relay URL, including the public key, from the relay’s documentation |
| systemd service won’t start | Binary not executable, or wrong path in ExecStart | Run chmod +x on the binary and confirm the path with which mev-boost |
| Rewards look lower than expected | Small sample size, or a run of unlucky proposal slots | Measure over a full month before drawing conclusions |
| Docker container can’t reach the beacon node | Containers on separate Docker networks | Confirm both services share the same defined network in your Compose file |
Advanced Tips: Redundancy, Security, and Remote Signers
Once the basic stack is stable, a few refinements are worth the extra setup time. Split your relay list across neutral and OFAC-screening relays deliberately rather than by accident, since that choice has real implications for the transactions your validator ends up including and is worth a conscious decision rather than a default. If censorship resistance matters to you, weight your relay list toward Ultra Sound Money, Titan, Aestus, and Agnostic Gnosis, all of which described themselves as non-filtering in September 2026 monitoring snapshots.
Consider a remote signer such as Web3Signer if you’re running multiple validators across more than one machine, which keeps your signing keys off the beacon node host entirely. That separation matters operationally too: if the machine running MEV-Boost and your beacon node ever needs a rebuild, a remote signer means your keys were never exposed to that host in the first place. Pair that with a circuit breaker script that watches your consensus client’s missed-proposal rate and pages you if it climbs, rather than discovering a problem days later in a rewards dashboard.
Finally, keep every layer of the stack (execution client, consensus client, validator client, and MEV-Boost itself) on versions compatible with the current network fork. A validator running one outdated component is a common cause of subtle proposal failures that have nothing to do with MEV-Boost directly but get blamed on it anyway.
Watch the ePBS research track loosely as it develops. If enshrined proposer-builder separation eventually lands on mainnet, relay operators and the trust model around them will likely change, though nothing about that timeline was confirmed as of September 2026. Until then, relay-based MEV-Boost is the production-tested path, and the operational habits in this guide (multiple relays, tested fallback, restricted local API access) carry over regardless of how the protocol-level picture evolves.
Put the whole sequence together and the setup is straightforward even if the individual pieces sound technical: install one binary, pick three or more relays with a deliberate view on their filtering posture, point your existing consensus client at MEV-Boost over localhost, wrap it in a systemd unit or a container so it survives reboots, and then actually test the failure paths before you trust it with a live proposal. The parts operators skip, testing fallback and verifying registrations, are exactly the parts that matter most when a relay has a bad night. Treat the yield figures in this guide as a range to expect, not a number to chase, and revisit your relay list every few months since market share among relays shifts as builder competition changes.
Frequently Asked Questions
Does MEV-Boost require extra ETH beyond my 32 ETH validator deposit?
No. MEV-Boost is middleware that changes how your existing validator builds blocks. It does not require an additional deposit or change your staking balance.
Is MEV-Boost mandatory for solo validators in 2026?
No, it remains optional. You can run a fully compliant validator without it, you will simply build every block locally and miss out on competitive builder bids. Some operators skip it deliberately for philosophical reasons around minimizing third-party dependencies, and that remains a valid choice, just a lower-yield one.
How many relays should I actually run?
Three to five from different operators is a reasonable range for a solo staker. More relays rarely hurt since MEV-Boost queries them in parallel, but each additional relay is one more URL and public key to keep correctly configured.
Will using only neutral, non-filtering relays cost me yield?
Based on 2026 relay share data, neutral relays like Ultra Sound Money and Titan together handled the large majority of blocks, so avoiding OFAC-screening relays entirely does not obviously starve you of competitive bids, though relay market share shifts over time.
What happens if every relay I configured is unreachable during my proposal slot?
A correctly configured consensus client falls back to building the block locally rather than missing the slot. That is exactly why testing the fallback path on a testnet, as covered in Step 11, matters before you rely on this in production.
Can I run MEV-Boost on a different machine than my consensus client?
You can, but it adds network latency to a process that already runs on a tight per-slot deadline. Running MEV-Boost on the same host as your consensus client, communicating over localhost, is the standard and lowest-risk setup, and it also avoids opening the unauthenticated Builder API port across a network link.
Does MEV-Boost work with liquid staking or pooled validators?
Large staking pools and liquid staking protocols typically run their own MEV-Boost configuration across their validator set, and individual depositors have no direct control over relay selection. This tutorial applies to operators running their own solo validator keys, where the 32 ETH deposit and the node itself are both under your control.
How do I know if my relay public keys are correct?
Copy the full relay URL, including the embedded public key, directly from the relay operator’s documentation page rather than retyping it. MEV-Boost verifies every bid’s signature against that key, and a mismatch silently disables that relay instead of throwing an obvious error.
