KVORUM
lidoSource: Snapshot · #0x3b1e5f9960e682abdc25c86624ad13acb88ee1cea18db9be99379b44750c7b36

Lido on Ethereum Block Proposer Rewards Policy v1.0

succeededSep 15, 2022, 04:00 PM UTCsignaling · non-bindingbyDB0xdbbc…1cb6View on Snapshot ↗

01Summary

AISummary by Kvorum

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

02Description

882 words

Following the draft policy posted on the forums, a proposed v 1.0 of the Block Proposer Rewards Policy has been uploaded to IPFS.

If you think Lido should enact this policy and Node Operators running validators for the Lido protocol should begin a soft rollout of out-of-protocol Proposer Builder Separation as described in linked policy, vote For. If you are against this proposal, vote Against.

Below are excerpts of certain sections from the linked policy for summary purposes.


A. Overview

As a DAO and a protocol, Lido on Ethereum should have a transparent, enforceable, and monitorable policy with regards to how its constituent Node Operators are expected to behave with regards to rewards that accrue from the activity of producing blocks for validators that they run as a part of Lido, namely priority fees and MEV extraction, and how the protocol will distribute the rewards that accrue to the protocol as a result of these activities.

B. Purpose

This policy aims to outline how Node Operators participating in Lido should distribute rewards obtained due to block production (including potential MEV rewards), what mechanisms or infrastructure may be used in execution of this, how rewards will be distributed, and how these activities will be monitored.

C. Scope

This policy applies to the Lido on Ethereum protocol, the Node Operators that participate in the protocol, and the validators that they operate as a part of the protocol.

D. Policy Statement

D.1 General goals

There are two key questions that this policy addresses:

  • How should validators run by Node Operators propose blocks? and
  • How should validators run by Node Operators distribute the rewards that result from block proposals?

Since the consensus within the Ethereum community is to move towards a PBS system where the building of blocks is separated from the proposal of blocks, Lido should seek to adopt an approach as close to a most likely draft of PBS as possible. Lido could become a testbed for this feature which is easier to roll back than a full-fledged implementation if something goes wrong.

On the rewards side, validators are powered by deposits from stakers, and thus stakers should always receive the lion’s share of rewards.

To that end, Lido as a protocol should:

  • Enforce - to the technical extent possible - that blocks are not built by Node Operators, but instead built by third parties and obtained from open and transparent builder markets.
  • Require that Node Operators ensure that relevant rewards are routed to the Lido Execution Layer Rewards vault which, as per LIP-12, will periodically be triggered to stake the rewards (less the Lido protocol fees), thereby essentially increasing staker rewards.
  • Ensure, to the extent possible, that proposed blocks are valid and do not damage the proper and sustainable operation of the underlying protocol.
  • Monitor Node Operator behavior (monitoring will be publicly available) and penalize Node Operators who are found to not be in accordance with the above stated goals.

D.5 Currently prescribed solution(s)

This section will be reviewed by the DAO and updated on an at-least yearly basis and more often if needed. It details which block production solutions may be used by Node Operators at the current time.

Applicability period: Merge date - 2022/10/31 (Unless otherwise overriden by a more recent DAO vote)

Summary: Post-Merge soft-rollout of MEV-Boost

Lido should aid Ethereum in moving towards its stated goal, PBS.

From any time following the Merge (slated to occur between 10-20th of September), Node Operators have roughly six weeks (until the end of October 2022) to test and implement MEV-Boost such that blocks produced are sourced from DAO-vetted relays (see LIP-17 for details about where the vetted relay information will be stored and how they may be retrieved by Node Operators). This period constitutes a soft-rollout so that Node Operators may properly test and configure their infrastructure prior to the policy being fully in effect.

