Validator Tools Desktop operations for Ethereum validators
Guide · MEV / MEV-Boost operations & policy

Turn MEV-Boost into a clear, documented policy, not a black box.

For most validators, MEV-Boost is now the default: blocks are sourced from an external market of builders, via relays, because it is profitable. This guide focuses on the operational side: how to choose relays, manage risk and neutrality, and monitor performance using the Validator Tools desktop GUI.

Profit · Liveness · Censorship resistance – treated as first-class trade-offs.

1. What MEV-Boost actually changes for a validator

Without MEV-Boost, a validator’s client builds blocks locally: it selects transactions from the mempool and constructs the block itself. With MEV-Boost, that work is outsourced to third-party builders via a relay layer. The validator effectively auctions its blockspace and picks the highest paying block offered, subject to its policy.

Profit
Higher expected rewards per block from specialised builders competing to pay you the most.
Liveness & risk
Additional moving parts: relays, builder market, extra network hops that can fail or misbehave.
Neutrality
Relay choices affect censorship behaviour and your contribution to the network’s credible neutrality.
Builder
Entity that constructs a full block and bids for the right to have it proposed.
Relay
Service that sits between builders and validators, forwarding bids and revealing blocks on commitment.
Sidecar (mev-boost / commit-boost)
Process that connects your validator client to chosen relays and manages the block auction flow.
Key idea: MEV-Boost is not “free yield”. It is a structured trade-off between higher profit and additional operational and policy decisions. Treat it like any other part of your risk framework.

2. Relay policy: what you actually need to decide

Once MEV-Boost is installed and technically working, the hard questions are about policy, not command-line flags. In practice, validators need to make decisions along three axes:

  • Which relays to connect to (censoring vs non-censoring, reliability, fee profile).
  • How many relays to use and how to handle failures or slow responses.
  • What to do when relays fail – fall back to local blocks, other relays, or accept empty slots.

Without an explicit policy, these decisions end up as a mix of default lists, random forum advice and copy-pasted flags – which is hard to explain to risk committees or clients later.

Step by step
MEV / MEV-Boost setup · From defaults to explicit policy
Using Validator Tools to define and enforce MEV policy

These steps assume you already run a validator with MEV-Boost or a compatible sidecar, or plan to. The goal is to move from “we enabled MEV-Boost” to “we can show exactly how MEV is handled”.

  1. Install the desktop application. Download and install the latest version Validator Tools GUI for your operating system (Windows, macOS or Linux). Run it on a workstation with access to your beacon, validator client and MEV-Boost sidecar.
  2. Register your validator endpoints and sidecar. In the settings, add: beacon/validator client APIs, and the URL of your MEV-Boost (or Commit-Boost) sidecar. Run the built-in connection test to confirm that proposal duties and relay communication are visible.
  3. Define relay sets as named policies. Instead of one long -relays flag string, use the GUI to create named relay sets, for example: “Non-censoring default”, “Dual policy (compliant + neutral)”, “Testnet Holesky relays”. For each set, record the rationale and any constraints (e.g. “must contain at least N non-censoring relays”).
  4. Attach policies to validator groups. Group your validators in the app by entity, client or product and assign a relay policy to each group. This makes it explicit which validators use which relay sets, and avoids accidental drift between nodes.
  5. Configure fallbacks and local-block behaviour. In the MEV policy view, decide for each group: whether to fall back to local block-building if all relays fail, how long to wait for relay bids before building locally, and what to do in case of partial relay outages.
  6. Enable monitoring for MEV share and liveness. Turn on the MEV monitoring dashboard in Validator Tools to track: the fraction of your proposed blocks coming via relays, the average additional reward vs local blocks, and any missed or late proposals linked to relay issues.
  7. Review and log policy decisions. Use the built-in notes or policy log to record: why specific relays were chosen or removed, how censorship and neutrality trade-offs were considered, and which governance body signed off. This log becomes part of your operational documentation.
  8. Test on Holesky or a non-critical environment. Before applying new relay combinations on mainnet, use the same policy on Holesky or a similar test setup to validate that everything behaves as expected.
Even if you already run MEV-Boost, it is worth retrofitting your current setup into this structure, so that future changes become policy updates, not ad-hoc flag edits.

4. Relay strategy and operational controls

Relay choice and operational controls belong together: “which relays” is only half the story; the other half is how you monitor and react when they misbehave or fail.

4.1 Designing a relay strategy

A sensible baseline strategy often looks like:

  • Mix of non-censoring relays to support network neutrality, plus a limited set of compliant relays if your risk/region requires them.
  • Diversity of operators so that a single relay outage does not dominate your MEV flow.
  • Regular review of relay performance and fees, based on public stats and your own data.

In Validator Tools, these choices become a reusable relay-set definition rather than command-line lore that only one engineer remembers.

4.2 Operational controls in the GUI

The app can support this strategy by:

  • exposing which relays are actually delivering blocks to your validators,
  • highlighting relays that frequently time out or underperform,
  • allowing quick policy switches (e.g. “neutral only” mode during an incident) with a clear audit trail.

This keeps the day-to-day operational picture aligned with the agreed policy.

# Example: MEV policy profile (conceptual) policy_name: "Neutral-default" description: "Prioritise non-censoring relays, fall back to local blocks on relay failure." relays: - url: https://relay1.ethertool.org type: non_censoring - url: https://relay2.ethertool.org type: non_censoring - url: https://relay3.ethertool.org type: compliant_optional fallback: local_block_if_no_valid_bid: true max_relay_wait_ms: 200 monitoring: alert_if_missed_proposals_from_relay_issues: true alert_if_mev_share_drops_below: 0.6

Validator Tools doesn’t force this exact schema, but the UI is designed to capture the same ideas: relay lists, fallbacks, monitoring thresholds and the narrative behind them.

5. Talking about MEV policy with stakeholders

For many institutional or protocol-level stakeholders, the relevant questions are simple:

  • “How much additional yield do we get from MEV-Boost, and how variable is it?”
  • “What are we doing about censorship and credible neutrality?”
  • “What happens if relays fail – do we miss blocks?”

The point of putting MEV operations into Validator Tools is that you can answer those questions from one place:

  • reward deltas vs local blocks come from the MEV monitoring view,
  • censorship stance is visible in the relay policy definitions,
  • liveness impact is tracked via missed/late proposals that correlate with relay issues.
All of the above is available from the same desktop GUI you use for exits and consolidations. To see how MEV policies look in practice, you can download Validator Tools, connect it to a test validator with MEV-Boost enabled, and experiment with relay sets and fallback options before applying them to your main fleet.

6. Practical recommendations for MEV / MEV-Boost operations

To keep MEV-Boost from turning into a fragile bolt-on:

  • treat relay selection and fallback logic as policy, not as individual operator preference,
  • make sure every validator group has an explicit, named MEV policy attached in the GUI,
  • monitor MEV revenue and liveness together, not as separate dashboards,
  • review relay choices periodically and after major incidents or regulatory changes.

With that in place, MEV stops being “whatever our flags are set to” and becomes a part of your documented validator strategy.

If you want to move MEV-Boost out of the “black box” category, you can download Validator Tools, connect it to your sidecar and start by defining a single relay policy for one validator group. Everything else can grow from there, and the monitoring & alerting guide shows how to keep relay health and MEV revenue visible alongside the policy.