KVORUM
lidoSource: Snapshot · #0x8b6addc4be1a9ef4b2a1591be5ac4909aa82c868cd9b7871494b626539a99a8e

Proposal for Updating Block Proposer Rewards Policy to Lido on Ethereum SNOP on Block Proposals v3

succeededJun 30, 2025, 04:00 PM UTCsignaling · non-bindingbyDB0xdbbc…1cb6View on Snapshot ↗

01Summary

AISummary by Kvorum

An AI summary is not generated yet. Read the description →

02Description

707 words

Summary

This proposal seeks the community’s support to update the currently in effect Block Proposer Rewards Policy v2 (approved by the Snapshot vote) to the proposed Standard Node Operator Protocol (SNOP) on block proposals v3 (diff-view).

Context & Motivation

The current version of the Block Proposer Rewards Policy dates back to when Ethereum’s block proposal pipeline was less complex, Lido protocol was still monolithic, and out-of-protocol proposer-builder separation in the form of MEV-Boost had not yet been fully rolled out to the protocol.

Given the advancements since then — Pectra and Staking Router 2.0, the upcoming Lido v3 and CSM v2 upgrades, as well as features like Auxiliary Proposer Mechanisms (APMs) and Triggerable Withdrawals — this proposal aims to ensure the SNOP accurately reflects the current state and lays the groundwork for the future development of the Lido protocol.

The SNOP on block proposals v3 builds on a detailed review of the Ethereum and Lido protocols, incorporates input from community members and contributors across multiple workstreams, and adopts the structure introduced in the recent revision of the SNOP on validator exits (approved by the Snapshot vote) for consistency and clarity.

Overview of Changes & Additions

The main changes and additions include:

  • Adoption of a standardized structure
  • Extension of the scope to Node Operators (NOs) using Simple DVT, Community Staking, and/or any potential future staking module (SM) or avenue
  • Adaptation of the validator definition to the Pectra changes to MAX_EFFECTIVE_BALANCE
  • Introduction of the concept of APMs and their utilization in Lido protocol — i.a., via a framework, committee, the proposed SNOP, and an accompanying allowed list
  • Summary of the considerations around economic security, decentralization & operational diversity, and censorship resistance that guide stakers’ thinking of Ethereum, the Lido protocol, and APMs
  • Listing of the responsibilities with respect to proposer activity and distribution of associated rewards that arise for NOs using the Lido protocol from the guiding considerations
  • Breakdown of the per-SM consequences to be expected in case of an NO’s non-conformance with the responsibilities
  • Addition of an appendix complementing APM knowledge with information on the standards and infrastructure relevant to block proposals in Ethereum

NO Responsibilities

The key responsibilities arising for NOs using the Lido protocol with respect to block proposals are as follows:

  • Set the fee recipient to the Lido Execution Layer Rewards Vault for the relevant Ethereum network
  • Utilize only APMs that have been vetted by the community and are included in the APMs Allowed List
  • Adhere to the operational best practices of operational effectiveness, fair rewards distribution, and responsible APM usage
  • Utilize out-of-protocol PBS and configure at least one vetted relay of the MEV Boost Relay Allowed List for the relevant Ethereum network labeled as "must use some"
  • In case a builder and/or vetted relay experiences operational issues, report the issue to the wider NO community and disable the affected relay(s) until service has been restored
  • Configure proposal parameters such that local building occurs only if the incremental value of externally-sourced payloads is relatively low as defined by social consensus among NOs, DAO contributors, and the wider staking community in the Lido Node Operator MEV Boost min-bid guidance thread

Official References

The full text of the proposed SNOP on block proposals v3 is available through the following sources:

  • IPFS - primary reference, will serve as the single source of truth if the proposal is approved
  • HackMD - available for collaborative reading and discussion
  • GitHub - provided for easier access and readability (the text will be available in this directory after this Snapshot vote concludes and is approved)

Vote Outcomes

If the "For" option wins, the proposed Standard Node Operator Protocol (SNOP) on block proposals v3 will be supported and used as the main reference for NO interactions with Lido protocol with regards to configuration around the block proposal pipeline from the moment of the conclusion of the vote onwards.

If the "Against" option wins, the Block Proposer Rewards Policy v2 remains in effect, a revised draft of the Standard Node Operator Protocol (SNOP) on block proposals v3 will be prepared based on community feedback, and a second round of voting may follow.

03Mismatch analysis

AIMismatch analysis by Kvorum

A calldata-vs-description analysis is not generated yet. Review the decoded actions →

04Actions

0 total

This proposal carries no on-chain actions.

05Tally

Summed from votes

Voters93
VP participating0
Outcome (current)For
Current support100%

06Voters

93 total
Filter:
VoterChoice% of totalRationale
4A0x4af8…6a0bFor022.47%—1y ago
420x42e6…3fb0For017.65%—1y ago
810x8172…922eFor09.29%—1y ago
6D0x6d8d…0cccFor07.31%—1y ago
LIlido.banteg.eth0x55bc…f0faFor06.13%—1y ago
9C0x9ca8…36afFor05.54%—1y ago
510x510a…8d0eFor05.33%—1y ago
B90xb933…8dd1For04.35%—1y ago
A40xa418…b737For04.10%—1y ago
110x1109…43daFor03.60%—1y ago
3F0x3fb1…4c8aFor02.95%—1y ago
B60xb664…f890For02.37%—1y ago
6F0x6f9b…8a1dFor02.14%—1y ago
1F0x1f76…5ed6For01.71%—1y ago
7A0x7a59…8e22For01.28%—1y ago
390x3983…777aFor01.23%—1y ago
870x8787…ea52For00.67%—1y ago
E80xe80e…28e8For00.56%—1y ago
2C0x2cc1…4df1For00.50%—1y ago
620x624d…2cd0For00.25%—1y ago
3D0x3ddc…05b0For00.14%—1y ago
980x9830…bd94For00.14%—1y ago
060x06a9…bba0For00.14%—1y ago
3D0x3d63…4afcFor00.11%—1y ago
8A0x8ab6…e0baFor00.03%—1y ago
7A0x7af3…8df3For00.00%—1y ago
C50xc554…7759For00.00%—1y ago
270x27d3…f70aFor00.00%—1y ago
3D0x3d5a…b97fFor00.00%—1y ago
C60xc634…3c18For00.00%—1y ago
B10xb1f8…4250For00.00%—1y ago
B70xb792…89d7For00.00%—1y ago
EC0xecc2…6ac9For00.00%—1y ago
C10xc1c2…24f8For00.00%—1y ago
530x53c4…3584For00.00%—1y ago
C40xc48b…75b6For00.00%—1y ago
500x500f…7d0bFor00.00%—1y ago
270x2748…ac26For00.00%—1y ago
9D0x9d57…65a5For00.00%—1y ago
050x0579…ca09For00.00%—1y ago
2F0x2f2f…f78aFor00.00%—1y ago
B30xb3bf…6ce4For00.00%—1y ago
1B0x1b9d…61ddFor00.00%—1y ago
CE0xce57…70f0For00.00%—1y ago
FD0xfdab…2b62For00.00%—1y ago
650x659f…dadcFor00.00%—1y ago
BB0xbb02…2f78For00.00%—1y ago
C90xc973…9457For00.00%—1y ago
BF0xbfd1…4f66For00.00%—1y ago
AF0xaf90…7b3bFor00.00%—1y ago
Showing 50

07Forum

No forum thread is confidently linked to this proposal.

08Similar proposals

AI · embeddings

No semantically similar proposals found yet.