# VEBO 2.0

The purpose of this document is to look at changes to the Lido validator exit process in the near future due to new requirements for the process and possible changes to the Ethereum protocol. First, let's take a look at the current exit process.

## Current Implementation

The current implementation of validator exits in Lido is based on the Validator Exit Bus Oracle (VEBO). Off-chain oracle demons analyze data from the Consensus Layer (CL) and Execution Layer (EL) and make a decision on whether to exit validators, how many, and from which node operators.


The oracle itself cannot exit validators due to current protocol limitations, namely the absence of EL Triggerable Exits (ELTE). Therefore, the oracle only signals through events on the contract about which validators have been decided to exit.

In turn, node operators run Ejector on their side. This program stores pre-signed exit messages and monitors events in VEBO. In case of detecting a relevant event, an exit message is sent to the CL.

In the current implementation, the exit of validators pursues only one goal - to cover user withdrawal requests at the expense of ETH withdrawn from the validator after the exit.

## Requirements

It is proposed to change the current implementation based on a rethought understanding of the requirements for exiting validators not only from the point of view of covering user withdrawal requests, but also rebalancing stake among operators, exiting validators by governance decision, and at the discretion of the staking module. The possible emergence of ELTE in the Ethereum protocol allows us to reconsider the design of validator exits, allowing the Lido protocol to gain control over the withdrawal of user-locked ETH on the balance of validators.

The proposed solutions stem from the following requirements:

**Triggerable Exits**. Support Triggerable Exits in the protocol, which may appear in the next hard fork with some probability. The tool is vital for permissionless modules and provides leverage over control of the curated set of operators.

**Forced Exits**. Provide a tool for reducing the stake on a node operator without being tied to the volume of user withdrawal requests. The tool is useful for manual rebalancing of stake between node operators and modules regardless of the volume of user withdrawal requests, as well as a tool for forced offboarding of operators or limiting the amount of stake on them.

**Specific validators exit**. Provide a tool for the priority withdrawal of specific validators by public key. The tool can be useful for:

- Withdrawing specific validators, for example in case of compromise of private keys of some validators or migration of some validators to other tooling.
- Withdrawing specific validators in case of key loss or prolonged offline from the validator side.
- For withdrawing specific clusters in DVT modules, where the module structure has no operators, in case of violation of Lido policies or the module itself.

**Module target share**. Consider the target share of modules not only when distributing stake but also when exiting validators.

**Permissionless triggers**. Provide a tool for permissionless request of validators to exit. Such a tool can be useful for scenarios like:
- Dual Governance, to allow users to trigger validator exits in case of compromise of the oracle set.
- For permissionless modules, which may have their own handles for withdrawing validators in case of any policy violations.

## Proposed Changes

It is proposed to keep the current VEBO as a single entry point for withdrawing validators and add additional layers to VEBO: Priority Exit Bus (PEB) and EL Triggerable Exits (ELTE).

### EL Triggerable Exits

Based on the current draft of the [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002), it is assumed that for the forced exit of a validator on EL, it will be necessary to send an exit signal on behalf of the Withdrawal Vault (WV) contract, whose address is specified as Withdrawal Credentials (WC) at Lido validators, to the address of the precompiled contract.

It is proposed to supplement the Withdrawal Vault contract or write an additional one next to VEBO, so that any validator requested for withdrawal through VEBO can be forcibly exited through ELTE by providing the necessary proof.


It is assumed that anyone can bring proof that the validator was requested for withdrawal through VEBO. The contract will check the proof and call the corresponding method on the precompiled contract, which will lead to the addition of the validator to the exit queue.

The current implementation of VEBO already has everything necessary to prove that a validator was requested to exit earlier. Events contain the necessary data about the validator and one can prove their presence through a merkle proof. However, this is probably not the most gas-efficient way and the proof window is limited by the number of stored historical block hashes. It is suggested that VEBO will be modified to simplify the proof of requested validators, for example, by storing roots of trees of validators requested for exit.

The technical solution should take into account the work with multiple WCs in case of their change in the future or support of several WCs in the protocol, for example, for institutional staking.

The main idea is to have VEBO as a single source of validator withdrawals and build ELTE based on already accepted decisions. This approach has a number of advantages, which are proposed to be considered separately:

#### Single Decision-making Point

Allows keeping the current limits and sanity checks built from the general considerations of the entire protocol, such as the throughput of the exit queue on the CL and damage to the protocol in case of compromise of oracles or exploitation of vulnerabilities in smart contracts.

Allows coordinating data on the number and priority of validators to exit in one place. The current VEBO already operates a large number of parameters determining the priority of validators to exit, such as delays in processing requests by operators, the number of validators on an operator, the percentage of the entire network, the lifetime of validators. With the appearance of new modules and the release of Staking Router v1.5, new weights in prioritization of calls are expected, such as the module target share, forcing target limits, and similar. Unified limits and priorities will eliminate the need to coordinate data between different validator exiting tools.

