Lido on Ethereum Block Proposer Rewards Policy 2.0 and Relay Maintenance Committee

Following the draft policy updates extensively discussed on the forums, a proposed v2.0 of the Block Proposer Rewards Policy has been uploaded to IPFS.

If you think Lido DAO should update the existing policy and enact the updated version, vote For. If you are against this proposal, vote Against.

Below is a summary of changes to the policy included in the v2.0 proposal:

• Set expectation of full-scale rollout of “PBS lite” via MEV Boost for all Node Operators going forward
• Define responsibilities of Node Operators in the case of Relay misbehavior, failure, or otherwise unexpected or non-performant functionality (e.g. what happens if relays provide bad bids, bad blocks, don’t unblind timely, etc).
• Define the responsibilities of Relay Operators towards the Lido Protocol and Node Operators

Additionally, by voting For, the below is also ratified:

• Propose to empower the Relay Maintenance Committee to facilitate the maintenance of the Lido vetted relay lists.
  • The Relay Maintenance committee will be a 5/7 Gnosis Safe multisig and have the address https://gnosis-safe.io/app/eth:0x98be4a407Bff0c125e25fBE9Eb1165504349c37d
  • The initial members of the multisig, as per the post linked above, will be:
    • PhilKnows eth:0x0ef5c6Ab0C44b2b042606215530437809eFE54c8
    • Elias eth:0x4981A4775983e947b12d0982021BeA8697175f4A
    • Michael Sproul eth:0x6B29132ea388a308578c1d3Be068D0e4fc9915a2
    • Izzy eth:0x783EA934d543CD1ccfd920639A7539a0BD3895e2
    • Sisyphos eth:0x8C5f9c67028fAaE0Db258D44507BdfBD7A9de223
    • George eth:0x912e21CdA3D7012146da4Df33309d860a9eb0bEb
    • YorickDowne eth:0xeCbb058Fc429941124a2b8d0984354c3132F536f
  • The Relay Maintenance Committee will be made the manager of the MEV Boost Relay Allowed List smart contract (0xF95f069F9AD107938F6ba802a3da87892298610E) (this will occur via an on-chain Aragon vote if this proposal passes)

Below are excerpts of the sections of the policy with substantial changes.

---

D.4.II Monitoring & Penalties Specification

Lido should monitor, record, and assess non-compliance with this policy. Monitoring and follow-up actions should include at least the following:

• Assessing whether the correct fee recipient has been configured by the Node Operators for the validators that they operate
• Assessing from which source proposed blocks by the validators have been received (and if that source is appropriate)
• Assessing the general availability of the allowed sources for block bids around the time of each block being proposed
• Assessing, in cases where blocks were not constructed via chosen MEV infrastructure, if this was due to a min-bid-like setting and whether the value of the min-bid used in these cases conforms to the expectations set by the Policy
• Assessing, in cases where blocks were not constructed via chosen MEV infrastructure, whether the block proposed contained transactions not available in the public mempool
• Recording, on a per-block basis, the most valuable known block bids offered via accepted MEV infrastructure (and block bid sources, e.g. relays), i.e. the reference block
• Recording, on a per-block basis, the blocks actually produced by the validators and their total value, i.e. the actual block
• Analyzing, on a per-block basis and historically, the difference between the reference block and the actual block for each Node Operator participating in Lido, having also properly taken into account the effect that min-bid usage would have on such a difference

Some leeway should be given to Node Operators for potential network problems, faulty relays, min-bid usage, or buggy software outside their control. It should be enough for the Lido DAO to punish gross misbehavior when a Node Operator is deviating more than ALLOWED_VALUE_DEV% from the reference block, on a frequency basis more than ALLOWED_FREQ_DEV% of the time over a rolling time window DEV_WINDOW. These parameters can be reviewed and tweaked via governance, if needed.

—

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: 2022/11/1 - 2023/6/30

(Unless otherwise overriden by a superceding DAO vote)

Summary: 2022/Q4 - 2023/Q2 MEV-Boost Full-scale Adoption - Phase 1

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

Following the Merge, Node Operators were requested to roll out and use MEV-Boost for validators that they operate as a part of the Lido protocol via a soft-rollout approach. They were asked to use as many of the relays which had signaled interest for inclusion as possible in order to test the efficacy and performance of the relays. Following the soft-rollout period and going forward, Node Operators are expected to adhere to the following:

1. The DAO will hold a Snapshot vote to:
   • determine which MEV-Boost relays will be added to the initial “must-include list” and “allow list” (“relay lists”)
   • for ease of governance operations given the number of new relays being created and the need for haste in certain scenarios, identify and approve a set of multi-sig participants who will manage the relay lists (the “Relay Maintenance Committee (RMC)”) for the duration of Phase 1, or until the management of the relay lists can be moved to Lido Easy Track
   • delegate authority to the RMC to make decisions about which relays are added to or moved between the “relay lists”, provided that RMC decisions are posted publicly on the Lido research forums prior to any on-chain actions being taken and giving the DAO and community a reasonable amount of time to consider. The DAO retains the right to a final decision and community members may post a Snapshot vote to change or counteract RMC decisions and/or reconstitute the RMC with different participants.
