Lido MEV policy for the Staking Router

Department of Decentralisation
1

Discussion topic for community - MEV policy

In light of the recent announcement around the Staking Router, thought it’d be a relevant time to ask what folks thought about Lido’s MEV policy as it relates to:

  1. MEV relay provider “allow-list”

  2. Censoring vs. non-censoring MEV relays (see rated.network’s Lido pool operator page and also the EthStaker community’s list on censoring vs. non-censoring MEV relays), and

  3. Vanilla block building vs. MEV-boost enabled building

Context - why discuss this now?

While it is difficult to predict what exactly the operator set is going to look like once the Staking Router and DVT solutions like SSV and Obol go live, clearly it is fair to expect that the NO set for Lido will expand to encompass a broader diversity of actors, each with different sets of considerations.

Enough will change here in Lido that I think it is worth re-visiting some of the work the DAO has done in the past around MEV policy and how all of that fits into 1) the likely near-term composition of Lido and 2) the longer-term goals & ambitions for Lido as it relates to being a core part of the Ethereum ecosystem.

Won’t offer up any strong POVs on my end for now and would welcome comments and further topics for discussion in this thread here.

Including below a couple relevant forum posts and the recent Lido announcement.

I’ll also include SEC Commissioner Peirce’s recent public statement on the SEC/Kraken staking situation. We can shelf the staking regulatory discussion for another thread if that’s too much to tackle in a coherent way in one place, but it is difficult to fully explore this topic (aka how Lido will approach MEV) without touching on regulatory/censorship risk.

*edit: also including the Coinbase public statement on its staking services from 2/10/2023 for additional context, obviously not directly relevant to Lido

Relevant forum threads and blog posts

4 Likes
2

I think one of the key pieces of reference docs in this area would be the Block Proposer Rewards Policy (which includes MEV rewards, relay selection, possible protocol and network service degradation etc); version 2.0 was voted in by the DAO in December, and 1.0 of the policy was put into effect in September.

In general I think the policy is pretty robust and can easily be extended to encompass the potential widening Node Operator base with the introduction of possible new staking router modules; which facets and in what manner do you think need we should approach the revisions?

1 Like
3

Good call! Missed that one. Thanks Izzy. Have updated my initial post to include it as an additional reference link.

That’s a good question. My initial reaction was that the Staking Router, which again was telegraphed far in advance of the recent announcement wrt Lido’s intentions to decentralize, introduces new types of NOs and actors into the Lido ecosystem. Each set of actors may have different preferences when it comes to MEV, economic motivations, and, more specifically, soft censorship via choice of MEV relay.

My rough way to bucket them would be:

  1. Professional, enterprise-grade: effectively who Lido works with today via whitelisting. These are identifiable entities by their very nature and directly subject to jurisdictional risk and demands of legally incorporated entities, some of which are domiciled in jurisdictions that appear to be increasingly hostile to public, permissionless blockchains like Ethereum

  2. Solo validators: net new actors for Lido. Likely the same profile as a home-staker or someone would use Allnodes or RP. Permissionless entry/exit from NO set with bonding.

  3. DVT clusters: also net new actors for Lido. Could comprise a combo of sets #1 and #2. Architecture and assumptions behind the clusters may differ depending on if Obol vs. SSV vs. some other DVT used. Again permissionless entry/exit from NO set likely with some type of bond that can be slashed due to poor SLA or potentially malicious activity, so somewhat similar in mechanism to solo stakers

I agree the block proposer policy is quite comprehensive and well thought out.

There are however some key assumptions in there around the timing of in-protocol PBS and related censorship-resistance measures like partial block auctions, crLists, etc.

My main question then is really around uncertainty of timing–what if, for example, it takes a year to reach consensus on a suitable design for these anti-censorship mechanisms and then another year to implement them in-protocol? What if it takes 3+ years if, for example, other parts of the roadmap take priority like in-protocol DAS (aka scaling)?

Maybe this is all fine and we get bailed out via some combination of timing of things like PBS and/or the introduction of potentially non-enterprise actors like solo validators and DVT node cluster operators means a more robust, less-likely-to-censor Lido validator set, but wanted to raise this as a topic of discussion given the official announcement of the Staking Router seemed like a natural time to perhaps re-visit the original block proposer policy.

Clearly though, the consideration here is around how “opinionated” Lido as a DAO/protocol should be around enforcing policies on its NO set.

I don’t personally have a good answer to what the right choice is and maybe the best thing to do right now is to do nothing, but that personally feels somewhat unsatisfying. And I know this is a somewhat polarizing presentation of the data on mevwatch.info from Labrys, but at the same time it is difficult to fully ignore / dismiss.

