# MaxEB 💧 Lido

## Problem

The proposed EIP-7251 introduces major backwards compatibility issues for the Lido protocol (probably other staking pools and delegate protocols) with a risk not being mitigated before the projected hardfork date.

Notably, several modifications disrupt backward compatibility, such as:
- Lido distributes stake and rewards to operators based on the number of active validators, not their balance. The ability to switch to 0x02 allows the node operator to accumulate significantly more stake on the validator than the protocol intended, and the voluntary consolidation of validators on CL allows the operator to significantly reduce the number of active validators for the same amount of stake, which will result in all new deposits being directed to the operator's keys. This opens up an attack vector for operators to attack the protocol accounting.
- Lido protocol counts the participating validators based on the preuploaded and deposited through the protocol keys, not by withdrawal credential. Consolidation on validators not deposited through Lido contracts but with Lido withdrawal credential allows a malicious actor to break the link between validators and operators and disrupt the accounting of the protocol.
- The proposed changes alter the way the total balance of locked ETH on the Consensus Layer is determined. In addition to the validators' balance, the lists `pending_balance_deposits` and `pending_partial_withdrawals` must also be taken into account.

To accommodate the changes proposed in maxEB, a significant portion of the protocol needs to be revisited: accounting, deposits, stake and reward distribution among operators, validator withdrawals, etc. This requires substantial resources for design, development, and auditing. And the preliminary Pectra hardfork date poses significant implementation risks.

## Solution

The main issue seems to be the ability to consolidate and switch to 0x02 without the involvement of the withdrawal address.

**Permissions.** A solution could be to check in the `apply_deposit` and `process_consolidation` methods for such permission from the withdrawal address.

Permissions could be stored in `BeaconState` as a list of withdrawal addresses that have explicitly allowed the transition to compounding withdrawal credentials. The permission for the transition could be granted by a transaction similar to `execution_layer_withdraw_request` and be a one-time operation.

This solution would allow for phased changes to the Lido protocol without sacrificing quality and security: minimal necessary to support the hardfork, full support and migration.

**EL initiated.** Another solution to the problem could be consolidation and switching to 0x02 initiated from the Execution Layer side