LogoLogo
SDKAPI
Version-v1.4.0 (current)
Version-v1.4.0 (current)
  • Learn
    • Introduction
      • Obol Collective
      • OBOL Incentives
      • Key Staking Concepts
      • Obol vs Other DV Implementations
      • Obol Splits
      • DV Launchpad
      • Frequently Asked Questions
    • Charon
      • Introduction to Charon
      • Distributed Key Generation
      • Cluster Configuration
      • Charon Networking
      • CLI Reference
    • Futher Reading
      • Ethereum and Its Relationship With DVT
      • Community Testing
      • Peer Score
      • Useful Links
  • Run a DV
    • Quickstart
      • Quickstart Overview
      • Create a DV Alone
      • Create a DV With a Group
      • Push Metrics to Obol Monitoring
    • Prepare to Run a DV
      • How and Where To Run DVs
      • Deployment Best Practices
      • Test a Cluster
    • Running a DV
      • Activate a DV
      • Update a DV
      • Monitoring Your Node
      • Claim Rewards
      • Exit a DV
    • Partner Integrations
      • Create an EigenLayer DV
      • Create a Lido CSM DV
      • DappNode
  • Advanced & Troubleshooting
    • Advanced Guides
      • Create a DV Using the SDK
      • Migrate an Existing Validator
      • Enable MEV
      • Combine DV Private Key Shares
      • Self-Host a Relay
      • Advanced Docker Configs
      • Beacon node authentication
    • Troubleshooting
      • Errors & Resolutions
      • Handling DKG Failure
      • Client Configuration
      • Test Commands
    • Security
      • Overview
      • Centralization Risks and Mitigation
      • Obol Bug Bounty Program
      • Smart Contract Audit
      • Software Development at Obol
      • Charon Threat Model
      • Contacts
  • Community & Governance
    • Governance
      • Collective Overview
      • The Token House
      • The RAF
      • Delegate Guide
      • RAF1 Guide
    • The OBOL Token
      • Token Utility
      • Token Distribution & Liquidity
      • TGE FAQ
    • Community
      • Staking Mastery Program
      • Techne
    • Contribution & Feedback
      • Filing a Bug Report
      • Documentation Standards
      • Feedback
  • Walkthrough Guides
    • Walkthroughs
      • Walkthrough Guides
  • SDK
    • Intro
    • Enumerations
      • FORK_MAPPING
    • Classes
      • Client
    • Interfaces
      • ClusterDefinition
      • RewardsSplitPayload
    • Type-Aliases
      • BuilderRegistration
      • BuilderRegistrationMessage
      • ClusterCreator
      • ClusterLock
      • ClusterOperator
      • ClusterPayload
      • ClusterValidator
      • DepositData
      • DistributedValidator
      • ETH_ADDRESS
      • OperatorPayload
      • SplitRecipient
      • TotalSplitPayload
    • Functions
      • validateClusterLock
  • API
    • What is this API?
    • System
    • Metrics
    • Cluster Definition
    • Cluster Lock
    • State
    • DV Exit
    • Cluster Effectiveness
    • Terms And Conditions
    • Techne Credentials
    • Address
    • OWR Information
  • Specification
Powered by GitBook
On this page
  • Getting started with Charon & the Builder API​
  • Client configuration​
  • Verify your cluster is correctly configured​
Edit on GitHub
  1. Advanced & Troubleshooting
  2. Advanced Guides

Enable MEV

PreviousMigrate an Existing ValidatorNextCombine DV Private Key Shares

Last updated 5 days ago

This quickstart guide focuses on configuring the builder API for Charon and supported validator and consensus clients.

Getting started with Charon & the Builder API

Running a distributed validator cluster with the builder API enabled will give the validators in the cluster access to the builder network. This builder network is a network of "Block Builders" who work with MEV searchers to produce the most valuable blocks a validator can propose.

