Update Proposal: Lido on Ethereum Standard Node Operator Protocol - Validator Exits

Proposals
1

Dear Lido Node Operators,

I hope you are as hyped about the CSM mainnet launch as I am :slight_smile:

In addition to the start of CSM’s Early Adoption phase, enactment of on-chain vote 180 has also brought some changes under the hood of Lido on Ethereum. With this post I would like to present to you a proposal for a new version of the Standard Node Operator Protocol (SNOP) regarding Validator Exits.

Since the improvements of Staking Router 2.0 include some new concepts and individual approaches of the now three active Staking Modules (SMs), of which only the Curated Module existed at the time of the discussion and voting on the current version of the document, it feels like it is time to update the documentation on the underlying mechanisms and expectations towards Node Operators (NOs) who use Lido to run validators.

My intention was to give the document a logical structure that can be easily expanded, to coherently describe the key concepts and mechanisms around validator exits, both in Ethereum and specifically to Lido, to define NO expectations w.r.t. the usage of the protocol, and the possible consequences of non-conformance as per the rules of each SM.

The main changes include:

  • Refactoring of the structure in an attempt to create a template structure for all SNOPs, and re-organization of some ancillary content to appendices

  • Extension of the scope to NOs using the Simple DVT Module and/or Community Staking Module

  • Definition of the terminology specific to SDVTM and CSM

  • Introduction of the validator exit order of SR 2.0

  • Introduction of SM stake share limits and explanation of their effect on exit priority

  • Introduction of NO target limits and explanation of their effect on exit priority

  • Clearer description of mechanism through which an NO validator exit request status of delinquent can recover to an in good standing status

  • Clearer explanation, on a per-SM basis, of validator exit requirements and penalties for non-conformance as per the protocol code

The draft contains a wealth of knowledge from the original and input from various of my co-contributors, for which I would like to express my sincere gratitude.

Now I would like to ask the community for its feedback and suggestions to bring the SNOP to a state suitable for a Snapshot vote seeking token holder ratification.

The draft of the document can be found here:

A GitHub diff-view between V1 and the proposed V2 can be accessed here:

As suggested next steps, I propose a discussion and incorporation of ideas from this thread, the presentation of the draft during two Node Operator town hall calls with the possibility of direct exchange on November 22, one at 9 AM and one at 5 PM UTC, to accommodate NOs from all time zones, and the review of the final proposal by LDO token holders as part of the voting process.

Many thanks and I wish you all a fantastic week.

10 Likes
2

Thanks for the proposal! I think it is well-shaped and much needed for the recently released Community Staking Module.

3 Likes
3

Thx for the thorough proposal!

The proposed definition of delinquency, particularly the 96-hour (4-day) timeframe, applies uniformly to all NOs, whether they are CM, SDVT, or CSM NOs. However, I’m concerned this timeframe may not be as manageable for individual operators within the CSM. CM NOs are Pros, likely on standby 24/7, and SDVT NOs, if operating within a cluster, may be able to rely on multi-sig operations (if I understand correctly). CSM NOs, on the other hand, might not be able to respond as quickly—for example, if they are on vacation. I’m uncertain about what timeframe would be most suitable for them, though.

Part E - Action and Consequence table
While an NO has a status of delinquent, no operator rewards will accrue to the NO for the affected PO reporting frame(s), with all operator rewards accruing towards the stETH rebase(s) instead. The NO still receives rewards related to its bond rebase.

do you think we can label these NOs as underperforming NOs too and the operator rewards they accrue in the frames will be averaged to well-performing guys in CSM.

1 Like
4

I’m a CSM operator. I’m supportive of having same standards set on us so it’s more fair for everyone. 4 days is actually quite reasonable for us to exit a validator. Most of us are supposed to have vpn setup to access our nodes.

Anyway we don’t go on holidays. We live from Ethereum events to the next Ethereum event :crazy_face: I’m sure you can find us there or announce the exit events at the Devcon for example :crazy_face:

2 Likes
5

A Note: The content of a SNOP results from the current state of LoE and the SMs, not the other way around. While protocol parameters can be changed via governance, which would consequently be reflected in the corresponding SNOP, a SNOP is neither able nor intended to propose changes to Lido code.

Maybe @dgusakov can shed some light on why the NO delinquency threshold of CSM was proposed to match that of the CM and SDVTM?

6

The reason is simple. No matter how professional you are you should keep an eye on your nodes. CSM offers numerous ways to stay up-to-date with the exit requests - Subscribing to the important events | Lido Docs

2 Likes