​
Why Participate?

Participation of L1 validators in the mev-commit protocol increases the credibility of preconfs made through mev-commit and consequently their value. Due to increased preconf values, providers have additional value to bid in the mev-boost auction, thus driving up the total revenue a proposer will get.

​
Supported Networks

Both Holesky and Mainnet L1 validators are able to opt-in to mev-commit. The opt-in process is initiated from the chain the validator is staked on. See mainnet and testnet for relevant contract addresses.

​
Requirements

  1. An operational L1 validator node for either mainnet or Holesky.
  2. An operational mev-boost sidecar.
  3. Capital requirements as described further below.
As a validator opting into the mev-commit protocol, ensure your mev-boost client only connects to mev-commit opted-in relays to avoid slashing for proposing blocks without delivering commitments.
By opting-in to the mev-commit protocol as a validator in one of the three forms described, you agree to only use opted-in relays. These opted-in relays will only forward mev-boost bids from addresses that have registered with the mev-commit provider registry, such that any provider can be slashed in case of a protocol violation. This allows validators to passively opt-in to mev-commit, letting block builders and relays do the work.

​
Supporting Relays

RelayDocs
Titandocs.titanrelay.xyz
Aestusholesky.aestus.live
We expect all known relays to support opting-in to mev-commit within a few months of being live on mainnet. If you are a relay looking to join the mev-commit network please visit our Relays page to get more information. Proposers who fallback to local block production, from either a fault in the mev-boost software or a lack of economically viable block bids, will not be slashed. See flashbots docs for more on this scenario. The protocol may in the future slash for abuse of this local fallback mechanism.

​
Choose Your Opt-In Method

Note each validator pubkey should only opt-in using one of the three methods described below.

Eigenlayer Restaking

Click here for more information on native restaking with mev-commit’s AVS

Symbiotic Restaking

Click here for more information on ERC20 restaking with mev-commit’s middleware contract

Simple Staking

Click here for more information on “vanilla” staking with mev-commit

​
Protocol Design

To learn more about the protocol design for any of the registries, see their respective READMEs: To query the on-chain parameters of any registry (on mainnet or Holesky), run an example forge script like this.