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:
Flashbots
Agnostic
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:
Fast, independent relays will receive the majority of bids from BuilderNet
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.
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.
Could you confirm which relays fit the criteria you outlined?
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.
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.
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.