Dear Lido community,
This post proposes v3 of the Lido on Ethereum Standard Node Operator Protocol (SNOP) on block proposals.
Its predecessor, the Lido on Ethereum Block Proposer Rewards Policy v2, dates back to when Ethereum’s block proposal pipeline was less complex, Lido 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. It therefore felt like the right time to upgrade the document to properly reflect the current state of the protocol with Pectra and Staking Router 2.0 in practice, as well as Lido v3 and the implementations of Auxiliary Proposer Mechanisms (APMs), Triggerable Withdrawals and CSM v2 on the horizon.
To come up with the following draft, we studied the Ethereum and Lido protocols, gathered feedback from a variety of co-contributors across different workstreams (thanks a ton to everyone who contributed!) and applied the same structure that may already be familiar from the revision of the SNOP on validator exits.
The main changes include:
- Adoption of standardized structure
- Extension of scope to Node Operators (NOs) using Simple DVT, Community Staking and/or any potential future staking module (SM) or avenue
- Adaptation of validator definition to Pectra changes in MAX_EFFECTIVE_BALANCE
- Introduction of concept of APMs and their utilization in Lido — i.a., via a framework, committee, the proposed SNOP and an accompanying allowed list
- Summary of considerations around economic security, decentralization & operational diversity, and censorship resistance that guide stakers’ thinking of Ethereum, Lido protocol and APMs
- Listing of responsibilities in respect to proposer activity and distribution of associated rewards that arise for NOs using the Lido protocol from the guiding considerations
- Breakdown of per-SM consequences to be expect in case of an NO’s non-conformance with the responsibilities
- Addition of appendix complementing APM knowledge with info on the standards and infrastructure relevant for block proposals in Ethereum
The draft is not final yet, and we kindly ask everyone to share their opinions and suggestions for improvement in this thread. If no objections are raised, the next step will be the Snapshot vote (presumably, on June 23).
One aspect that again proved challenging during the creation of the document was the quantification of the upper min-bid threshold permitted to be optionally configured by NOs using the Lido protocol to protect Ethereum’s censorship resistance. Based on this realization, the idea was born that — if necessary due to prevailing conditions — the value should be discussed in the Lido Node Operator MEV Boost min-bid guidance thread, adjusted by social consensus, and, instead of being set in the SNOP, be specified in the APMs Allowed List. Simply because the list can be more easily adjusted without requiring the full governance process. Therefore, please also take a look at my latest post there and feel free to suggest a value you deem appropriate for Lido today.
Finally, I would like to invite you to the two NO townhall calls happening Monday June 16, first at 9 AM and second at 5 PM UTC, where you will have the opportunity to directly discuss the proposal.