Updated MEV-Boost relay settings

BuilderNet
1

We’re updating way BuilderNet submits to MEV-Boost relays in order to enhance its performance and neutrality. We expect this will result in better outcomes for latency sensitive bundles.

Change

BuilderNet currently submits to the following relays:

  1. Flashbots
  2. Agnostic
  3. Ultrasound EU and US

Going forward, BuilderNet will submit to MEV-Boost relay(s) that meet a set of performance, independence, and reliability criteria.

Performance

Some users require fast replacements. Every additional millisecond from when a MEV-Boost relay receives an updated bid to when it publishes a new best bid to proposers increases the latency for users.

To provide a competitive user experience, BuilderNet will only submit blocks containing replaceable bundles to relays that offer fast ingestion and replacement of new top bids (≤ 10ms), and ensure that the most recent block header is always used.

Independence

One of BuilderNet’s main goals is to create a neutral platform to transact. Operating both a block builder and a MEV-Boost relay can present an opportunity for conflicts of interest. To reduce these risks, we will be capping the percent of bids that BuilderNet submits to MEV-Boost relays which are not independent.

MEV-Boost relays operated by teams that also operate block builders will receive no more than 10% of bids from BuilderNet each week.

Reliability

BuilderNet will prioritize relays that are connected to at least 25% of Ethereum validators and have been in operation for 6+ months.

Effect

We expect these changes to have the following effects:

  1. Fast, independent relays will receive the majority of bids from BuilderNet
  2. Users will receive faster replacement on their bundles

Note: This is just an update, not a final policy. We’ll continue to evaluate the best way for BuilderNet to submit blocks, and may change it again in the future.

1 Like
2

Hey! Thanks for sharing the new guidelines. I think submitting to specific relays for latency-critical bundles makes a lot of sense, and is something that most builders do for a small subset of blocks. Just wanted to clarify a few points as I believe, if taken too far, there is a risk that this could negatively affect the builder → relay dynamics. Potentially centralising and entrenching a small (potentially 1) number of relays.

  1. Could you confirm which relays fit the criteria you outlined?
  2. Would you consider operating a buildernet instance and a relay a conflict of interest, considering that some of the infra (and all for relays) is run outside of TEEs? An interesting point here could be, what happens if an independent relay operator also wishes to join buildernet.
  3. How do you think about the potential centralisation risk if only one relay meets your criteria over the majority of slots?

My concern comes up because based on my view of your rules, I see:
Ultrasound, bloXroute, Titan as “performant” relays.
Ultrasound, Aestus, Agnostic as “independant” relays.

This effectively leaves only Ultrasound for blocks that aren’t part of the 10% quota for non-independent relays and contain replaceable bundles. Depending on how you define “replaceable”, that could mean almost every block.

3 Likes
3

This seems like a good start towards some guidelines. These three metrics are all valuable, and it feels reasonable to build in some gray area, e.g. less performant relays can still receive blocks w/o replaceable bundles and non-independent relays can still receive some % of order flow. George’s questions are on point too.

The performance requirement does stand out as the condition that might need to be more carefully detailed. What exact computation needs to be completed within this 10 ms? I would guess the end point could be reasonably defined as when the top getHeader response is updated. But is the start of the 10 ms when the block is fully received from a builder and decoded? When the first packet is received? The last packet when sending a full block, or the last packet in the block header under an optimistic v2 submission, or somewhere else entirely?

Looking briefly at Aestus’s metrics, block verification time is obviously too long, so this performance requirement would limit submissions to relays willing to accept submissions optimistically from BuilderNet. Further, even block decoding time (when under heavy load) possibly would put a relay outside of the 10 ms range, so optimistic v2 becomes a requirement (which would be our limiting factor currently, and moving to optimistic v2 would make the difference).

Which leads to more of an operational question: how is BuilderNet planning to handle optimistic block submissions? Does each builder entity running under BuilderNet still submit using their own BLS pubkey, such that they can be responsible for their own collateralization and faults with relays? Or does BuilderNet itself check proposer payment in blocks before releasing them to relays? Could make the argument that sufficient trust in the TEEs to verify payment could make collateralization unnecessary.

2 Likes
4

MEV-Boost relays operated by teams that also operate block builders will receive no more than 10% of bids from BuilderNet each week.

Does this include teams that operate BuilderNet builders? Like Flashbots?

5

Thanks for the questions! Leaving some replies inline. Would also reiterate that this is just a first update to address the user feedback we’re hearing — open to other changes down the line.

Could you confirm which relays fit the criteria you outlined?

Ultra Sound and Bloxroute meet the performance criteria so far. The median latencies we see over landed blocks in the last 3d are: Ultra Sound (1ms), Bloxroute (3ms), Aestus (190ms), Agnostic (193ms), Flashbots (279ms).

Would Titan relay be able to make the websocket top bid stream public? Right now our measurements are quite slow (300ms+) but anticipate the websocket is faster. Would be great to integrate if we can get access to a faster feed.

What exact computation needs to be completed within this 10 ms?

We’re measuring the delta between:

  1. The time when a relay displays an updated header over its public bid feed — using the fastest publication method, so websocket if available
  2. The time when a relay reports that it received a block — we’re assuming that relays use the time after deserialization, so optimistic v2 isn’t needed

Would you consider operating a buildernet instance and a relay a conflict of interest, considering that some of the infra (and all for relays) is run outside of TEEs? An interesting point here could be, what happens if an independent relay operator also wishes to join buildernet?

Really what matters is that third parties don’t use their privileged position or access to private pre-trade data to degrade the user experience in BuilderNet. It doesn’t strike me that running a node in BuilderNet would give a relay (independent or otherwise) an incentive to harm BuilderNet users. The risk stems more from sharing pre-trade data with parties that operate non-TEE block builders.

