web3.newbeta
by
← Protocols
EIP-7251 — Increase the MAX_EFFECTIVE_BALANCE (MaxEB)
Standard / EIP·EVM

EIP-7251 — Increase the MAX_EFFECTIVE_BALANCE (MaxEB)

[ Docs ][ github.com/ethereum/EIPs ]
01Description

Pectra Core EIP raising `MAX_EFFECTIVE_BALANCE` from 32 ETH to 2,048 ETH while keeping the 32 ETH minimum. Introduces compounding validators (type `0x02`), in-protocol consolidation, and execution-layer-triggered partial withdrawals via a system contract, so operators can run fewer validators with auto-compounded rewards.

02Best for
  • 01staking pools / LSTs reducing validator count and infra cost
  • 02solo stakers wanting auto-compounding above 32 ETH
  • 03validator consolidation tooling
  • 04execution-layer partial-withdrawal UX
  • 05rewards accounting that scales with effective balance
03Install
  • # Consolidation request system contract: 0x0000BBdDc7CE488642fb579F8B00f3a590007251
  • # Withdrawal request system contract (EIP-7002): 0x00000961Ef480Eb55e80D19ad83579A64c007002
  • pnpm add viem
  • forge install ethereum/consensus-specs
05Prompt snippet
Build against the two system contracts shipped with Pectra: the consolidation contract at `0x0000BBdDc7CE488642fb579F8B00f3a590007251` (EIP-7251) and the withdrawal request contract at `0x00000961Ef480Eb55e80D19ad83579A64c007002` (EIP-7002). To upgrade an existing 0x01 validator to compounding, send a switch-to-0x02 consolidation where `source_pubkey == target_pubkey`; to merge two validators, the source is exited and its balance is added to the target up to `MAX_EFFECTIVE_BALANCE = 2048 ETH`. Both calls take a fee from the system contract that scales EIP-1559-style with queue pressure — read the current fee with a static call before sending. After consolidation, rewards compound on the target's effective balance and partial withdrawals trigger automatically only above the new ceiling. Index the consensus-layer `consolidation_request` and `withdrawal_request` operations to reflect status in your UI; do not assume the call succeeds — it can be skipped if the validator is not yet active or if the queue is full.
06Gotchas
  • ⚑MaxEB is opt-in per validator: a 0x01-credentialed validator is unaffected until it is upgraded to 0x02 (compounding). Do not assume all validators auto-compound after the fork — UIs must show credential type and surface the upgrade flow.
  • ⚑The consolidation and withdrawal request contracts charge a dynamic fee that grows with queue pressure; a transaction that does not forward enough ETH is silently dropped (no revert on the EL, but the CL ignores the request). Always quote the current fee via static call and include a small premium.
  • ⚑Source validator is fully exited during consolidation — its 32 ETH minimum is moved to the target. There is no partial consolidation, and the source's withdrawal credential must already be 0x01 or 0x02. Plan slashing and key-rotation flows around this irreversibility.
  • ⚑Slashing penalty scales with effective balance: a 2,048 ETH compounding validator can lose up to ~64x more than a 32 ETH validator from a correlated slashing. Diversify keys/clients across consolidations even though MaxEB lets you run fewer.
  • ⚑Activation churn is shared between deposits and consolidations — heavy consolidation activity can throttle new staker entry, and vice versa. LSTs and staking dashboards should display estimated wait times based on current churn limit.