image
image604×713 53.4 KB

1 Like
4

Indeed there are key assumptions, but that doesn’t mean that those assumptions should be fixed! The idea behind the assumptions is “understand where we are, understand what’s available” and then figure out how that may affect “where we want to go”. They should be revisited, especially in an environment, like Ethereum, which is constantly evolving.

Wherever and whenever there are options to advance credible neutrality of the network in the near term, even steps that may introduce complexity, the Lido community (from contributors to Node Operators) has shown a willingness to think on its feet and adapt. Two great examples of this are the Relay Maintenance Committee (and the recent work to vet new relays as options for Lido Node Operators) as well as when when Flashbots proposed a method to use min-bid to increase censorship resistance Lido Node Operator MEV Boost min-bid guidance, which was added to the 2.0 policy.

I would challenge that “nothing is being done” here with evidence to the contrary (above, two points re: new relays and min-bid) and below (re: work being done to really understand the state of the network and creating an ability to really see how the network participation may be affected by changing circumstances in the future).

Unfortunately this resource greatly misunderstands what censorship is and egregiously misstates when, how, and how often, it happens.

I’m hoping that the analyses created and submitted as a part of the of the open RFP: Ethereum censorability monitor that LEGO is running will be a lot more useful than the mevwatch resource.

What I believe we need to do is:

  1. get a handle on how bad censorship actually is (or isn’t) on the network (mevwatch and other similarly superficial approaches don’t cut it)
  2. continuously re-assess options to advance credible neutrality and minimize service degradation and determine how they may be implementable on-chain
  3. continue to do as the Lido DAO has done, which is to take all information into account with a long view on network health and by involving as many relevant stakeholders and finding implementation strategies that are practical and market-force aligned
1 Like
5

100% agree :+1:

Also agree, yes!

Poor choice of words on my part–what I meant by “do nothing” is to continue the status quo of keeping the MEV and block proposer rewards policy fixed while doing several incremental efforts to maintain Ethereum’s credible neutrality + combating censorship (of the “soft” variety today).

Yes, the amount of inbound interest received on that RFP is encouraging. Good to see others stepping up to help.

I suppose we won’t know what specific choices new NOs will make (particularly of the DVT cluster variety) when it comes to choice of MEV relay operator, so it’s worth monitoring that closely when it goes live on mainnet.

Something like a NO survey, perhaps surveyed as part of the recurring NO community calls might not be a bad idea? Particularly once we expand the NO set via various means down the line. What do you think @Izzy? Or has that surveying work been done already around why the 30 or so various NOs have made specific choices around relay operators – obviously we should anonymize the answers and just report the aggregate summary statistics / various data cuts of it (perhaps with some blinded survey respondent commentary)

1 Like
6

You can largely see the choices that NOs have made regarding relays either via https://fees-monitoring.lido.fi/ (and there’s additional work to be done here for sure in terms of giving more insights into historical / overall use) or eg via https://www.rated.network/o/Lido?network=mainnet&view=pool . Although there is a “bias” in the data here which basically shows “relays used” instead of “relays configured” (since it looks at blocks which actually landed), I think over time that’s kind of all that matters (e.g. “if you configure a relay that never lands a block, is it really a relay” kinda thing =D).

The thing that will be more difficult to expose is usage of min-bid, and I think a survey will certainly help in that regard. The question of DVT and relays becomes a bit more difficult, because how each different DVT infra solution approaches block proposal duties will determine to what extent the cluster participants need to be fully / somewhat / not aligned in terms of things like MEV Boost and relay configuration.

There’s definitely work that needs to be done even before mainnet in terms of understanding the limitations and possible resulting constraint requirements that might result from different DVT-driven operator configurations. The scope of these questions/problems – and hopefully some early answers – should be born out of the next round of DVT testing https://twitter.com/LidoFinance/status/1621503397139742721

2 Likes
7

Would be great in surfacing all sorts of things! And helpful context for the DAO tbh. I’m happy to help design the survey, but will require a group effort I think. Trying to think of easy ways we can run this and design it without making it burdensome on participants (to avoid the low response rate scenario)…

Yes, it’s great we’re exploring multiple options on that front.

:joy: I suppose in some state of the world, it is the thought that counts. But yes that is the reality of things today. Again, would be something that would also come out quite easily in a survey.

8

Yep! Definitely. Previously we were also discussing an API feature in the MEV Boost discord that allows for relatively easy polling of relay registrations en masse (so e.g. anyone could poll every relay API with a request to see if the Lido set of validator public keys has registered with them and if so with which fee recipient), but I don’t remember the status of this and if it made it into the relay API spec or not.

1 Like