## [Draft] MaxEB: Withdrawals part

To support a 2048 ETH max effective balance, the VEBO oracle algorithm for selecting the next validators for exit should be updated. This algorithm should be based on validator balances rather than the number of validators. It should take into account partial withdrawals and consolidation.

1. VEBO oracle changes

1.1. VEBO oracle rules for choosing validators will be modified to support the new max effective balance value, as validators will now have varying balances:
- oracle already works with electra max_effective_balance
- Should be added predicate that compare sum of effective balance of validators of a node operators;
- Should reconsider places like `predictable_effective_balance = calculate_effective_balance_non_exiting_validators + transient_validators_count * LIDO_DEPOSIT_AMOUNT` as they use an outdated deposit value. Also possibly we will support both 32Eth and 2048 validators.
- It should take into account partial withdrawals, consolidation, and possible operator weights
- `max_validators_to_exit` value we read from sanity checker possibly should be represented in balance (effective balance) to represent amount we want to exit via oracle report.
- Currently exits cover withdrawal demand. This value can be increase to covers the targetShare of modules, and this should be restricted by a configurable cap; It will improve reallocation (topic of another document)

1.2 The VEBO report should be changed to contain the requested amount for withdrawals (in ETH), and exit entries should also include the operator’s balance.

    /// MSB <------------------------------------------------------------------- LSB
    /// |  3 bytes   |  5 bytes   |     8 bytes      |    48 bytes     |
    /// |  moduleId  |  nodeOpId  |  validatorIndex  | validatorPubkey | balance  |

**TODO: detailed algorithm**

1.3. The oracle can also support partial withdrawals.
In the protocol, partial withdrawals may be limited to a certain percentage — for example, only X% of validators can be partially withdrawn. This feature is intended for faster fulfillment of withdrawal requests. The oracle must track these validators. They will continue to be withdrawn until their balance reaches zero. Also it can be usefull, if withdrawals demand 32 ETH, but all validators hold 2048 ETH, partial withdrawals help oracles cover requests more flexibly—without needing to exit entire validators.

This operation will incur a fee, meaning we are paying to accelerate withdrawal coverage.

We need to analyze whether it’s possible to withdraw the full 2048 ETH in the worst-case scenario. Further analysis is required to determine whether this trade-off is acceptable.

2. Exit requests in the VEBO contract are limited by the ExitLimitUtils library.
This library currently uses a maxExitLimits value per a fixed time period.
Instead, it should use balance-based logic: maxExitLimits * 32 ETH.

3. Oracle sanity checker:
The values such as exitedValidatorsPerDayLimit and maxValidatorExitRequestsPerReport should be based on total balance, rather than the number of validators.

4. VEBO contract:
Suggested to devide VEBO contract on two: oracle and validators exit bus:


Draft scheme for vebo changes:
https://miro.com/app/board/uXjVInc8cwA=/

4.1 Validator exit bus oracle contract

- Should now support the new oracle report that includes validators' balances; this will affect sanity checks and limits; Sanity checks should be based on balances to not allow to influence TVL;
- Oracle send exit requst hash and data to VEB contract. Veb contract will emit voluntary exit event and store hash to later have opportunity to trigger exit via 7002;

4.2. Validators exit bus contract

- Should have two flows: full withdrawals mechanism via Voluntary exits with next possibility to exit via 7002 (as it implemented in TW release) & trustfull partial withdrawals flow;
- Before processing request data, a balance-based limit will be checked; maxValidatorsPerReport will be replaced with a balance limit check;

4.3 New trust assumption

- The oracle could misreport validator balances — e.g., claiming 32 ETH while the actual balance is 2048 ETH.
- This could lead to reward loss, but not loss of stake.

5. TWG triggerFullWithdrawals is limited by ExitLimitUtils,
which should use balance instead of the number of exits.
The main method must be modified to support balance-based checks.