Lido Node Operator MEV Boost min-bid guidance

The purpose of this thread is to collect discussion and community alignment with regards to min-bid usage by Node Operators participating in in the Lido Protocol.

As a start, I propose we begin the discussion based on Irina’s post from the relay voting proposal thread.

In general I think that ~28-40% of blocks produced locally sounds about high but isn’t a prohibitive starting point, although a maximum APR decrease of 15% sounds high, given that it’s currently not easily discernable what effect this level of local block production would have on ameliorating overall service degradation in the network. That said, due to how min-bid works, it’s to be expected that APR effects will be worse during lull periods (vs busy periods), so if based on feedback the NO community feels that overall more validators would opt in than the estimated 60%, the configured min-bid can be lowered.

I propose that the DAO can make min-bid > 0 an opt-in measure for NOs who wish to use it, with a value up to (but not exceeding) the initial suggestion of 0.07, which can then be tweaked down if either large negative effect on APR and/or higher usage of min-bid than expected is noted, and then after ~1-2 month of usage and hopefully with some initial results from RFP: Ethereum censorability monitor to fine-tune the suggested min-bid value based on:

  • how many NOs are actually using min bid > 0
  • approximate effect on amelioration of (possible) service degradation

We are a bit on the fence regarding min_bid.

Generally, we appreciate the effort and we would like Lido to be censorship resistant.

In general I think that ~28-40% of blocks produced locally sounds about high but isn’t a prohibitive starting point, although a maximum APR decrease of 15% sounds high

On the other hand, we feel that a maximum of 15% decrease in APR is not to be underestimated.

We discussed this internally and if the APR decrease would be in the 5-10% range we would be much more confident to say yes.

We also did not want to say we opt-in now, but not do it in the end, as this would skew calculations and projections for other NOs.

I propose that the DAO can make min-bid > 0 an opt-in measure for NOs who wish to use it, with a value up to (but not exceeding) the initial suggestion of 0.07 , which can then be tweaked down if either large negative effect on APR and/or higher usage of min-bid than expected is noted

This sounds like a sensible approach!


Min-bid should be a must, not an opt-in. The decentralization and censorship resistance of the network is non negotiable.
However the value to be used needs to be discussed, targeting 1/3 of blocks locally or a 5% APR decrease for example.

1 Like

I agree with the general approach too.

I think it would be good to set some lower bound however. i.e lowest <= min_bin <= max.

In general operation, I’d like to think that we’d prioritize local block production over block builders especially if the monetary gain to us using a block builder is very small. I don’t have a number for lowest, but perhaps something that would reduce the overall APR <5%.


If an NO can use anything in between 0 and the max suggested I’m not seeing a strong reason for an enforced lower bound. IMO there are two overriding concerns here:

  • NOs cannot be forced to use min-bid (for the same reason all NOs cannot be forced to use any specific set of relays or specific categories of relays – overriding legal/risk/operational assessment concerns);
  • Local block production in general moves away from the “validators should be dumb pipes” principle and introduces concerns about MEV hiding, off-channel payments, etc. which all have to somehow be answered or monitored, and the operational work and complexity to do that is very high. The concession made here is that in order to address concerns about service degradation on the network there is a that proposal which may prove effective from a practical standpoint in the near-term until more robust solutions are implemented, and it makes sense to try it out.

There are some additional minor benefits to setting a min-bid of zero (or having a sub-set of NOs which do) e.g. you’re not “late to the party” in terms of figuring out if there’s something wrong with relays.


Yep, fair points.

I’m all for NOs having freedoms to act within their legal requirements.

Its tricky to find a balance between legal requirements, whats best for the network and whats best for stakers (maximising APR). Each operator seems to have their preference of each of these.

But yes I agree, it may not be reasonable to force operators to use min-bid.

1 Like

I would also add to this that setting a min-bid helps to reduce the requirement of always using an external builder/relay for every block produced, sometimes for little revenue benefit. Building more vanilla blocks decreases the risk of missed/orphaned blocks due to things like latency/configs or other external problems which may arise. And of course, less censorship potential. We’ve already seen a few orphaned blocks which could have been prevented by just publishing a vanilla local execution block - with very little difference in revenue.

Though, I also agree that this should be a setting based on a node operator’s evaluation and if we can come up with a maximum threshold for min-bid, that should be the only enforceable parameter.


Dear NOs, LDO holders, and stakers - more than one and a half years have passed since The Merge and a lot has changed in our space, not only with Dencun, but also the launch of Lido V2, onboarding wave 5 of the curated set, the long-awaited release of the Simple DVT module to mainnet, etc.