is one such product from Flashbots that enables you to ask multiple block relays (who communicate with the "Block Builders") for blocks to propose. The block that pays the largest reward to the validator will be signed and returned to the relay for broadcasting to the wider network. The end result for the validator is generally an increased APR as they receive some share of the MEV.

Before completing this guide, please check your cluster version, which can be found inside the cluster-lock.json file. If you are using cluster-lock version 1.7.0 or higher, Charon seamlessly accommodates all validator client implementations within a MEV-enabled distributed validator cluster.

For clusters with a cluster-lock.json version 1.6.0 and below, Charon is compatible only with . Use the version history feature of this documentation to see the instructions for configuring a cluster in that manner (v0.16.0).

Client configuration

You need to add CLI flags to your consensus client, Charon client, and validator client, to enable the builder API.

You need all operators in the cluster to have their nodes properly configured to use the builder API, or you risk missing a proposal.

Charon

Charon supports builder API with the --builder-api flag. To use builder API, one simply needs to add this flag to the charon run command:

charon run --builder-api

Consensus Clients

The following flags need to be configured on your chosen consensus client. A Flashbots relay URL is provided for example purposes, you should use the and select the two or three relays with the lowest latency to your node that also conform to your block building preferences. A public list of MEV relays is available .

Teku can communicate with a single relay directly:

teku --builder-endpoint="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"

Or you can configure it to communicate with a local sidecar to configure multiple relays:

teku --builder-endpoint=http://mev-boost:18550

Lighthouse can communicate with a single relay directly:

lighthouse bn --builder="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"

Or you can configure it to communicate with a local sidecar to configure multiple relays:

lighthouse bn --builder="http://mev-boost:18550"

Prysm can communicate with a single relay directly:

prysm beacon-chain --http-mev-relay="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"

Nimbus can communicate with a single relay directly:

nimbus_beacon_node \
      --payload-builder=true \
      --payload-builder-url="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"

You should also consider adding --local-block-value-boost=3 as a flag, to favour locally built blocks if they are withing 3% in value of the relay block, to improve the chances of a successful proposal.

Lodestar can communicate with a single relay directly:

node ./lodestar --builder --builder.urls="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net"

The following flags need to be configured on your chosen validator client

teku validator-client --validators-builder-registration-default-enabled=true
lighthouse vc --builder-proposals
prysm validator --enable-builder
nimbus_validator_client --payload-builder=true
node ./lodestar validator --builder="true" --builder.selection="builderonly"

It can be difficult to confirm everything is configured correctly with your cluster until a proposal opportunity arrives, but here are some things you can check.

When your cluster is running, you should see if Charon is logging something like this each epoch:

13:10:47.094 INFO bcast      Successfully submitted validator registration to beacon node {"delay": "24913h10m12.094667699s", "pubkey": "84b_713", "duty": "1/builder_registration"}

This indicates that your Charon node is successfully registering with the relay for a blinded block when the time comes.

You should check that your validator client's logs look healthy, and ensure that you haven't added a fee-recipient address that conflicts with what has been selected by your cluster in your cluster-lock.json file, as that may prevent your validator from producing a signature for the block when the opportunity arises. You should also confirm the same for all of the other peers in your cluster.

Validator Clients

Verify your cluster is correctly configured

If you are using the , you can enter your cluster's distributed validator public key(s) into their website, to confirm they also see the validator as correctly registered. If you are using , you can check their API by running curl https://titanrelay.xyz/relay/v1/data/validator_registration?pubkey=0x123..456 with the public key of a validator in your cluster.

Once a proposal has been made, you should look at the Block Extra Data field under Execution Payload for the block on , and confirm there is text present, this generally suggests the block came from a builder, and was not a locally constructed block.

​
MEV-Boost
Teku
​
​
​
charon test mev command
here
MEV-boost
MEV-boost
​
​
Ultrasound Relay
Titan Relay
Beaconcha.in