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
11 Likes

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!

3 Likes

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%.

3 Likes

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.

2 Likes

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.

2 Likes

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.

Questions
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

6 Likes

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.

2 Likes

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).

2 Likes

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.

2 Likes

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?

Thanks!

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.

2 Likes

We appreciate the valuable discussions so far. We believe we should consider min-bid’s impact not only on decentralization but also on base-fee volatility, and thus we should spend more time studying on understanding the influence of each parameter properly.

Here are the three key points:

  1. The relationship between min-bid and Lido’s censorship resistance is unclear. While having more vanilla blocks may result in avoiding building blocks with OFAC-compliant relays and thus can enhance censorship resistance, we need to investigate its correlation with practical metrics like Average Censorship Latency(as suggested by @vsh).

  2. Vanilla blocks may increase base-fee volatility, creating a potential trade-off between decentralization and the economic efficiency for the end users.
    This is described in the recent presentation by Matt Cutler of Blocknative.

In a nutshell, what is said here is as follows;

  • There is an increasing amount of private transactions, which affects the gas price market.
  • Self-built blocks don’t contain private transactions as they don’t have access to private mempools.
  • Self-built blocks usually have much less gas used, in comparison with MEV-boosted blocks, due to the fact that they don’t contain private transactions.
  • After self-built blocks, there usually are recovery blocks that include a higher amount of private transactions than normal MEV-boosted transactions. This is because there is high pressure from private mempools on recovery blocks, and this results in a higher amount of gas used.

This is how base-fee volatility is increased with vanilla blocks.
There should be a lot to be studied before making a concrete understanding, and what we’d love to say here is that we should be careful about increasing the number of vanilla blocks produced as it might worsen the situation for users.

  1. If we prefer to do something to enhance Lido’s censorship resistance in a short time frame, reducing the rate of OFAC-compliant relays might be an option. This could be done by adjusting the policy on relays that can be found at “A.1.II Relays” on this page.

As we understand, the ultimate goal of this discussion is to keep Lido censorship-resistant, while improving economic efficiency. This problem can be reframed into “lowering the rate of OFAC-compliant relays while keep improving economic efficiency.”
However, this is not desirable for two reasons,

  1. As far as we know, we do not have a strong urge to rush on improving Lido’s censorship resistance.
  2. Allow/blocklisting (OFAC-compliant relays, in this case) is not a cool solution in general, especially when we are talking about censorship resistance.

We would love to continue to discuss this matter and contribute to the better approach to make Lido be more censorship resistant!

2 Likes

Dear Lido community,

In 2024 – largely due the criticism of the methodology used – no proposal was made to change the upper min-bid limit permitted to be configured by NOs using Lido. This year, @Aleksandr_V, @Mol_Eliza and I revisited the topic with a fresh perspective shaped by the feedback you provided.

One evolution in our thinking is that the threshold should probably no longer be defined in the Block Proposer Rewards Policy (BPRP). Instead, we suggest that going forward it should reside in the APMs Allowed List proposed alongside the rework of the BPRP, where – subject to the social consensus in this thread, but not requiring a full Snapshot process – it could be adjusted more flexibly to reflect prevailing conditions when needed.

In light of this, rather than proposing a new min-bid outright, we would like to open a discussion. We believe that a more regular and interactive collaboration with the community is the best way to ensure that any adjustment properly reflects the evolving network dynamics as well as the collective knowledge and interests of all stakeholders.

Below you find a TLDR of key take-aways, the detailed considerations and conclusion of our thinking.

TLDR

  • Interested in resuming the operation of NeutralityWatch and/or having ideas that could help solve the challenges described below? Please join the discussion!
  • For NOs using Lido, the following actions are proposed for now:
    • Keep min-bid as opt-in mechanism to support Ethereum’s censorship resistance
    • Stick with 0.07 ETH upper min-bid limit & adjust via social consensus if needed
    • Set boost factors weighting between externally-sourced and locally-built payloads to 1:1

Considerations

Assumptions

The assumptions made prior to the full-scale roll-out of MEV-Boost in Lido to determine an upper min-bid limit that would balance the protocol’s economic competitiveness with Ethereum’s security and censorship resistance have proven to be unrepresentative of the actual conditions observed after broader adoption of PBS and years of network maturation.

Several factors contributed to this:

  • More NOs than initially anticipated do not construct payloads locally. In many cases, this is due to what it takes NOs to configure their setups in accordance with their understanding of what is necessary to be compliant and participate in proposer activity.
  • The spontaneous and local configurability of min-bid makes it difficult for contributors to attribute on-chain detectable behavior to NO-driven interventions, transient issues, or other secondary effects with high degree of certainty.
  • Gas prices – and by extension, builder bid levels – have fluctuated significantly over time and will continue to do so, rendering any static analysis potentially obsolete or misaligned with prevailing conditions.

Impact

Maintaining parameters rooted in outdated assumptions during last year’s threshold revision was justifiably criticized. Instead, a call was made to better align the intended impact of the effort with the practical consequences users face – specifically, the delay in transaction inclusion. Unfortunately, determining what level of inclusion delay is acceptable to users (and what opportunity cost Lido can feasibly bear to reduce it) is not trivial to answer. The issue is further complicated by the recent discontinuation of one of the most valuable resources on the matter: NeutralityWatch. Sadly, the NW team could no longer sustain the initiative on a avocational basis, leading to its shutdown. We would like to take this opportunity to thank them again for their excellent contribution.

Rewards Calculations

