Lido on Ethereum Validator Exits Policy V1.0

Following the draft outlining policy updates, as discussed on the forums, this proposal proposes v1.0 of the Lido on Ethereum Validator Exits Policy, which covers validator exit mechanisms, goals, scope, policy statements, monitoring, penalties, and other considerations.

Policy document outline and summary

• With the V2 upgrade of Lido on Ethereum, validator exits may be required in order to meet potential user (staker) withdrawal requests (e.g. when size of the withdrawal request exceeds the amount of ETH available in the buffer for withdrawal-related use).
• This policy establishes the duties and requirements that Node Operators participating in the Lido on Ethereum protocol must adhere to with regards to the monitoring and processing of validator exit requests issued by the protocol.
• The order of validator exits is deterministic, prioritizing exits from the Node Operators with the largest amount of active validators and always exiting the “oldest” validators first.
• Validator exit requests will be signaled on-chain via the Lido on Ethereum Exit-Bus Oracle. Node Operators must monitor these events and timely process validator exits pertaining to validators that they operate in a timely manner.
• Failure to process exit requests in a timely manner will lead to delinquency which will cause Node Operators to receive reduced rewards until service is restored. This will be automatically enforced on-chain.
• Sustained delinquency without adequate communication and steps for remediation may result in the off-boarding of a Node Operator based on a DAO vote.
• Node Operators must always communicate proactively with the community in the case of out of order exits (i.e. exits not signaled by the protocol) or in the case that mass exits may need to be performed to provide the DAO enough time potentially respond via a vote.

Below are key excerpts in the Policy for summary purposes. Please consult the full Policy for details

B.1 Goals

Validator exits may be utilized by fully-functioning staking protocols, including Lido, for the following reasons:

• In order to satisfy withdrawal redemption requests from users (e.g. if a withdrawal request is larger than the amount of stake that can be made available for redemption via only partial withdrawals / skimming).
• To reallocate stake across the operator set (move stake from one operator to another) for a variety of reasons (e.g. substandard performance, guiding principles from the Operator Set Strategy).
• To rotate signing keys for some validators without changing the stake allocation.

The proposed V2 upgrade of Lido on Ethereum protocol would put in place a series of mechanisms based on on-chain signaling that will serve to notify Node Operators who participate in the protocol when they need to process validator exits.

B.2 Scope

This policy applies to the Lido on Ethereum protocol, the Node Operators that participate in the curated Node Operator registry (“Node Operator(s)”), and the validators that they operate as a part of the protocol. Validators outside of the curated registry are currently out of scope of this policy but may be included in later revisions.

B.3 Policy Statement

B.3.I Validator Exit Order

The exit sequence of Lido on Ethereum validators (i.e. validators submitted to Lido Node Operator Registries which have been deposited to) should follow a deterministic order so that they can be computed independently and trustlessly if needed. The current proposal for exit order is the “combined approach” discussed in the relevant topic “Withdrawals: on Validator Exiting Order”.

B.3.II Performance Expectations Over Time

As this is a new policy concerning new functionality of the Ethereum protocol, the proposed enforcement mechanisms, service level expectations, and associated timeframes detailed in this first version of the policy are mild enough to allow for working out initial kinks without an unreasonable penalty. Once the processes and mechanisms around the automation of validators exits have matured, this policy should be revised. In particular, time windows for service level expectations should be tightened and penalties for non-performance should be increased.

B.3.III Node Operator Responsibilities

Node Operators who participate in the Lido on Ethereum protocol have a duty to correctly exit validators in a timely manner as determined by the protocol’s requirements and rules (as set by the DAO). If they are requested to exit validators ( via signalling using oracles or the exit daemon infrastructure) by the protocol for any of the reasons described in the section “B1-Goals” and as per the validator exit order approved by the DAO.

In order to determine whether Node Operators have appropriately executed the required actions, this policy seeks to outline the time that Node Operators are afforded to do so, and what the penalties for non-conformance should be.

Generally speaking, Node Operators 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 Node Operators, and open source tooling will be available to aid Node Operators in identifying signaled validator exit requests, as well as in processing these requests. …

For clarity:

• A validator exit request is considered “signaled” once it is retrievable from the on-chain Exit Bus Oracle report (finalized on-chain multiple times per day).
• A validator exit request is considered “processed” once it has been broadcast to the CL and included in a proposed Beacon Chain slot.
• A validator exit request is considered “fulfilled” once the validator has been fully exited and withdrawn.

B.3.IV Monitoring and Penalties

…

If Node Operators are processing signaled validator exit requests as soon as they are available, the shortest possible time for a validator exit request to go from “signaled” to “processed” will be somewhere within the range of a few minutes to an hour. With respect to validator exit performance, each Node Operator may be considered to have one of the below three 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 maximum acceptable time frame.

| Event | Requirement to not be considered Delayed | Requirement not be considered Delinquent | | --- | --- | --- | | Processing of signaled validator exit requests | All signaled requests are processed ASAP (no longer than 1 day) | Some signaled requests are taking longer than 1 but less than 4 days to process | | Escalation of inability to execute signaled validator exit request with reason | ASAP but no longer than 1 day | ASAP but no longer than 4 days |

…

• If a Node Operator has a status of Delinquent, NOM workstream will raise a formal issue with the Node Operator on the Lido research forum. While a Node Operator has a status of Delinquent:
  • no new stake will be allocated to the Node Operator (this will happen automatically);
  • the daily rewards sent to the Node Operator will halve (with the remaining half sent towards that day’s rebase) (this will happen automatically). Reduced rewards will continue for the duration of a cooldown period long enough to determine whether, immediately after service restoration by the Node Operator, subsequently received validator exit requests are processed in a timely manner.

…

• Once a Delinquent Node Operator has processed all signaled validator exit requests (and thus their number of Delinquent validators in next Accounting Oracle report is updated to 0), they will recommence receiving validator exit requests. Their status shall revert to “In good standing” after 5 days (i.e. provided any newly received validator exit requests are processed timely). During this 5 day “cooldown period” they will continue to not receive new stake and receive halved rewards.

B.3.V Out of Order Exits and NO Business Continuity …

If at any time a Node Operator is unable to continue to participate in the Lido on Ethereum protocol (e.g. has become insolvent), it must notify the DAO via the Lido forums (https://research.lido.fi) of the circumstances and signal its intent to exit all of the validators that it operates as a part of the protocol. If the DAO does not otherwise instruct the Node Operator via a ratified vote within 8 days, it must proceed with triggering the exit of all of the validators.

Reference:

Full policy document: IPFS (V1.0), GitHub (V1.0), HackMD (current version, previous ones available via Options → Versions)

Voting Options:

For: Implement the Lido on Ethereum Validator Exits Policy as described above.

Against: Do not implement the Lido on Ethereum Validator Exits Policy as described above.