# EIP-7251 MaxEB Breakout Call #5 - Apr 9, 2024

Next call: [Tuesday Apr 16 @ 1200 UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo-australia-sydney/apr-16-2024/2pm).
See PM issue for details: https://github.com/ethereum/pm/issues/1012

**Please reach out to all stakeholders to participate in these calls to voice any concerns and clarify specification for downstream staking pools/entities!**

Reference: https://github.com/ethereum/pm/issues/1008
Previous Notes: https://hackmd.io/@philknows/Sy2kQAq1C

---

## Consolidations
- Debate continues between beacon chain operation vs. execution initiated.

### Additional notes from Lido
- Current design is not ready for consolidation. Multiple places where healthy validators are assumed to be near 32 ETH effective balance.
- Validators are not actually fungible, even under the same withdrawal key
- If we do beacon chain operation for consolidations (no gatekeeping or initiations from execution layer), we will need to upgrade in two steps:
- Step 1: Safeguard accounting to prevent breaking if there are accidental consolidations.
- Step 2: Architectural upgrade in include maxEB.
- If we do execution initiated operation for consolidations, we can do the upgrade all at once with everything complete to support.
- No Consolidation Option: Not a problem if no consolidations are not included with maxEB. They would lose out on some useful features like balancing ETH between operators
- Lido would prefer that if we cannot ship EL initiated consolidations, it would be preferred that there's no consolidation until Lido is ready for Step 2 in their 2-step upgrade.

### Feedback from Mikhail
- Not sure if we can do execution initiated consolidations in this hard fork.
- We would need to extend EIP-7002, adding more fields: `signature`, `target`, `source`
- Or have another smart contract
- Having no consolidations at all is also an option.

### Rocketpool Notes
- Consolidations don't necessarily break Rocketpool.
- Minipools are never shared between validators Each pool as its own withdrawal credential.
- Each withdrawal credential matches 1:1 with each validator
- Case: Node operator may consolidate minipool to ourside validator. Funds would be safe, metadata would be wrong. Cost of 16 ETH.
- Today RP would be safe with current consolidation spec
- Would prefer execution initiated consolidations to limit attack surface
- CL update is out of protocol.
- Would probably need outside stuff like oracles to deal with this.
- EL messages are easier for RP to engage with.
- Rocketpool minipools will likely not consolidate
- Median number of validators per node operator is low (2).
- In the case of top-ups (depositing out of band) it would be seen as a gift to rETH holders because it's all treated as rewards from beacon chain, then splits them between rETH holders and node operators
- Smart contracts today wouldn't be able to use maxEB properly.
- Looking to support in next version
- Compounding is good for rETH holders to bring up yield
- Deposit flow for changing validators to `0x02` compounding is not ideal. Out of protocol and RP would see it as a reward for rETH holders.
- No Consolidation Option: Rocketpool indicated this would not affect them. Unlikely validators there will use this feature.

### Decision
- It's widely agreed upon that for adoption of EIP-7251, consolidations _need_ to be included.
- Note that it will require more work on some of these staking protocols (e.g. Lido), so adoption may be slower.
- Pending additional feedback from other stakeholders, beacon chain operation (as current in spec) is going forward at least for devnet-0 until more feedback is considered.

## Custom Ceilings
- None of the pools yet have a strong opinion on this
- Helps solo stakers mostly
- Leaving this feature out would reduce complexity

- Concern: Using the EL withdraw request heavily if we don't implement.
- Target requests = 2 requests per block
- Functions similarly to EIP-1559 dynamics
- Fee would grow quite quickly with a large number of requests
- **How heavily will EL partial withdrawal queues be used by staking pools?**

### Decision

As of right now, there is not a lot of demand for including this as the benefits are minimal and increases complexity of implementation. Please speak up (solo validators!) if this is important to you.

## Weak Subjectivity in Top-Ups
Please see Francesco's PR: https://github.com/ethereum/consensus-specs/pull/3650

### Decision
Under reviews, will likely get merged.

## Preparation for pectra-devnet-0
- There is agreement amongst teams to implement EIP-7251 as is currently in the spec, while in parallel getting more feedback to above design changes.
- We will need be more firm as there is a timeline of 1 month to prepare for devnet.
- **Please speak up if you have opinions!**
- **Please share and see explanations we require the staking community to provide feedback on! [EIP-7251 for Staking Pool Operators](https://hackmd.io/@wmoBhF17RAOH2NZ5bNXJVg/S1U86pzgR)**