A third point of contention concerned the calculation of average rewards for blocks proposed with either externally-sourced or locally-built payloads. Its results may have been misleading due to the approach taken, which failed to adequately account for the disproportionate influence of high bids. To improve upon this, a more refined method was considered, relying on more granular data sourced directly from relays and execution clients that construct payloads locally on a per-slot basis.

However, as Lido functions as middleware, it is NOs – not DAO contributors – who run the validators for the protocol. While contributors are free to join the permissionless CSM, personal operations generally lack the scale and infrastructure of professional staking providers. Furthermore, since no data funnel optimized for varied home setups could be identified, any data collected under such conditions would not have been representative of the broader Lido validator set. As a result, instead an attempt was made to simulate local payload construction using a comprehensive package of mempool data kindly provided by Flashbots.

Unfortunately, that experiment was unsuccessful. Despite accounting for orphaned and empty blocks as well as missed slots, significant discrepancies between the simulated results and empirical data emerged that could not be credibly resolved through systematic processing. Two factors identified as contributing to this mismatch – though likely not the only ones – were the variability in bids receivable and transactions discoverable by nodes in different regions.

Nevertheless, the level of the “cost of min-bid” valuation under current conditions can be provided based on the observed difference between the rewards for locally built blocks and the rewards available from external payloads for the same slots.
Based on the data for the first four months of 2025, the present impact on the protocol in terms of APR is limited – with total missed rewards at 492.43 ETH and the effect on APR being 0.0157%.

The algorithm for this evaluation was:

  • Collect all bids provided by Flashbots’ Relayscan from start of January to end of April 2025

  • Evaluate the market value of the max bids available at half a second into the slot (t+0.5)

  • Collect the data on the blocks proposed by validators run for Lido based on Dune and MEV Monitoring

  • Evaluate the missed rewards for each block, based on the logic of:

    • Block was locally-built with rewards as rew_loc
    • Market value was <= 0.07 ETH at t+0.5
    • Missed rewards = max(0, market_value at “t+0.5” - rew_loc)

    Note: The merged data on slots, collected rewards and relay bids is available here

  • The result is the sum of all missed rewards during this period - 492.43 ETH

  • Compare the results with the total protocol rewards for the corresponding period

    • CL rewards: 86 790 ETH
    • EL rewards: 17 914 ETH

→ Missed rewards: 2.74% of EL or 0.47% of total rewards

Mechanisms

A fourth suggestion involved evaluating the recently introduced builder boost factor in the produceBlockV3 method of the Beacon Node APIs (note: in some consensus clients – such as Nimbus and Prysm – this parameter is instead implemented as the local block value boost). This mechanism allows for prioritizing locally-built over externally-sourced payloads based on their MEV value and could serve as an augmentation or potential replacement for the current min-bid approach. Unlike min-bid, which is configured as an absolute ETH value in the MEV-Boost validator sidecar, the boost factors are proportional parameters set within the consensus client. As a result, using a boost factor – either exclusively or in combination with min-bid – opens a significantly larger range of potentially allowable proposed block values compared to relying solely on min-bid.

Conclusion

Based on the considerations outlined, we believe that relying on a practically static min-bid definition – adjustable only through relatively slow governance cycles – is no longer appropriate. The proposed retention of the 0.07 ETH threshold is not a validation of its continued adequacy, but rather a provisional baseline for discussion, subject to adjustment via social consensus within this thread to better reflect prevailing conditions.

An important step in supporting Ethereum’s censorship resistance is developing a shared understanding of which metric is most suitable for measuring both its current state and the impact of different attempts at improving it. While transaction inclusion delay seems like the obvious choice, it is worth considering whether alternative metrics might prove more accurate or actionable. Once a metric is agreed upon, the community must also align on what levels are considered acceptable and which would indicate cause for concern. Assuming transaction inclusion delay is selected – and with NeutralityWatch no longer available – inclusion.watch may serve as a new reference point. Given the practical impossibility of achieving 100% inclusion probability in the first block after transaction propagation – which, with Ethereum’s current slot time, would correspond to a 12s inclusion delay – what realistic delay (or inclusion probability per block post propagation) should the community aim for? Importantly, remember that any benchmark must be balanced against the level of MEV missed Lido can sustainably tolerate while continuing to support Ethereum’s core values.

The limitations of the earlier method used to calculate execution layer rewards is acknowledged, and finding a better approach remains a key objective. Since the experiment, the accuracy of the analysis could be improved through the addition of an archive node and generally enhanced data availability. However, the geographic dependencies of data availability identified in the original setup remain relevant and continue to pose challenges to the credibility of results. One potential avenue for gaining better insights could be the development of a validator sidecar dedicated to collecting data on local payload construction. However, this approach raises questions such as which NOs would be willing to run it, how reliable and representative the collected data would be, and whether the undertaking would be justified – especially in light of the upcoming Fusaka hard fork and likely introduction of some form of in-protocol inclusion lists.
Alternatively, a broader coordination effort could be launched to engage more NOs in running Xatu Sentry, thereby contributing to EthPandaOps’ public good and producing a dataset hopefully more suitable for our analysis and modeling.

Finally, while the boost factors present intriguing alternatives to min-bid, they also add systemic complexity. Given our current inability to confidently determine realistic values for the payloads locally constructable and bids retrievable for nodes in different regions, let alone the lack of a common understanding of our benchmark, we believe it would be premature to introduce more mechanisms. Instead, to avoid incidents caused by the unconscious use of the boost factors’ default configurations in clients, it is proposed to proactively enforce the ratio of prioritization between externally-sourced and locally-built payloads to 1:1 (100% for some, 0% for others – depending on the implementation of the parameter) as defined in the APMs Allowed List.

Looking forward to your opinions!

2 Likes