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!