MB-Direct: An idea for MEV-Boost improvement

This post outlines some changes to how MEV-Boost works that both allows for improvement in the security and efficiency and the system and would serve as a kind out-of-protocol test for ePBS.

tl;dr: proposer gets a list of optimistic builders ahead of time and queries them directly. This improves efficiency, reduces relay role and moves towards ePBS.


In the current design, all block bids must flow through relays before they can reach validators. This introduces additional latency (thus lower revenue) and places additional trust in relays to pass on correct bid information to validators.

However, due to the uptake of optimistic relaying, the relays often hardly provide any meaningful service that justifies these costs as blocks are not being validated before being passed on to validators. The primary role relays in the optimistic setting are playing is slashing misbehaving builders and protecting validator IP information.

Several block builders have discussed deploying their own relays and some already have. Ideally, we avoid a process in which block building becomes a competition to sit in zoom calls to motivate proprietary relays being adopted. This proposal hopefully does avoid that.

MEV-Boost Direct:

  • removes the ability for relays to skim value from block bids and more broadly reduces the significance of a role whose existence we would to eliminate.
  • removes unnecessary latency, increasing revenue
  • implements direct bidding from builder to validator which more closely resembles ePBS
  • provides a path to further decentralising the relay

This isn’t anything particularly new since the original optimistic relaying idea was intended to involve into something relay-less.

MEV-Boost Direct

  • Just like with optimistic relaying, builders can opt-in to staking their funds in a contract the relay controls. This only needs to happen once, not every slot. A small change here is that builders must also register an endpoint which the validator will later query.
  • Just like before, validators choose which relays they trust

For every slot,

  1. MEV-Boost queries relays with a unauthenticated getEndPoints call. Relays respond to this call with a list of (stake, endpoint) for all the staked builders. Alternatively, MEV-Boost could be configured to check contracts on chain for this information.

  2. The getHeader is made to all trusted relays and all builder endpoints received in step 3. Relays behave as normal, responding with their best known headers. Builders also respond with their best headers, however proposers ignore any bids that exceed the builder’s stake.

  3. As normal, the proposer selects and signs the most valuable header. If the header comes from a builder directly and not via the relay, MEV-Boost sends the signed header to the relay where that builder is staked to protect its IP and for the relay to tell whether the header was signed in time.

  4. In the happy case, the block is delivered to the network and the promised payment is made. In the unhappy case, the block is not delivered, not valid or doesn’t make the promised payment. Just like with optimistic relaying, the relay slashes
    open route to decentralising the relay

The economics are the same as optimistic relaying so there is no change there. Builders who can’t put down enough capital to do a direct bid can go through the relay that simulates and can vouch for correctness and DA.

There is room to decentralise the relay into a committee, however I left that out of this discussion because it boils down to a latency/security tradeoff that applies to the status quo as well.

Finally, this does require builders to implement some relay functionality, but this doesn’t seem to be qualitatively different from managing their current open bundle submission endpoints.


  • the biggest unsolved problem is how to protect against validator IP leakage on the getHeader call.

Nice post!

In point 2:

however relays ignore any bids that exceed the builder’s stake.

Do you mean proposers ignore any bids that exceed the builder’s stake? The attack I’m considering is that a builder could grief the proposer by submitting a high bid, exceeding the stake amount, with no intention of paying. Additionally, if the builder is staked, where is it staked? Requiring the builder to repeat its stake on every single relayer may not be ideal.

if the proposer is the one controlling this, they can play games with the relay to slash a builder when they otherwise were not at fault

to fix this, you need relays to independently be observing some “bid mempool” and then it turns into optimistic relaying v3

funds could be locked on chain where only relays have the ability to slash builder stake

1 Like

I meant the builder’s stake! Will correct in the post.

That should cover the attack you’re talking about.

As for the staking at many relays: that’s no different to what’s happening today.

I’m not sure I follow what games the proposer can play?

If they send earlier than the deadline, then the relay should be able to propagate to the builder. If they send too late, the relay will deem the proposer to be at fault and not the builder.

Yeah, I forgot that is true today. Just didn’t feel capital efficient, but I’ll drop that argument here. : )