MEV Configuration¶
When it comes to MEV, Vero behaves like a traditional validator client – it does not communicate directly with MEV relays. Instead, connected beacon nodes should handle that role through sidecars like mev-boost or Commit-Boost.
flowchart RL
Lighthouse <--> Vero
mev-boost <--> Lighthouse
RA(Relay A) <--> mev-boost
RB(Relay C) <--> mev-boost
RC(Relay B) <--> mev-boost
style Vero fill:#11497E,stroke:#000000If you want Vero to use external builders when proposing
blocks, all you need to do is pass the
--use-external-builder CLI flag. With this flag,
Vero will regularly register its connected validators
with MEV relays.
MEV and multiple beacon nodes¶
For validator registrations, Vero uses a single beacon node to avoid overwhelming MEV relays with duplicate registrations. It selects the currently highest-scoring connected node.
When node scores are equal, this defaults to the first URL in
--beacon-node-urls.
If that beacon node's score drops (e.g. due to downtime or slow responses),
Vero automatically fails over to the next highest-scoring beacon node.
Therefore, ensure all connected beacon nodes are configured to reach all MEV relays you intend to use.
There are multiple choices you can make when it comes to setting this up in a multi-client environment.
Option 1: Point all beacon nodes to a single mev-boost instance:¶
flowchart RL
%% VC<->CL
Lighthouse <--> Vero
Lodestar <--> Vero
Teku <--> Vero
%% CL<->EL
mev-boost <--> Lighthouse
mev-boost <--> Lodestar
mev-boost <--> Teku
style Vero fill:#11497E,stroke:#000000Option 2: Deploy a separate mev-boost instance for each client pair:¶
flowchart RL
%% VC<->CL
Lighthouse <--> Vero
Lodestar <--> Vero
Teku <--> Vero
%% CL<->EL
MB1(mev-boost 1) <--> Lighthouse
MB2(mev-boost 2) <--> Lodestar
MB3(mev-boost 3) <--> Teku
style Vero fill:#11497E,stroke:#000000