Lido on Ethereum: Relay Voting Proposal

Thanks @aidan and @michaelsproul for your input. I’d like to reiterate the objective and thrust of the policy, which is to attempt to implement a mechanism which mirrors enshrined PBS as closely as possible.

In enshrined PBS (based on current designs), the validator (block proposer) will not be able to differentiate between what’s in blocks, thus they will effectively process whatever block pays the highest, with the possible addition of txs via crLists (which can, and should, be implemented in out-of-protocol PBS as well, and I don’t see why something like this wouldn’t be suggested for adoption by Lido at the earliest possibility in keeping with the same principle). This is mimic’d by hooking up a proposer to as many relays (and thus builders) as possible, with the caveat that due to the fact that MEV Boost-based PBS requires trust assumptions between Relays and Proposers there’s a vetting process that otherwise wouldn’t be necessary.

The point of using as many relays as possible is to foster relay and especially builder diversity; it is builder diversity and builder dominance which ultimately ends being the decision maker with regards to whether transactions are censored or not, and for how long.

Using “non-censoring” relays doesn’t actually prevent potential censorship from happening, because “non-censoring” is not “anti-censoring”. e.g. if the best builder 6/10 times is a tx-filtering builder, and that builder is sending blocks to non-filtering relays, then those are the bids that the relay will send and will be proposed.

Until such a time that anti-censorship mechanisms (crLists and/or ideally encrypted transactions) can be made a reality, I think that the best way forward is to test the system “as it will be” so that the right solutions can then be designed and appropriately prioritized. These are failings at the protocol level (both from a design and incentive perspective) – they should be remedied as such.


I do not believe PBS will ever be added to the Ethereum protocol without crList as mandatory per-requisite. Else the protocol would accept censorship which goes against its core values.

If we assume that this is the case, then to mirror future PBS LIDO should not add a “must-include” list of relays without some out-of-protocol crList mechanism. Until that time LIDO should mirror the actual Ethereum protocol which allows to not include censoring relays, at the staker’s discretion.


Practically this doesn’t solve the issue because censoring is driven at the builder level – not the relay level. Currently the reason that OFAC-compliant blocks dominate is because flashbots builders (which are OFAC compliant) are producing the highest-value blocks more often than other builders are. What’s to stop flashbots (or any OFAC-compliant builder) from sending these winning blocks to non-censoring relays and them ending up on chain?

There’s only two ways for this to happen: (a) relays that are not open to external builders and that’s patently net-worse from a builder decentralization perspective, and (b) the relay itself is doing “anti-censorship” checks (i.e. censoring potential censorers) which no relay is doing. If one can find a relay that is doing this and show that they’re effectively doing so and not ending up censoring bids erroneously, then I can see that arguing that allowing for this kind of relay choice is an optimal “censorship resistant” path. Until then, all it does is reduce the relay pool and builder pool with little to no material benefit.

I think a difference of opinion here is whether or not there could exist a censorship-free mev-boost space without crLists. I think “yes”, the current policy implies “no”.

By dictating a must-use relay list, the current policy assumes that censorship is inevitable – “the flashbots builder will just move to a different relay”, “there are no anti-censorship relays”, etc. I do not think this is inevitable at all, and as an example let me offer the case of This is a new relay with a single builder that is non-censorsing (source) and competitive with Flashbots for profitability (source). I would argue that an operator wanting to use a non-censoring list of relays like Relayoor + BloxRoute MaxProfit + Manifold should be allowed to do that, and will end up censoring less transactions than an operator using the must-use relay list (which will fallback to Flashbots most of the time). Not only is the alternate list less censorious, but it could also be more profitable!

I think the main argument in favour of an allow list is that Lido needs to trust the relays not to collude with the operators to steal value? Fair enough. However I don’t think this argument applies to the must-use list. The argument there is more along the lines of “operators must be competitive”, which I think could be achieved through metrics without a must-use list of relays.

I think the chance of an anti-censorship relay emerging before crLists are specced and implemented is also non-zero. It would be trivial to make a relay that only allows blocks with at least one non-compliant transaction (e.g. to Tornado Cash). Builders could just insert one if there were none in the mempool. If I weren’t preoccupied I would be tempted to build this myself.

