Builderelays: Builder-Relay Vertical Integration

tl;dr builder-relay vertical integration is nearer than we think. It’s unclear what to do. While the market incentives for builder-relay integration have been known for a while, recent announcements (discussed below) make renewed discussion feel needed.

Builderelays Are Coming

The Builder Perspective

The incentives for builders to run their own closely-integrated relays is clear. It cuts down latency by removing the need to send blocks to an extra actor and removes a simulation step (for non-optimistic relays). There’s nothing much new here.

While we have seen small or neutral builders run relays in the past (and FB has always done so but in a non-integrated way), Titan launching a relay seems more substantial, given their position in the market and focus on “additional features”. Stephane made a similar pitch not long ago.


PEPC-Boost was conceived as a PoC for PEPC. The idea is to have a relay enforce some block building rules on behalf of the proposer with the first example being running two separate auctions (top-of-block and rest-of-block). This looks a lot like a primitive version of block building. It seems natural that the “proposer commitment” will evolve to include more than 2 bundles per block as this likely increases profit, leading to the relay basically becoming a builder.

Ultra Sound Relay Monetisation (for PG)

JD has been talking about making a change to the US relay to capture some value. US is currently faster than other relays. This means that US has an additional window for new (presumably higher) bids to flow in. They plan to take the delta between their highest bid and the highest bid that could have been seen by other relays and put that in some funding pool.

The amount the relay is able to skim, not only depends on how much faster it is, but more generally on which builder submissions it receives exclusively.

Staking Yield Maximisation

In the short run, reducing latency by directly connecting to block builders should increase validator payouts. With teams already working on MEV-related optimisations to maximise staker revenue,, it would not be surprising to see node service providers opting to connect to builderelays.


The extreme case is that competition between builders means that the only way to reasonably be a block builder is to also be a builderelay. This would turn competitive building into a permissioned role. Since becoming a relay requires doing BD to garner trust and be whitelisted by validators, the barriers to entry into the builder market becomes quite high. This puts builderelays in a position with significant market power over both validators and users/searchers. I’m not yet quite sure how to think about this.

The less-extreme case is that competitive forces mean that several builderelays pop up, but difficulty getting new relays adopted and relative efficiency of optimistic relaying (and something like US’ monetisation strategy but with kickbacks to builders) means that several builders still share single relays to pick up scraps left by the builderelays at low-volatility times in which latency plays less of a role.

Wat do?

I don’t feel certain about what should be done, but here are a few options.

Reduce inefficiencies in disintegrated system: Make current relays resemble builderelays as much as possible to reduce integration incentives. Features like optimistic relaying and relays taking on bidding duties (e.g. US proposal) are examples of this.

Multi-relay queries: If validators only signed headers that they receive from at least N relays (assuming relays are still public entities and not sybils), this would significantly hamper the incentive to integrate very closely with a single relay given that its the $N$’th fastest relay that counts. The tradeoff for validators is that they suffer less liveness risk, but also likely receive lower revenue.

SUAVE: If validators could trust anyone running their relay in a kettle (or just SGX?) then becoming a relay (or builderelay) would be much lower barriers to entry than doing BD. A validator would simply need to check a registry of keys that correspond to valid kettles/SGX-relays. The problem here is that SGX can enforce that a bid and header correspond to a valid block which does pay the bid, but it cannot enforce that the relay responds to the validator’s signed header (e.g. the SGX can be disconnected from the network). An alternative way to address relay trust issues is to have the validator run an SGX node themselves to custody the data to prevent liveness attacks, but this needs a lot more thinking around implementation.

Preserve Open Source Norm For Relays to prevent more bespoke logic moving to the relay and making integration with the builder more transparent when it happens.

Move Some Building Logic Back To The Validator: This is an incredibly complex topic, but should be listed here.

I would appreciate it if people weighed in with some thoughts


This is a great summary!

I find the following sentence of particular interest:

This is a very interesting point. It made me think that, for a builder, it might then be better to submit to only one relay (the one that offeres that service - I assume that the builder get a small kickback and the relay the large chunk of the profit generated by adjusting the bid).
Also, I guess this could create an incentives for all strong builders to submit to the same relay as everyone wants to have that service while no one wants to increase the bids at other relays because the kick back could be smaller.

On the other hand, builders could already collude today, which weakes my argument of above.
I have to think more about this but I think this bid-delta compensation could have some unforseeable side effects on the builder and relay landscape.

The solution to this problem (and many more) is to simply enshrine PBS, force the builders to be staked and in-protocol, and then they can trustlessly be a relay without the need to garner any trust and do any BD.

1 Like

Hey @Quintus – Kubi from Titan here.

I completely agree with you. Builders and relays becoming vertically integrated does pose a significant risk to the competitive nature of the builder market.

Following discussions at ETHCC in Paris this year, it’s clear that many smart people in the industry believe that relays will continue to be fundamental infrastructure, even in a post-ePBS era. Moreover, there’s a significant incentive for builders to pursue vertical integration.

From our viewpoint, a highly competitive relay that is open to everyone significantly diminishes the advantage of vertically integrated builder-relays. This is what you were referring to in the ‘Reduce inefficiencies in disintegrated system’ section of your post I believe. This approach seems to be the most realistic way, at least in the near to mid term, for existing builders not vertically integrated, or even new builders, to stand a chance at being competitive.

This understanding is one of the primary reasons why we chose to develop a highly performant relay in Rust from the ground up. It’s a strategic defensive action. Our relay will be non-integrated, open-source and accessible to all builders. Maintaining credibly neutral infrastructure is a key value for us, as demonstrated with our block builder, and we plan to continue this practice with the launch of our relay.

We realized that the threat is real and that we are in a unique position to do something about it, which is why we decided to launch a relay.

1 Like

would love to see a proposed design :eyes:

Here’s a very concrete one

And it’s design doc is here. Very much work in progress and slowly in our free time is advancing, regardless of adoption we will have a PoC for Prysm + geth in the coming months.

1 Like