The below summarizes the prescribed solution to work towards within the soft-rollout period:

  • Validators operated by Node Operators participating in the Lido protocol should produce blocks via the MEV-Boost infrastructure as detailed in Appendix A.1, by obtaining sealed blocks from the maximum possible number of relays (to be determined by each Node Operator based on their own risk and legal assessment) from Lido’s “must-include list” and an optional number of relays from the “allow list”.
  • If using MEV-boost infrastructure leads to any operational failures/difficulties (e.g. failing to produce valid blocks, blocks at all, received rewards being incorrect, or lack of availability of appropriate relays), the Node Operator may fall back to building blocks via the “Default” block-building method.
  • Blocks produced by the validators will be monitored as per Monitoring & Penalties section and the monitoring section of the relevant Appendices.
  • Node Operators acting in violation of the policy are subject to penalties as described in the Monitoring & Penalties section.

Prior to the end of the soft-rollout period, the DAO will review and update (via a vote) this policy, in order to:

  • re-confirm or amend the prescribed solution if deemed necessary and set the - new applicability period for the policy;
  • stipulate the values for the MEV Monitoring & Penalty parameters; and
  • indicate the finalized Monitoring Mechanisms.

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

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total
Filter:
VoterChoice% of totalRationale
B80xb842…82b0For00.00%—4y ago
E00xe017…4e63For00.00%—4y ago
CC0xcc18…2575For00.00%—4y ago
AE0xae09…256bFor00.00%—4y ago
960x9648…ea04For00.00%—4y ago
110x1109…43daFor00.00%—4y ago
950x9535…d5c7For00.00%—4y ago
5B0x5ba4…b1edFor00.00%—4y ago
620x624d…2cd0For00.00%—4y ago
130x130f…97d5For00.00%—4y ago
5C0x5c9e…452dFor00.00%—4y ago
880x8845…53f5For00.00%—4y ago
710x71c1…440bFor00.00%—4y ago
A50xa5d4…d792For00.00%—4y ago
3D0x3d5a…b97fFor00.00%—4y ago
140x1464…e535For00.00%—4y ago
CF0xcf2b…e05dFor00.00%—4y ago
550x55c5…7bccFor00.00%—4y ago
B40xb4dc…7e9aFor00.00%—4y ago
D90xd929…b62cFor00.00%—4y ago
FC0xfc83…7642For00.00%—4y ago
910x9109…43a3For00.00%—4y ago
120x12ba…e357For00.00%—4y ago
470x471a…d6b7For00.00%—4y ago
470x4796…22f2For00.00%—4y ago
A60xa647…a9b8For00.00%—4y ago
390x3986…eb4eFor00.00%—4y ago
D90xd9c1…f7deFor00.00%—4y ago
F00xf077…7d3aFor00.00%—4y ago
6C0x6cc1…9415For00.00%—4y ago
000x0044…0fbcFor00.00%—4y ago
710x71e2…0d9aFor00.00%—4y ago
CE0xce8e…4e14For00.00%—4y ago
9E0x9ed2…1a04For00.00%—4y ago
D00xd0ac…03c7For00.00%—4y ago
F00xf05e…2969For00.00%—4y ago
DD0xdd45…fb09For00.00%—4y ago
6E0x6e0f…b040For00.00%—4y ago
540x543b…167eFor00.00%—4y ago
CF0xcf08…f42fFor00.00%—4y ago
9A0x9adf…493cFor00.00%—4y ago
DA0xda94…4951For00.00%—4y ago
140x14fd…14c6For00.00%—4y ago
9F0x9f65…40f5For00.00%—4y ago
710x710a…88e2For00.00%—4y ago
D30xd31a…1072For00.00%—4y ago
130x1371…c28eFor00.00%—4y ago
8D0x8d4f…e608For00.00%—4y ago
FE0xfe25…b0bbFor00.00%—4y ago
070x072c…c701For00.00%—4y ago
Showing 50

07Forum

No forum thread is confidently linked to this proposal.

08Similar proposals

AI · embeddings

No semantically similar proposals found yet.