To summarise; I’m in favour of abolishing the must-use list and allowing all operators to choose their own list of relays. This gives operators the flexibility to adopt new relays as they emerge, or drop ones that are malfunctioning or found to be untrustworthy. It allows operators to favour non-censoring relays if they believe that to be an effective strategy, without a decision being made on their behalf by the Lido DAO.

I think a difference of opinion here is whether or not there could exist a censorship-free mev-boost space without crLists. I think “yes”, the current policy implies “no”.

I don’t think censorship-free is technically possible without fully encrypted transactions/mempool (or shutterizing them / etc). Even crLists do not guarantee censorship-freeness (e.g. a transaction may be delayed long enough before it’s picked up in the crList as to fail/revert/etc and thus be considered censored). Given that operators are asked to connect to as many of the “must include” relays as possible and given that the best block bid wins out and given that best bids could come from any of the connected relays, it is possible that the same level of actual on-chain censorship in MEV-boost space could exist without crLists as with. Once again – the issue is possible censorship at the builder level, not the relay level. If an operator is connected to all relays and the best builders don’t censor, there won’t be censoring.

“Non-censoring relays” are a misnomer. These relays provide no assurances about whether the blocks that they relay are censorful or not – just that the relay itself doesn’t care. In fact we could have censoring blocks being sent by “non censoring” relays and no one would be the wiser because the tools to assess actual censorship on the network currently do not exist (though some are trying to build them and IMHO I do not see any reason to not support this effort). Using “non censoring” relays and thinking we’ve accomplished something without actually assessing the practical effects and just saying “well, technically it’s probably less censorious” is performative.

This is a new relay with a single builder that is non-censoring (source) and competitive with Flashbots for profitability (source). I would argue that an operator wanting to use a non-censoring list of relays like Relayoor + BloxRoute MaxProfit + Manifold should be allowed to do that, and will end up censoring less transactions than an operator using the must-use relay list (which will fallback to Flashbots most of the time).

Relayooor has been contacted since day 1 to sign up to the Lido on Ethereum: Call for Relay Providers and they haven’t. I understand from their side why they probably want to take it slow before taking on the traffic and responsibility that Lido NOs may bring (although obviously there’s no reason to not do slow rollouts at a pace they would be comfortable with), but given that they are an anon relay I think it’s important that they show up here, represent themselves, and put themselves forward.
IMO it is not reasonable for someone else to take on the responsibility and accountability of this given the trust assumptions engendered by how MEV Boost currently works – but actually someone, anyone, can. Anyone can propose an addition to the “allow list” – so if e.g. you want to do that and the DAO signs off on it (which I don’t see an issue with personally given that it’s up to NOs to use) then it could be used, but the onus is on NOs there to (a) do the work and (b) stand by the their choices.

Not only is the alternate list less censorious, but it could also be more profitable!

If all you’re doing is adding/removing flashbots from the configuration, then I don’t get how it would be more profitable, since the most profitable block would be included regardless. At best it would be “as profitable”.

To summarise; I’m in favour of abolishing the must-use list and allowing all operators to choose their own list of relays. This gives operators the flexibility to adopt new relays as they emerge, or drop ones that are malfunctioning or found to be untrustworthy. It allows operators to favour non-censoring relays if they believe that to be an effective strategy, without a decision being made on their behalf by the Lido DAO.