We have seen the protocols develop and new findings, dashboards, and tools being published with regard to MEV-Boost, the block builder and relay markets, the Lido on Ethereum relay lists [a, b], timing games around bid size maximization, and on the validity of the assumptions made right after the merge [c, d] - e.g. about the opportunity costs of min-bid based censorship resistance in proposer/builder separation (PBS) [e, f] as well as the adoption of respective optional configurations by Lido’s curated NOs [g, h].

This has prompted fellow DAO contributor @Greg_S and myself to revisit the topic of min-bid to, collaboratively with you, identify the best possible approach for it on Lido on Ethereum today.

Status quo
In contrast to the original assumption of around 60% opt-ins, up to and including VaNOM Q1/2024, only 5/37 ≈ 13.5% of the curated NOs self-reported that they had configured some form of min-bid. Furthermore - checking the Lido Fees Dashboard - only about 8026/58246 ≈ 13.8% of all blocks proposed by validators run by the curated NO set in the last month had an unknown payload source - which, for the sake of simplicity, can be equated with non-relayed, locally built (“vanilla”) blocks. Taking those 13.8% as a rough differentiator between NOs using min-bid (those with a higher percentage of blocks proposed with unknown PS than the reference) and those who do not (lower percentage), within the last month 6/37 ≈ 16.2% of them seem to have had min-bid configured at least temporarily or to a limited degree.

Before we dive into the methods that Greg used to calculate possible outcomes in terms of vanilla blocks proposed and APR lost for various combinations of min-bid settings and adoption rates of curated Lido on Ethereum NOs based on historical data, let me first share the questions we would like to discuss with you based on said findings:

  1. Between the maximization of the staking APR - crucial for the competitiveness of the Lido protocol and the security of the Ethereum network - and the resistance to transaction censoring by block builders and/or relays with the help of min-bid, taking the opportunity cost of unrealized MEV rewards into account, what percentage of vanilla blocks do you consider reasonable for Lido on Ethereum?

  2. Given the importance of the share of opt-ins to the percentage of blocks locally built by the curated set, the dynamics of this metric i.a. due to bid sizes changing over time, the easy adaptability of the min-bid setting and difficult monitorability of the configuration for the DAO, as well as the circumstance that currently fewer NOs use min-bid than originally anticipated: should individual NOs be allowed to configure higher values than specified in the Block Proposer Rewards Policy at a given time to bring the overall vanilla block rate closer to, for example, the 28% initially targeted? Practically turning the policy’s min-bid requirement into an interpretable reference point conditional on the percentage of blocks locally built by the entire set?

  3. If you do not consider this approach feasible, given the constraints that prevent some of the NOs from configuring min-bid entirely, what else do you propose to ensure Lido on Ethereum’s censorship resistance?

  4. Irrespective of whether we agree on a tolerable share of APR to be sacrificed, vanilla block rate or min-bid setting as the independent lead variable to achieve satisfactory censorship resistance - in your opinion, how often should this parameter be reviewed to provide a helpful and enforceable reference and at the same time keep the effort required within reasonable limits?

Relation between min-bid and APR
Before diving into the numbers, it is crucial to again highlight the following relation between min-bid and APR: If part of the Lido on Ethereum NOs do not use min-bid, those who do need to produce (significantly) more vanilla blocks for the entire set to reach the targeted rate.

For example, with 10 NOs, a targeted share of 30% vanilla blocks, and 6 NOs not configuring min-bid, the remaining 4 NOs need to produce 75% of blocks locally to achieve a share of 30% (4/10*0.75=0.3). We call this the ‘adjusted percentage’-share of blocks which need to be produced locally by NOs that use min-bid to reach the desired total percentage of vanilla blocks.
The equation is simple:

\text{Adjusted percentage}=\dfrac {\text{Desired total percentage}} {\text{Share of NOs that uses min-bid}}

Now, let us dive into numbers. The full table can be found here and since it is pretty large, we will only use the most relevant parts of it in this post.

Protocol’s POV
From Lido’s point of view, it is important to look at the whole structure of the validator set and take into account both NOs who use and those who do not use min-bid. For each combination of a percentage of NOs who configure min-bid and a range of possible min-bid values, we created a table showing the respective rates of vanilla blocks produced and the APR decrease in percentage points - following, e.g., for min-bid values of 0.03, 0.05, and 0.08 ETH:

How to read this table
If the DAO agrees to set min-bid to 0.03 ETH and 40% of the NOs opt-in, Lido’s curated set produces 9.4% of blocks locally while the APR decreases by 0.06%. Therefore, instead of an APR of 3.4% it generates 3.34%.

