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.

11 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.

2 Likes
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:

4 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
7

Just a bump here as I realize the links for the townhalls weren’t shared. Here they are!

morning (9am UTC) and
afternoon (5PM UTC)

1 Like
8

On behalf of new solo stakers coming aboard via the CSM, I think we could consider a 7-day period to fulfil exit requests so that the period will always cover 1 weekend, creating a consistent commitment in their minds.

e.g., Reserving time every Sunday to perform exits when needed (commitment by default) vs Arbitrarily scheduling time for it (commitment by request)

There are 4 reasons for my suggestions:

  1. Many solo stakers are full time professionals and the nature of work nowadays doesn’t necessarily mean 9 - 5. Further, shift workers may be out of action for up to 4 days at a time, especially if they are offshore.

  2. Limited impact to the liquidity of stETH and protocol resilience given the current low share limit of CSM at 1%.

  3. It is unclear how many CSM operators are using the automatic validator ejector service at the moment. There will also be a learning curve for those attempting to exit manually for the first time.

  4. Overall, I want to avoid letting potential solo stakers feel like this activity is more daunting than it actually is.

Perhaps we could start with a 7-day period and then converge to 4 days as the share limit increases?

2 Likes
9

Hi Sam,

thanks for your feedback and attendance of the first town hall.

As explained in the call, the likelihood that one of the validators of a CSM NO will be requested for exit is currently very low. This is due to several reasons.

Following the SR’s allocation algorithm and VEBO’s sorting predicate of the validator exit order:
While CSM could reach half of its 1% Early Adoption Mode stakeShareLimit with the current queue of unused keys, I don’t see a relastic scenario in which enough stake - and, given the targetLimit of 12 active keys per NO, also new solo and community stakers - would flow into CSM that its currentShare would surpass the priorityExitShareThreshold, or the CM - as LoE’s fallback SM - would run the risk of NOs exceeding the soft cap before an expansion of CSM’s stakeShareLimit could be proposed. Additionally, CSM NOs should be amongst those with the lowest stake weights and active keys, as well as their validators have some of the highest indices. Finally, SDVT’s cohort 3 scaling will soon ask for a good amount of deposits too.

Nonetheless, I see the point in the feedback shared by you and Sat and kindly ask those who consider proposing changes to CSM parameters to take it into account.

However, as already mentioned, the SNOP cannot initiate any changes to LoE code.

1 Like
10

Jan did a great job of hosting the townhalls and taking us through the work he’s done to prepare a proposed updated to the Validator Exits SNOP, and we’re happy to share that the recordings are up!
Morning session

Afternoon session

1 Like
11

IMO having a good tool for CSM exit could be the ultimate solution to balance decentralisation and user experience, but perhaps that should be a separate discussion :grinning:

12

Hello everyone, please note that the link to the standalone document in the original post is no longer functional due to GitHub operations.

Instead, you can now find the unmodified file here: documents-and-policies/Lido on Ethereum Standard Node Operator Protocol - Validator Exits.md at ValidatorExitsV2.0 · sssngth/documents-and-policies · GitHub

2 Likes
13

Happy start to the week - in the lead up to the opening of the December window of the Snapshot cycle, I would like to share with you the IPFS variant of the SNOP that will be the basis for the vote and corresponds to the GitHub version provided earlier.

2 Likes
14

Snapshot vote started

Please get your wallets ready to cast a vote :white_check_mark:, the Update Lido on Ethereum Standard Node Operator Protocol - Validator Exits Snapshot has started! The Snapshots ends on Mon, 23 Dec 2024 16:00:00 GMT.

1 Like
15

Snapshot vote ended

The Update Lido on Ethereum Standard Node Operator Protocol - Validator Exits Snapshot has passed! :partying_face:
The results are:
For: 55.6M LDO
Against: 86 LDO

3 Likes