2. Validators operated by Node Operators participating in the Lido protocol shall be configured to produce blocks via the MEV-Boost infrastructure (or equivalent, such as Vouch’s MEV-Service) as detailed in Appendix A.1, by obtaining sealed blocks from the maximum possible number of relays from Lido’s “must-include list” (those used will be determined by each Node Operator based on their own risk and legal assessment) and an optional number of relays from the “allow list”. NOTE: the use of “must” here is effectively “must use some”, not “must use all”. The purpose is to promote relay diversity (and thus builder diversity). Node Operators may elect to not use all the relays from the “must-include list”, but the entirety of that list is used as a basis for the formation of the reference block as described in Monitoring & Penalties.
3. In Phase 1, Node Operators may also opt-in to configure a min-bid value in MEV-Boost ranging from 0 (default) to a preliminary upper maximum to be determined based on community alignment and agreement and published on the Lido Research Forums (min-bid discussion thread). The effects of usage of min-bid shall be incorporated into the allowable deviation parameters discussed in Monitoring & Penalties, such that only egregious and/or non-community aligned (including but not limited to values and usage that would be substantially detrimental to protocol APR) values of min-bid would result in a Node Operator being penalized. The effects of min-bid implementation will be analyzed and shared with the DAO during Phase 1 to determine and codify a more specific policy.
4. If using MEV-boost infrastructure leads to any operational failures/difficulties (such as, but not limited to: failing to produce valid blocks, failing to produce blocks at all, received rewards being incorrect, or lack of availability of appropriate relays), the Node Operator shall refer to and act as per the guidelines in A.1.IV Block Production & Relay Troubleshooting.
5. Blocks produced by the validators will be monitored as per Monitoring & Penalties section and the monitoring section of the relevant Appendices. If as at the time of the start of the applicability period the “MEV Monitoring & Penalty parameters” have not yet been defined, a grace period will be instituted until such a time that the parameters are defined and ratified by the DAO, at which point this policy will be updated.
6. 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 Phase 1 of the Full-Scale Adoption period, or as soon as possible thereafter, 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 next phase policy;
• stipulate or amend the values for the MEV Monitoring & Penalty parameters; and
• indicate any updates or refinements to be put in place regarding Monitoring Mechanisms.

—

A.1.IV Block Production & Relay Troubleshooting

In the case that operational issues are noticed (e.g. blocks not produced as expected, blocks not being timely unblinded, blocks not being timely created and propagated, blocks being invalid are invalid, relays not providing agreed upon data or monitoring APIs, etc.) the Node Operator should temporarily disable the relevant relay(s) until such a time that:

• (a) service is sufficiently and satisfactorily restored, or
• (b) the DAO and Node Operators collectively decide that the relay(s) should no longer be used and removed from the relevant vetted lists, at which point a DAO vote should be made to do so.

In these cases, the Node Operator should also:

• timely inform the rest of the Lido Node Operator community about the issues identified,
• reach out to the Lido Node Operator Management contributors to notify them of the issues, and
• reach out to the relay operator to understand the source of the issue and report back

If a Node Operator is found to be "under-performing" as per the mechanism described in D.4 Monitoring & Penalties but this is due to issues stemming from a bad relay or malicious builders interfering with block production, then the Operator will not considered out of compliance with the policy.

A.1.V Relay & Relay Operator Responsibilities and Incident Management

Given the trusted nature of relays in the MEV-Boost context, it behooves Relay Operators to ensure that they and the relays that they operate function effectively, performantly, and efficiently, and that any and all communications are made timely and professionally.

Relay Operators should notify relevant Lido protocol participants (e.g. Node Operators, the Node Operator Management Workstream) as soon as possible upon identification of an issue with any of the relays that they operate. Notification may be performed through public (Lido forum, Lido discord, etc.) and/or private channels (e.g. group chats) available to them, so that Node Operators can proceed with appropriate changes to their MEV-Boost configurations.

During an incident, Relay Operators should provide regular updates with regards to the status of the incident. Following the conclusion of the incident, Relay Operators should provide an incident report (or post-mortem) that details at minimum the root cause, fixes performed, if/how soon the relay will be back in service, and what steps have been undertaken to prevent the likelihood of similar incidents in the future. Additionally, in cases where block production was adversely affected (see A.1.IV Block Production & Relay Troubleshooting), Relay Operators should advise as to what steps will be taken (if any) to reimburse validators for any missed/lost/invalid/etc. blocks and/or incorrect/invalid/inaccurate bids.

Incidents will be reviewed on an ad-hoc basis by the Node Operator and Lido DAO communities. These reviews will inform DAO decisions (via vote) regarding whether Relay Operators and the relays that they operate will continue to be considered vetted and ratified for use by Node Operators or not.

Relays which exhibit poor or otherwise unacceptable communication and especially performance (such as, but not limited to, inability to performantly and timely register validators, inability to performantly and timely send/receive bids and payloads, not verify bids, not simulate payload validity etc.), and/or fail to conform with the expectations outlined above with regards to incident management (as determined by the DAO and Node Operator communities) will be subject to removal from the Lido-approved relay lists.