Accordingly, if min-bid is set to 0.05 ETH and 60% of NOs use it, Lido produces 28.8% of blocks locally, but the APR decreases more drastically, by 0.2%.

It is also important to note that these tables generally tend to overstate losses since the percentage of vanilla blocks due to min-bid is considered as part of the expected value, while in reality, not each locally built block would necessarily be lower in value than a relayed one, for example in times of low bid sizes during which builders are not able to bundle blocks more valuable than validators with min-bid configured.

How to make a decision
Using the above table, NOs can decide which decrease in rewards is acceptable to them for a certain level of expected censorship resistance, while also understanding how many vanilla blocks will be produced by Lido if other NOs opt-in to min-bid as well.

Methodology and calculations
All calculations are based on historical data of all blocks produced by Lido on Ethereum’s curated set from the merge until 2024-04-23. The calculations consist of several steps:

Step 1. Min-bid values by vanilla block percentages
First, we solve the task of finding the min-bid values required by various predefined vanilla block percentages. For that, we take a targeted share of vanilla blocks, e.g. 30%, and then calculate the adjusted vanilla percentages based on the amount of NOs who configure min-bid.
As a result, we get the following table:

If every NO uses min-bid, each needs to produce 30% of blocks locally to achieve 30% of vanilla blocks. If 60% of NOs opt-in, they need to produce 50% locally for the total share of vanilla blocks to remain 30%. Accordingly, a situation in which only 20% of NOs configure min-bid to achieve a total share of 30% vanilla blocks is impossible (we assume that block proposals are split equally among NOs), which is why the adjusted percentage for this scenario was left empty.

Then, we determine the min-bid values that satisfy the condition of being the limit below which the targeted adjusted percentages of locally built blocks have historically fallen. This means that, e.g., for the adjusted percentage of 37.5% we search the min-bid setting below which 37.5% of proposed blocks have fallen (basically the 37.5th quantile), which is 0.04 ETH.
The complete table for 30% looks like this:

Value 691.96 ETH was the highest ever recorded MEV reward until the time of writing, and practically means that all blocks with a lower bid will be produced locally. For the full table, please go to the ‘Min-bid values’ tab in this spreadsheet.

Step 2. Vanilla block percentages by min-bid values
Next, we solve the opposite task, predefine various possible min-bid values and find which share of vanilla blocks they result in, depending on the amount of NOs who opt-in. From the previous step, we learned that most of the relevant min-bid settings lie in the range of 0.03 to 0.2 ETH, therefore the chosen values for min-bid are [0.01,0.02,0.03,0.04,0.05,0.06,0.07,0.08,0.09,0.1,0.12,0.14,0.16,0.2].

We then rank the initial dataset and look for the share of blocks which lies below each min-bid setting, and as a result, get the following table (this is an example of min-bid 0.06, the full table can be found on the ‘APR decrease’ tab of this spreadsheet):

Step 3. APR decrease
The third step is to calculate how the APR is affected by changes to the min-bid setting. For this, we determine the average rewards for relayed and non-relayed blocks since the merge, which are 0.13 and 0.015 ETH, respectively. We subsequently solve for the expected value of a proposed block by using the shares of vanilla and relayed blocks. For example, if we produce 33.8% vanilla blocks, the expected value is:

0.338 * 0.015 + (1 - 0.338) * 0.13 = 0.09 \; \text {ETH per proposed block}

We then divide this value by the average reward per relayed block, to find the ratio of the reward we would earn compared to a relayed block:

\dfrac{0.09}{0.13} = 0.7 \; \text{or 70%}

Therefore, the expected value per block with a min-bid setting of 0.06 and 60% of opt-ins is 70% of the expected value per block if we would only produce relayed blocks. In other words, we would lose 30% of the expected value of each proposed block under these conditions.

Furthermore, we need to find the share of EL rewards in the total structure of Lido earnings, depending on different combinations of min-bid values and NO opt-ins. For doing so, we take the 30-days averages of the CL and EL APRs. For example, under the above mentioned conditions and for the last month of data, the average CL and EL APRs equaled 2.86% and 0.78% respectively:

2.86\% + 0.78\% * 70\% = 3.41\%

By knowing this value we can finally determine the APR decrease suffered from configuring min-bid by subtracting the result from the current 30-days average APR of 3.64%:

3.64\% - 3.41\% = 0.23\%

