​
Assumptions

The assumption is that both Vouch and MEV Plus have been installed. If not, please consult the following guides:

​
Base MEV Plus configuration

MEV Plus configuration should look something like this:

[Service]
User=root
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/mev-plus \
  -builderApi.listen-address http://0.0.0.0:18551 \
  -externalValidatorProxy.address http://X.X.X.X:18550 \
  -k2.eth1-private-key XXXX \
  -k2.beacon-node-url http://127.0.0.1:5052 \
  -k2.execution-node-url http://127.0.0.1:8545

The following configuration achieves the following:

  • Sets MEV Plus’ listen address and port to http://0.0.0.0:18551 which the Consensus Builder API will talk to
  • Acknowledges MEV Boost is operating on address and port http://X.X.X.X:18550 ensuring normal operation
  • Will access general beacon node information from http://127.0.0.1:5052 and,
  • Will broadcast smart contract transactions to the exeuction layer on http://127.0.0.1:8545

The private wallet that is passed to MEV plus allows paying for GAS required for Ethereum smart contracts and will be the representative of a group of validators unified under a payout wallet address which by default is the suggested fee recipient configured on the beacon node.

​
Vouch communication with MEV Plus

MEV Plus will communicate with Vouch via the existing Boost configuration parameters without affecting any communication with Boost. Here’s an example Holesky config (please not it may not be complete):

version: "3.7"
services:
  validator:
    image: sigp/lighthouse:v5.1.3-modern
    user: root
    container_name: val
    restart: unless-stopped
    stop_grace_period: 3m
    volumes:
      - ~/data/validators:/validators
    environment:
      - NETWORK=holesky
      - EC_CLIENT=
      - CC_CLIENT=lighthouse
      - CC_API_ENDPOINT=
      - CC_RPC_ENDPOINT=
      - FALLBACK_CC_API_ENDPOINT=
      - FALLBACK_CC_RPC_ENDPOINT=
      - CUSTOM_GRAFFITI=
      - DOPPELGANGER_DETECTION=true
      - VC_ADDITIONAL_FLAGS=
      - NODE_FEE_RECIPIENT=
      - FEE_RECIPIENT_FILE=
      - ENABLE_BITFLY_NODE_METRICS=
      - BITFLY_NODE_METRICS_SECRET=
      - BITFLY_NODE_METRICS_ENDPOINT=
      - BITFLY_NODE_METRICS_MACHINE_NAME=
      - GRAFFITI=
      - ADDON_GWW_ENABLED=
      - MEV_BOOST_URL=http://0.0.0.0:18551
      - ENABLE_MEV_BOOST=true
    entrypoint: sh
    command: "/setup/start-vc.sh"
    cap_drop:
      - all
    cap_add:
      - dac_override
    security_opt:
      - no-new-privileges

Notice the following two important flags:

Without the flags configured exactly like this and pointing to MEV Plus, then both MEV Boost and MEV Plus will not receive registration messages and the following will appear on the MEV Plus logs:

mevPlus[126214]: time="2024-05-02T14:25:37Z" level=warning msg="No registration events received yet from your node for more than 2 epochs since mevPlus started" moduleExecution=k2

However, if Vouch is correctly configured with ENABLE_MEV_BOOST=true and the URL pointing to Plus, then both Plus and Boost will work and MEV Plus logs will look something like this:

time="2024-05-04T09:51:02Z" level=info msg="Processing 51 validator registrations through K2 module [batch 1/1]" currentBatchRegistrations=51 moduleExecution=k2 totalRegistrations=51

The number of validators that undertake native delegation will depend on whether:

  • They are all using the same suggested fee recipient on the node
  • If an inclusion list was defined then only the validators in that list will be natively delegated (it is possible to include validators by fee recipient or specify individual addresses)
  • If an exclusion list was defined then all validators apart from excluded ones will be included

Additionally, Web3Signer can be used to create a global payout address for all validators on a node that are part of the inclusion list (if defined). Please see the following for more information about configuration: https://docs.restaking.cloud/middleware/mevPlusModule