How do you think about the potential centralisation risk if only one relay meets your criteria over the majority of slots?

We’re thinking a lot about how to balance better guarantees in block building with the risk of consolidation in the relay market. On the one hand, we want to raise the bar for pre-trade privacy and give users great execution. If only a few relays are able to meet this bar then it would be a disservice not to prioritize them. At the same time, we’re very sensitive to how this could impact consolidation in the relay market. So we’re making a compromise to send some blocks to relays that operate their own block builders — which is not ideal from a privacy standpoint, but avoids fully entrenching a single provider. Open to iterating on this (suggestions welcome). Long term, we’re working to mitigate a lot of these concerns by removing or reducing BuilderNet’s dependence on relays altogether (eg. TEE-Boost).

QQ: Would other teams be open to running their relays in TEEs? If non-independent relays can attest to their execution and treatment of user data then this reduces the risk of submitting to them.

how is BuilderNet planning to handle optimistic block submissions?

There’s a section on this in the docs :slight_smile: See “relay submission keys”.

Or does BuilderNet itself check proposer payment in blocks before releasing them to relays? Could make the argument that sufficient trust in the TEEs to verify payment could make collateralization unnecessary

Fun question. There aren’t any additional checks on top of rbuilder today but we’re definitely excited about using TEE attestations to enhance or replace relay integrity guarantees (eg. TEE-Boost).

1 Like
6

But the relay operator could give advantage or preference to BuilderNet builders. Isn’t this “an opportunity for conflict of interest” exactly the same as with a non-BuilderNet builder?

1 Like
7

Hey @shea, thanks for the follow‑up.

Would you also be able to share the list of relays you consider “independent”?

The Titan Relay requirements for connecting to the top-bid websocket are fully public. Additional constraints were added, primarily around requiring builders who use it to actually submit to the relay, to ensure builders who do submit are not disadvantaged compared with those who do not. Builders who don’t could have an earlier view of the relay state and react faster to bids through the Titan Relay stream without exposing their own. Appreciate this might conflict with your “independent” relay restriction, which is a new case, so it might be worth revisiting how this rule could work for BuilderNet.

The ~300ms you’re seeing is probably because you are submitting non-optimistically. Our p50 processing time from deserialisation to header-ready is ~4ms, so you should see good performance even without the websocket. Would also note that the timestamp we show is taken ~on receipt of the first packet, not after deserialisation, so that might skew the results. Happy to run you through the process to setup optimistically and help benchmark the relay properly!

From the builder’s perspective, the concern is preferential treatment, not just data sharing. If there is an incentive for BuilderNet operators to win blocks, a relay that also runs a BuilderNet builder can fast-track its own blocks or even serve only those blocks. Even with TEE attestations, there are still big advantages to be gained e.g., colocation.

Here are a few suggestions that I think could alleviate some of the entrenchment risks, especially in the in the short-term while we have a single relay that meets both criteria:

  1. Almost every block contains at least one replaceable bundle, but many add negligible value. To address this a minimum value or block contribution % before the “performant” relay only rule kicks in could be added.
  2. While Ultrasound is the sole relay meeting both “performant” and “independent” criteria, a hard 10% cap on non‑“independent” relays feels pretty strict. It might be worth adding a temporary higher ceiling that tapers as other “independent” relays speed up.

Definitely open. Titan Relay runs the fully open source Helix codebase so happy to explore attesting to that through TEEs.

1 Like
8

Happy to run you through the process to setup optimistically and help benchmark the relay properly!

Great let’s do it. We did use optimistic mode. Maybe its a problem with rate limits?

Additional constraints were added… to ensure builders who do submit are not disadvantaged compared with those who do not

As a block builder submitting to the Titan relay, we would prefer for all bids to be made publicly available over the websocket like they are at other relays. We are happy for BuilderNet bids to be made public as part of this.

If there is an incentive for BuilderNet operators to win blocks, a relay that also runs a BuilderNet builder can fast-track its own blocks or even serve only those blocks

There is no incentive today for BuilderNet operators to win blocks. The operators run their nodes at cost and do not receive any payments from the network.

Instead of competing against each other like centralized block builders do, each node in BuilderNet shares all of its orderflow with all other nodes and coordinates its bids with them. Any block profits are then redistributed back to users, or used to cover operating expenses like subsidies, refund transfer fees, etc.

But the relay operator could give advantage or preference to BuilderNet builders. Isn’t this “an opportunity for conflict of interest” exactly the same as with a non-BuilderNet builder?

It’s not exactly the same. Unlike centralized block builders, BuilderNet operators don’t have the ability to observe the data sent to their nodes, modify the software they run, or earn any profit. Individual operators also can’t unilaterally make governance decisions. So while any relay could always arbitrarily choose to prioritize a certain builder (regardless of if they operate it), the incentive and capacity for misbehavior is substantially different.

list of relays you consider “independent”

Ultra Sound, Agnostic, and Aestus do not participate in the block building market in any capacity. We also generally want to deprecate BuilderNet’s dependencies on centralized Flashbots infrastructure so we’re capping bids to the Flashbots relay at 10%.

9

Aestus has kindly onboarded us to their websocket top bid feed and it is fast. In our latest evaluation:

p10: 4ms
p50: 5ms
p90: 8ms
p99: 13ms

We’re going to trial sending BuilderNet bids to Aestus for the majority of slots, alongside Ultra Sound.

10

bloXroute would like BuilderNet to connect to its relays. Please note that we are no longer operating an active block builder—our builder is currently used for testing purposes only.

Let us know if there are any additional requirements we need to meet before getting connected.

1 Like