Various scenarios can be envisioned, such as the forced offboarding of a large node operator and the forced exiting of several validators of the operator due to a lack of bond. The priorities of such scenarios should be implemented in the code explicitly.

#### CLTE + ELTE

Separating ELTE into an additional layer allows having two ways to exit validators: softly and without transaction costs with the forces of node operators on the CL side or forcibly without the participation of operators on the EL side. Different modules may have different policies around this process. For example, a curated set of operators may have stricter criteria for infrastructure and the requirement to run Ejector, while this requirement may not apply to community operators.

Fallback in the form of Consensus Layer Triggerable Exits (CLTE) allows not to be blocked on the presence of ELTE in the Ethereum protocol and design validator exits from general concepts.

### Priority Exit Bus

In VEBO, data is brought by oracles, but based on the new requirements, it is assumed that there should be the possibility of exiting validators through governance and, in some scenarios, permissionlessly. To solve this contradiction, it is proposed to add Priority Exit Bus (PEB).


#### Filling the Priority Exit Bus

It is proposed that PEB represents a contract into which different actors can bring validators to exit. It is assumed that such actors can be Aragon voting, EasyTrack motions, and Prover, through which one can bring evidence that the validator should be exited, for a pre-agreed list of scenarios.

It is assumed that PEB can be used to exit a large number of validators at once, for example through Aragon voting, so it is proposed to store roots of trees of validators to exit instead of the exact list of validators.

It is proposed to have a permissionless entry in the form of a Prover contract, which can check different scenarios. The design is proposed in which each scenario is a separate contract for verification. Examples of such scenarios can be:
- A scenario of collusion of LDO holders and Oracle holders in which validator exits are stopped and vetoed through Dual Governance. As simple proof in such a scenario may serve the presence of a veto, the volume of unfinalized stETH in the queue, the time elapsed since the date of creation of the first unfinalized request, and the insufficient number of previously requested validators.
- Violation of policies by some validators, for example, prolonged offline.
- The operator in the module has lost the private key from a validator and intends to exit the validator via triggerable exits. In this case, the operator can bring the key id, module id, and operator id to the Prover, and the Prover will check that `msg.sender` corresponds to the operator's address and add the key to the priority exit queue.

#### Submitting Data to VEBO

It is suggested that data from PEB to VEBO can be unwrapped by calling the corresponding contract method. The technical solution should provide for unwrapping the tree in several transactions, for large batches.

It is proposed that anyone can unwrap the data, but a priority time window is allocated for unwrapping by any member of the VEBO quorum. Until the appearance of ELTE, the time window is proposed to be made very large. Such a solution is based on a security check on the side of the Ejector, validating the signatures of transactions and comparing them with a pre-known list of oracle demon addresses.

Thus, without ELTE, validator withdrawals are carried out as before through CLTE with transaction signature verification, and after the appearance of ELTE, there are two streams: priority exiting through CLTE and permissionless exiting with a small delay.

#### Processing in VEBO

It is proposed to supplement the VEBO contract with a method allowing triggering events for validator exiting outside the frame of the oracle report and allowing this method to be called by PEB. At the same time, consider the limits of the current frame when calling the method. Planned VEBO reports should take into account extraordinary exit requests within the frame limits at the contract level.

### VEBO Improvements

#### Module Target Share

Module target share now only affect deposits, but not validator exits. Validator exit bus oracle (VEBO) does not consider module target share as a weight when deciding which validator to exit. It’s suggested to investigate how this parameter should be taken into account when exiting validators and implement changes in the code.

#### Forced Target Limit

Node operators have a target limit property that allows to balance the number of active validators on the operator to the target result. The limit is taken into account when covering withdrawal requests and when making a deposit, but does not allow withdrawing validators regardless of demand in the withdrawal queue. It is proposed to design the ability to exit validators forcibly, without being tied to users’ withdrawal requests.

## Scenario Examples

Examples of validator exit scenarios that are enabled by the implementation of PEB, ELTE, and VEBO improvements:
- Governance initiates offboarding of a node operator by setting a forced target limit to 0 through CLTE, followed by forced exit through ELTE if the operator rejects the protocol's request.
- Governance initiates a targeted exit of a batch of validators that have been offline for an extended period through ELTE, all at once from different modules and operators.
- Anyone can trigger the exit of a validator through Prover and CLTE & ELTE by providing proof of policy violation (e.g., extended offline period of a validator).
- Modules signal VEBO to forcibly exit a certain number of validators due to a bond shortage using the forced target limit.
- Anyone can trigger the exit of validators to cover requests in the Withdrawal Queue through Prover and CLTE & ELTE in cases where a veto is imposed by DG and the Withdrawal Queue is not processed.
- The curator of a DVT module with multisig initiates a motion to exit a cluster where quorum has ceased to be formed.