# EIP-7251 for Staking Pool Operators The next Ethereum hard fork, Pectra, is currently targeting release near the end of 2024. [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251) is designated for inclusion in this fork. Ethereum core developers are soliciting feedback from staking pool operators regarding some design decisions around EIP-7251. There are three orthogonal design decisions to be made: 1. How to Initiate Validator Consolidations 2. Setting Compounding Withdrawal Credentials 3. Custom Ceilings For each of the proposed designs, we are soliciting answers to the following questions: 1. Does this design break your accounting / operations in a way that cannot be rectified in time for the fork? 2. Does this design prevent you from using EIP-7251 with (consolidating) existing validators? 3. Does this design prevent you from using EIP-7251 with (consolidating) future validators? 4. What can we do to better enable you to opt into using EIP-7251? ## Initiating Validator Consolidations A consolidation operation combines two validators into one without either having to exit and re-enter the validator set. The main advantage of using a consolidation operation (rather than exiting the validator set and re-entering) is that the consolidating validator will only miss out on 256 Epochs (~27 hours) of profit (~0.0024 ETH per 32 ETH validator at time of writing). #### Current Design We only allow **validators with the same execution withdrawal address** to consolidate, effectively treating these validators as if they were fungible. Consolidation is initiated via a **beacon chain operation** similar to `BLS_TO_EXECUTION_CHANGE`, from the **source validator**. With this design, **anyone in possession of the signing key to a validator with the same withdrawal address as the target validator can initiate a consolidation into the target validator**. Important note: when a source validator is consolidated into a target validator, the target validator becomes compounding (more on this in the next section). #### Alternative Design It *might* be possible to allow consolidations to be Execution Layer initiated (meaning the consolidation operation would be submitted as a transaction from the withdrawal address). This adds a decent amount of complexity and we may simply opt to exclude consolidations all together if this is our only option. ## Setting Compounding Withdrawal Credentials EIP-7251 introduces a new type of withdrawal prefix: `0x02`. Validators with this *compounding* withdrawal prefix are opted into **compounding rewards**. Thus they are **exempt from the standard withdrawals sweep** until their balance reaches `2048 ETH`, or potentially a custom ceiling if we implement this (more on this in the next section). We plan to implement **execution layer initiated partial withdrawals** to allow compounding validators to withdraw rewards before hitting this ceiling if they wish. #### Current Design There are two ways for a target validator to become compounding in the current design: 1. Consolidate another validator into the target validator 2. Make a top-up deposit to the deposit contract, signed by the target validator's signing key Thus there are **two actors** who can change a target validator to compounding credentials: 1. Anyone in possession of the signing keys of a source validator with the same withdrawal address as the target validator 2. Anyone in possession of the signing keys of the target validator and at least 1 ETH Note: in theory an attacker could force a target validator to become compounding if they are willing to gift the target validator 32 ETH in the process. ## Custom Ceilings We are considering allowing validators to specify a custom ceiling: `32 ETH < ceiling <= 2048 ETH` for which compounding validators would have rewards in excess of this ceiling automatically withdrawn by the withdrawals sweep. #### Current Design We wish to exclude this feature for this fork to save on complexity. ## Thank you We appreciate your time. If possible, please have a representative present in [the next MaxEB breakout meeting](https://github.com/ethereum/pm/issues/1012) to discuss your responses to these questions.