This causes way too many possible issues due to trust assumptions and moves away from the goal: get as close to enshrined PBS as possible, so we can actually figure out what that’s going to do to the network. Right now reactions re: “look how censored the network is” are hyperbolic and basically wrong (see some work Rated has started doing on .

It allows operators to favour non-censoring relays if they believe that to be an effective strategy, without a decision being made on their behalf by the Lido DAO.

A protocol like Lido needs to be able to strike a balance between doing what’s best for stakers (which includes not making the underlying network worse), managing those risks, giving NOs enough leeway to operate the way they need to given legal realities and their organizational ethos (which I honestly believe this policy allows for), and operate within the technical limitations of the underlying protocol. If e.g. triggerable exits existed on Ethereum (or even just plain withdrawals), where stake could be reallocated between NOs more easily, I can definitely see empowering NOs to make these decisions on their own because then the protocol has recourse if the decisions the NO makes end up being bad. However, in the current system, this is not possible, so the policy has to account for that.

1 Like

Hi everyone, there will be a community call and discussion about the topic next week. Updates on the community call will be posted in (Lido Node Operator Community Call)


Very happy to see you here. What do I think:

As long as Lido pushes for an open market for block builders, there’s no way the most profitable builder (which is currently Flashbots who happen to censor txs interacting with OFAC-ed txs) is pushed out of it. If they make most expensive blocks 80% of the time and the market is open, 80% of blocks will be censored. Right now Flashbots builder only works through Flashbots relay but it doesn’t have to - and it’s not even required for them to reconsider that, relays can proxy each other if they want to. Removing flashbots relay while maintaining a somewhat open market is not likely to change a thing, it would be just a gesture.

I am against Lido closing market for blocks. That’s the power that Lido should not have in the first place and the ability to have it happened upon Lido bc the block market design is not completely trustless - and I don’t want Lido to make steps in that direction unless the situation is absolutely dire which I don’t think it is now.

The potential viable policy for Lido would be “operators just decide for themselves we don’t care” but I think it would lead to much less usage of less known relays and non-censoring relays in Lido. And I think that relay diversity is the one of the most important long-term challenges for Ethereum. On the balance, I don’t like that option compared to what we have now.

1 Like

I think some of the existing tools do actually give us an indication of censorship, in particular shows how many censored transactions are included per relay. We can also see from that the builder-relay affinity at the moment is very strong, with very little crossover. I think we can exploit this, at least temporarily, to gain stronger anit-censorship properties. I am against presupposing that builder migration and censorship are inevitable, and I would at least like us to try the non-censoring relay approach and see what happens. There’s inertia and hidden information that may cause builders to behave differently than we expect from a naive model of their incentives.

I think the chances of good anon relays existing are quite high, and they may not want to doxx themselves to participate in Lido governance. I’ll look into championing Relayooor so they can join the allow list while retaining their anonymity, thanks.

I mean removing Flashbots and adding Relayooor, as Relayooor isn’t part of the allow list currently so its blocks are not being considered.

I did some more reading about the current PBS designs and I think there are few points worth highlighting:

  • In almost all current PBS designs proposers are still free to choose a bid other than the highest paying one. This means they retain the freedom to avoid censoring builders if they are willing to forego some profits. The only PBS design that forces the proposer to take the max bid is Francesco’s MEV-smoothing design, which acknowledges in the last section that censorship resistance is harder when profit-maximising is enforced (and needs to be handled via another mechanism).

  • There is a conflict between Lido’s desire to support open block markets, and its desire to prevent MEV hiding. If it were the case that enshrined PBS required proposers to choose the highest paying block no matter what, then Lido would be unable to blacklist builders that are suspected of hiding MEV. However, this is a moot point because enforced max bids probably implies MEV smoothing, which would disincentive MEV hiding, as all the builders would need to collude to artificially lower the highest bid. I don’t think it is possible to simulate this dynamic in the current system because there’s no max bid enforcement, and the current must-use+allow list system is a poor approximation because it excludes some builders. I think the closest approximation would be requiring operators to use all known relays under the sun, but this would come with the significant downside of reduced censorship resistance, as Francesco notes in his post.

    In the other case where max bids are not enforced in enshrined PBS, the situation is much more similar to what I’m proposing: the block proposers are free to choose bids in whichever way they want and may altruistically forego profits if they wish. I think we can simulate this today by giving operators free choice over the relays they use. This also has the advantage of improved censorship resistance because of the reasons stated earlier in my post (builder-relay affinity, interia/loyalty/etc).

I would be in favour of this. IMO word of mouth and reputation can move faster than DAO governance adding to the allow list, and the anarchic approach to relays gives better censorship resistance + a closer emulation

Finally, it seems that enshrined PBS or mev-boost inclusion lists are still at least a few months off, based on the current state of research (Barnabé). So making a good decision in the interim is not inconsequential. Currently I like the sound of the forward inclusion lists, which socialise the cost of censorship-resistance over the whole network, which as noted in that post also can’t be simulated using mev-boost.

1 Like

It’s useful but somewhat limited in that it only tells us information in the context of singular relays. This data doesn’t tell us anything about “once submitted how likely is it that X transaction will censored for Y blocks before it lands on the chain”, nor do we know how many other builders were vying for the slot at the time, what the value of those bids were, if the bids were censorious or not, and which of the relays the proposer was connected to.

Inclusion per relays unfortunately doesn’t tell us a lot about the “winningness” of bids that would (or wouldn’t) include potentially censorable txs if someone was using all relays (e.g. in an enshrined PBS-alike setting).

One could argue that builder-relay affinity is strong because there’s little reason for the builders in question to need to seek new relays. Once that reason exists (i.e. the relays that send their blocks won’t have enough connections to possible proposers), then you create a reason for builders who previously didn’t see a reason to send bids to additional relays to now start to.
I’m claiming that this would happen eventually anyway, but I’m also saying that if you try to stifle successful builders via relays you’ll make it happen faster. You’re claiming that it’s worth trying because it may not happen at all – however if it happens you’re now in a potentially worse situation, earlier than you would be in the other scenario, with fewer tools to combat it.

I didn’t mention anything about them doxxing themselves – but if the relays themselves don’t come and say “hey – we’re here, this is what we stand for, this is how we will strive to ensure good operations and performance, here is our history of performance, despite being anon this is what we think makes us trustworthy, etc, use us!”, then I see little reason for an NO to use them and I see a few reasons why DAO members and stakers would be suspicious of an NO all of a sudden using such a relay.

I’ve seen those designs included as a possibility (i.e. “here are all the ways that this COULD be done”) but not as a likely choice. Efforts seem to be geared towards the max-bid design (hence the additional designs and research on crLists and MEV smoothing, which otherwise aren’t as necessary). Designs like where the proposer is more than a “dumb pipe” have potentially ruinous implications w.r.t. censorship resistance. It basically opens the door for things like censorship-at-the-proposer level which is not desirable.

I don’t really see the conflict. In open markets a builder that hides MEV should lose out to builders that don’t, provided that proposers are connecting to as many builders as possible. This is of course seriously harmed by builder centralization (which means there may be wide differences in bid margin between builders and thus allowing the dominant builder to still do this, or increases chance of collusion and cartelization of bids), which is why relay and builder diversity at this stage is crucial; but these same problems apply to enshrined PBS as you explain, so it’s a wider protocol design issue, not a Lido issue.

Once relay management can be done via the Easy-Track mechanism (~within 1-2 months) a relay could be added to the allow list in a matter of days. Regardless, right now the issue is not existence of additional relays but their reluctance to participate in the process (even as anon). If we are saying that the vetting / trust-building here isn’t as important as the potential censorship-resistance that we gain by giving NO’s more flexibility re: relay choice, then we also need to be more specific (and strict, IMO) about what the repercussions are for an NO that makes this choice on their own but where potentially negative consequences affect the protocol and stakers.

One of the core issues with anarchy on node operator level is that node operator is, logically, now responsible for the performance of the relays they choose and any problems on relay level (like the recent ones with bloxroute or manifold) are theirs to sort out. Power equals responsibility. Now Lido acts as a powerful negotiator who deals with relays having issues.

The other core issue is I think you overestimate the amount of effort average NO will put into sourcing and vetting relays. In my opinion many of NOs will just settle for a couple reliable ones which will be pretty bad for relay and builder diversity.


Sorry that I can’t make the call tonight, I’ve been ill today and can’t do the 12am time slot.

Here’s a quick dump of my latest thoughts.

I would expect the majority of Lido operators to still follow the greedy strategy. Only a subset would likely follow the non-censoring relay strategy. The dominance of Flashbots network-wide (including outside Lido) suggests that non-censoring validators would be in the minority and may not trigger builder migration. Some relays (Relayooor) also don’t accept new builders, and this could be a good thing (closer to enshrined PBS).

Francesco gave the impression that MEV-smoothing and enforced max bid were unlikely when I asked about it (both are absent from Barnabe’s recent writeup). However I think it’s too early to know which way it will go. One of the main issues with enforcing the max bid is that it increases complexity and introduces a new latency assumption: the attesters have to receive all of the bids by some deadline and come to consensus on which is maximal, else block production fails for that slot. Regardless, the inclusion lists (or proposer prefixes/suffixes) are essential for censorship resistance in all MEV designs.

Suggestions of actionable changes that could be acceptable compromises:

Prop 1: Rename “must-include” to “should-include” for clarity

Prop 2A: Make no other changes to the policy. Introduce Relayooor to the allow list via DAO governance.

Prop 2B: Abolish the allow list. Remove the indemnity provided to operators for running relays other than the ones listed on the “should-include” list. Other relays can be used by operators at their own risk.

Both 2A and 2B would allow interested operators to run Relayooor + BloxRoute + Manifold without being in violation of the policy. The impact on rewards should be minimal due to Relayooor’s profitability. BloxRoute and Manifold provide diversity. Relay malfunctions may be dealt with by the fallbacks built into clients/mev-boost, or failing that, manual intervention.

My current preference would be for 1A + 2B.


Some post-call points:

  • I agree with Hasu points that relayer + builder diversity (i.e. running all competent) is the longer term solution to these problems.
  • In such a perfect market, non-filtered block = most profitable block. However, currently that’s not the case
  • To correct this deviation, some compromise must be made. @michaelsproul points address it. Else I propose
    • Prop 2C: LIDO can allow a fraction of validators to run an “ethical” list, while the majority runs a “greedy” list. With this arrangement LIDO can both compete and appease community concerns.

I like the inclusiveness of 2C!
But I’d try to still find a common denominator / bounds from the LIDO DAO though, which could be the economic band of acceptance around the reference block value that Izzy eluded to maybe?
As a LIDO staker, personally I’d be happy to sacrifice some economic performance for “high ethical standards”. It has parallels to social responsible investments (which also is pretty complicated and heavily debated in the details…).
But I also see the market realities, LIDO goals and NO legal necessities, so giving choices as much as possible while ensuring some control/risk management sounds appealing to me.


It may also be relevant to the discussion that the latest mev-boost update includes a new feature, called min bid, that allows validators to ignore the worst x% of bids coming from mev-boost and build these blocks locally instead. The idea behind it is to give the ability to make some portion of blocks locally but at the smallest possible opportunity cost. We (Flashbots) are posting a longer announcement about it today or tomorrow.

That said, I think we are better off keeping the must-include list but requiring NOs to include most but not all of the relays (my straw person proposal would be 75%.) This gives the same benefits at arguably the same cost and with less complexity.


Here is the post I was talking about:


On the first glance this looks like a really good idea. Need to think a bit more about it but to me it looks like it’s a really a good fix here that is 10x easier to deliver than crlists


@dapplion @michaelsproul @Adrian
What are your thoughts on this?

In terms of short-term implementation, I think this works decently well because it’s immediately implementable and still works within the spirit of the policy: node operators that want to opt into this can, and those that can’t won’t, and the overall effect on staker profitability is kept at an acceptable level. Two questions here are around coordination and monitoring: how do we determine what the right min_bid is, how is that value propagated to NOs, and how do we ensure that the min_bids are set at an acceptable level, but I think these are easily solvable (and e.g. the reference block calculations can take the latter question into account).

The only downside here is that you lose a little bit of reflexivity in terms of being able to identify issues with relays right away (e.g. if min_bid > 0 one may only realize that there’s issues with a relay later than someone who is using min_bid == 0, but hopefully via 3rd party monitoring/alerting services we may be able to still propagate this happening to NOs quickly).


I think it’s a good idea. However one of the purposes of Lido DAO is high APR. Can the above solution be a hindrance to high APR?

Both ignoring some relays from the must-include list and setting a min bid below which relays blocks are ignored lowers the APR for Lido stakers marginally. However, the benefit would be to increase Ethereum’s censorship resistance, which is also in Lido’s interest. I don’t think it should become the norm for all NOs to use a mev-boost configuration that doesn’t maximize APR but if only some do it, the APR sacrifice for Lido should be very small.


I’m in favour of the min bid approach!

I think setting it so that say ~35% of blocks are constructed locally on average would be good?

I guess this would supersede the other changes to the relay policy, except maybe the must-include → should-include change?

(edited 40% → 35% as the flashbots post has nice numbers for 35%)