The outlined approach is based on several strong assumptions:

  1. To achieve the highest possible APR, it is assumed that no NO is opt-in to min-bid. This is an inaccurate representation, since currently between 13.5% and 16.2% of NOs seem to have min-bid configured. Therefore, the real decrease of APR would be lower than calculated.

  2. The expected values are based on averages, but in reality the EL rewards for proposed blocks could be higher than the configured min-bid value for most of the blocks and therefore the overall rewards decrease would again be lower than determined.

  3. Since 30-days averages are taken, if the market conditions change, the real results could deviate to either side.

Taking into account these assumptions, we suggest that the numbers presented should be considered as maximal possible rather than expected decrease of APR.

PS: Edited to fix equation formatting & an incorrectly referenced value


The right scale to select a target point on for min bid is not “% of vanilla built blocks”, but “effect of Ethereum soft censorability”, e.g. the median or average delay for censorable transactions. If reducing stakers APR by 0.1 percent point gets us no significant improvement for Ethereum censorability (e.g. reduces median from 13 seconds to 12 seconds) it might be not worth it.


This does not seem like the correct metric to me for what you are attempting to measure. For example, the 691.96 ETH payload would skew the average reward for relay blocks up, but there is no way that it would be excluded by a min bid.

A more useful metric may be the difference between the locally-built block and the best block provided by the relay for a given slot. Unfortunately this information is not available retrospectively, but it should be possible to obtain this for a range of slots by asking an execution client to build payloads for each slot over a given period and compare that value to the best bid across all relays at a given time in the slot (either the beginning of the slot if you want to be idealistic, or 1s into the slot if you want to be more realistic).


The default CLsVCs use now for the proposer boost is to take MEV when it’s 10% above local. We haven’t adjusted the default.

Doesn’t that already give us the properties of min bid, without imposing an artificial threshold?

We have seen a higher percentage of locally built blocks since proposer boost went in.


Thank you for your comment and the chance to state that the planned updates to the block proposer rewards and other policies provided as guidance and to ensure equally fair treatment of all NOs of course are always intended to continuously challenge and meaningfully improve current methods for the benefit of the health of the Ethereum and Lido protocols, and not to idealistically hold on to antiquated approaches or to showcase pointless action.

In this regard, I find your proposed change of perspective away from the vanilla block rate - which rightfully can be considered somewhat meaningless in measuring the achievement of acceptable censorship resistance - to the practically more relevant delay of censurable transaction inclusion very interesting.

I wonder if you and/or the NOs already have a specific absolut delay or relative reduction in mind that you’d like to see in Ethereum to consider the network free and Lido’s contribution to be positively significant to this goal?

Also, I would like to point out that we - Greg as a contributor to the Analytics stream and I to NOM - can’t confidently estimate how time-consuming the prep work for gathering and processing the data would be that such a change in approach would entail and that we, out of respect for the other contributors, do not want to lightheartedly impose additional work on them. Perhaps @mikgur, thanks to his experience from Neutrality Watch, could help with an assessment?

Ultimately, to plan the resources and also in relation to a timely update of the BPR policy, it would be helpful to understand how highly the DAO stakeholders currently prioritize a specification of min-bid and/or an improved methodology for measuring the impact of Lido on Ethereum on the network’s censorship resistance, given Lido’s censorship resistance index already is above-average of other staking pools?

Hello @jgm, you are right that the methodology of our post has weaknesses. Even if our contribution never intended to provide absolutely reliable numbers but rather to serve as an impulse for discussion and - given the generosity with which we made assumptions - at most as an approximate decision-making aid, there certainly is a degree of simplification beyond which the added value of a measure should be critically questioned. Apologies! However, I would like to explicitly take Greg off the hook here, as he carried out the calculations I asked for but did not conceive the approach.

Is there a way in which we could process the existing data differently to reduce the inaccuracy and thus provide you and others with a more insightful decision-making support?

Furthermore, I also find your suggestion very promising. Just as in my response to @vsh , I have to point out though, that I am not an expert in tooling and would first need to learn more about data procurement required to give an estimation when we could be able to implement infrastructure to record the historic differences in value gathered between locally built and relayed blocks on a per-slot basis.

Finally, what is your opinion on @vsh and @yorickdowne’s ideas?


Hi @yorickdowne, thanks for pointing out proposer boost as a potential simple and practical solution.

I would love to hear if other NOs also have the default setting configured or if they are modifying it and also whether they have any insights into their proposer boost setups that they would kindly share with us?

1 Like

Let’s have a call and I’ll share my experience and maybe we come up with the estimation, it looks like a very different task to me though. I’ll schedule a call.