Update Lido on Ethereum Standard Node Operator Protocol - Validator Exits

Summary

This proposal seeks the community’s approval to update the currently in effect Lido on Ethereum (LoE) Validator Exits Policy 1.0 (Snapshot) to the proposed Standard Node Operator Protocol (SNOP) on Validator Exits 2.0 (diff-view), following the draft as presented and discussed on the Lido Research Forum and during two community town hall calls.

Context and Motivation

The current Validator Exits Policy is outdated as it does not reflect protocol improvements made in Staking Router (SR) 2.0 (Snapshot, on-chain vote), and the addition of the Simple DVT (Snapshot, on-chain vote) and Community Staking (Snapshot, on-chain vote) modules which are now live on mainnet.

SR 2.0 includes some new concepts and individual approaches with regard to validator exits with respect to the now three active Staking Modules (SMs): the Curated Module (CM), the Simple DVT Module (SDVTM), and the Community Staking Module (CSM).

The Validator Exits SNOP has been reworked with 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 Node Operator (NO) expectations with regard to the usage of the protocol, and the possible consequences of non-conformance as per the rules of each SM.

Overview of Changes and Additions

The changes and additions include:

• Refactoring of the structure in an attempt to create a template structure for all future 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
• A clearer description of a mechanism through which an NO validator exit request status of delinquent can recover to an in good standing status
• A clearer explanation, on a per-SM basis, of validator exit requirements and penalties for non-conformance as per the protocol code

Key Excerpts

B - Scope

This SNOP applies to LoE, the NOs who use one or more of the Staking Router (SR)'s Curated Module (CM), Simple Distributed Validator Technology Module (SDVTM), and Community Staking Module (CSM) and the validators the NOs operate as part of the Liquid Staking Protocol (LSP).

[…]

C - Validator Exit Order

[…]

In the SR 2.0, the priority of exits is determined by the following sorting predicate.

| Sorting | Staking Module | Node Operator | Validator | | --- | --- | --- | --- | | V | | Lowest number of delayed validators | | | V | | Highest number of targeted validators to boosted exit | | | V | | Highest number of targeted validators to smooth exit | | | V | Highest deviation from the exit share limit (i.e. highest positive difference between currentShare and priorityExitShareThreshold) | | | | V | | Highest stake weight | | | V | | Highest number of active validators | | | V | | | Lowest index |

[…]

D - Node Operator Responsibilities

LoE contains on-chain signaling mechanisms that serve to notify NOs when to process validator exits. If exits for keys under their operation have been requested through the Validators Exit Bus Oracle (VEBO) smart contract, NOs have the duty to fully, correctly, and timely exit validators as determined by the requirements and rules set by and for any of the reasons described in the sections A - Purpose and C - Validator Exit Order, as per the latest in force SNOP.

To determine whether NOs have appropriately executed the required actions, this SNOP outlines the operative timelines for exits processing, and specifies the consequences of non-conformance. Generally, NOs are expected to exit the indicated validators in a reasonable time frame. The actual mechanisms for validators to be exited are at the discretion of the NOs, with community-built open-source tooling (see Appendix B) to aid the NOs in identifying and processing signaled requests being available in addition to any internal tooling, APIs, or manual processes NOs may use.

D.1 - Out of Order Exits

Out of order exits refer to exits that are made by an NO of one of or both the CM and SDVTM when a validator exit request has not been made through the VEBO. In such cases, the NO must notify the community via the Lido Research Forum that an out of order exit has been processed, how many and which validators have been exited, and the reason for it. As the CSM is permissionless and validators are bonded, this expectation is not extended to validators contained therein, CSM NOs are free to exit out of order at their discretion.

D.2 - Business Continuity

If, at any time, an NO of one of or both the CM and SDVTM is unable to continue operations, e.g. has become insolvent, the NO must notify the community via the Lido Research Forum of the circumstances and signal intent to exit all of the validators the NO operates using LoE. If LDO token holders, via a ratified vote within 8 days, do not instruct the NO otherwise, the NO must proceed with triggering all of the exits.

D.3 - Validator Exits Performance

[…]

With respect to validator exits performance, at any point in time, each NO may be considered to have one of the below three validator exit request statuses:

• in good standing – validator exit requests are being processed fully, correctly, and timely
• delayed – validator exit requests are being processed incompletely, incorrectly, or not within the desired time frame
• delinquent – validator exit requests are being processed incompletely, incorrectly, or not within the acceptable time frame

For every delinquent exit request, i.e. a request that has been unprocessed for longer than the delinquency threshold, an NO's per-SM stuckKeysCount increases by 1. An NO with a stuckKeysCount > 0 is delinquent, which may result in the NO's share of rewards being reduced and/or penalties imposed for the affected and possibly further frames, as determined by the respective SM. The time for an NO to recover to in good standing depends on four aspects, (1) the NO having processed all delinquent exit requests, (2) the frame length of the Lido Oracle sub-module that reports updates on validator exit request statuses, (3) the frame length of the sub-module whose reports account for NO penalties related to unprocessed exit requests or delinquency, and (4) any SM-specific cooldown period for NO delinquency. For the CM and SDVTM, the relevant sub-module is the Accounting Oracle (AO), for the CSM it is the Performance Oracle (PO). The CM and SDVTM have a cooldown period for NO delinquency of 120 hours, long enough to determine whether, immediately after service restoration, subsequently received validator exit requests are processed timely. The CSM does not have such a cooldown period.

To avoid NO delinquency, NOs must adhere to the following time frames.

| Event | Requirement to not be considered delayed | Requirement to not be considered delinquent | | --- | --- | --- | | Processing of signalled validator exit requests | All signalled requests are processed in less than 24 hours after a VEBO report | Some signalled requests are taking longer than 24 but less than 96 hours to process | | Escalation of inability to process signalled validator exit request with reason | ASAP but no longer than 24 hours | ASAP but no longer than 96 hours |

E - Consequences of Non-conformance

In case that an NO is not processing validator exit requests timely, the below actions shall be taken. Separate measures may be applied depending on the technical characteristics of the SM within which the request originated. For example, while NOs are known for the permissioned CM and SDVTM, NOs of the permissionless CSM may remain anonymous and reaching the NOs is only possible if a contact is voluntarily shared with the community.

[…]

The full text of the proposed Validator Exits SNOP 2.0 published to the IPFS will be a single source of truth if the proposal passes. The alternative sources that can be used to access the policy text are as follows:

• GitHub
• HackMD

Vote Outcomes

If the "For" option reaches quorum and a majority in favor of the proposal, the new version published to the IPFS will replace the previous document one-to-one and be used as the human-legible reference for the interaction of the protocol with NOs using LoE to operate validators from the moment of the conclusion of the vote.

If a quorum is not met or the proposal is rejected, 1.0 remains in effect until a quorum is reached in a subsequent vote and/or the draft is adjusted to satisfy the community.