Discussion thread for Add EIP: Increase the MAX_EFFECTIVE_BALANCE by michaelneuder · Pull Request #7251 · ethereum/EIPs · GitHub


Increases the constant MAX_EFFECTIVE_BALANCE, while keeping the minimum staking balance 32 ETH. This permits large node operators to consolidate into fewer validators while also allowing solo-stakers to earn compounding rewards and stake in more flexible increments.


As of October 3, 2023, there are currently over 830,000 validators participating in the consensus layer. The size of this set continues to grow due, in part, to the MAX_EFFECTIVE_BALANCE, which limits the stake of a single validator to 32 ETH. This leads to large amounts of “redundant validators”, which are controlled by a single entity, possibly running on the same beacon node, but with distinct BLS signing keys. The limit on the MAX_EFFECTIVE_BALANCE is technical debt from the original sharding design, in which subcommittees (not the attesting committee but the committee calculated in is_aggregator) needed to be majority honest. As a result, keeping the weights of subcommittee members approximately equal reduced the risk of a single large validator containing too much influence. Under the current design, these subcommittees are only used for attestation aggregation, and thus only have a 1/N honesty assumption.

With the security model of the protocol no longer dependent on a low value for MAX_EFFECTIVE_BALANCE, we propose raising this value while keeping the minimum validator threshold of 32 ETH. This increase aims to reduce the validator set size, thereby reducing the number of P2P messages over the network, the number of BLS signatures that need to be aggregated each epoch, and the BeaconState memory footprint. This change adds value for both small and large validators. Large validators can consolidate to run fewer validators and thus fewer beacon nodes. Small validators now benefit from compounding rewards and the ability to stake in more flexible increments (e.g., the ability to stake 40 ETH instead of needing to accumulate 64 ETH to run two validators today).

Related workeip7251 related work · GitHub


I published an in-depth explainer on EIP-7251 for those interested in learning more about the proposal to increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2048 ETH and implement in-protocol validator consolidation as a solution to the problem of contracting the Beacon Chain’s validator set: EIPs For Nerds #3: EIP-7251 (Increase MAX_EFFECTIVE_BALANCE).

The article explains how EIP-7251 modifies aspects of the consensus protocol like validator activation, deposits, withdrawals, and slashing penalties to enable validator consolidation while preserving the Beacon Chain’s existing security properties. It also addresses regarding increased slashing risk for large validators and (potential) regulatory issues arising from implementing EIP-7251’s auto-compounding rewards feature. All comments/feedback are welcome.


Is it not necessary to also modify the ejection balance? If a validator consolidates their stake, they would lose substantially more from e.g. inactivity leak or lost keys before being ejected than retaining discrete, 32 ETH validators. Perhaps it should be proportional to the stake. Or am I missing something?

See also prior discussions

1 Like

Dear authors of the proposal, given the latest news regarding including the EIP proposed into Pectra, I have several questions about the actual implementation.

  • How the sweep threshold will be set?
    • Would it be a validator private key or WC to initiate this value?
    • Would this value be changeable during validator operation?
    • Can this value be reduced? (effectively acting as a trigger for the partial withdrawal)
  • The point about the cancelation of the initial slashing does not seem to be researched. When should one expect clarifications?
  • How will validators consolidation be performed?

Any information available is appreciated!

1 Like

I believe this blog post answers my question

Hi @dgusakov. I updated the EIPs For Nerds: EIP-7251 article with information about the validator consolidation process. I consulted this article from @mikeneuder and team, so you can check that for answers to some of the other questions you asked.

The slashing penalty analysis has useful information on the cancelation of the initial slashing penalty. I haven’t seen anything concrete on the decision to remove the initial slashing penalty, but it’s part of the EIP-7251 feature set, so we should have more information about it soon enough. (I should update the EIP-7251 article once the info is available, too.)

1 Like

The proposal has the nice side effect of also increasing the average total value locked by the sync committee, making slashing approach for that more desirable in the future: EIP-7657: Sync committee slashings

Having these not in the CL ExecutionPayload makes local verification of EL block_hash complicated for the CL.

Generally, all of the new EIP-7685 “general purpose execution layer request” tend to share some of that, but the types 0 and 1 are at least somewhat mappable back to something of which the block hash can be computed by an optimistically syncing CL (while EL is undergoing maintenance, it cannot answer INVALID_BLOCK_HASH so the CL has to do it internally).

I’d advocate to try and replicate the three lists (deposit receipts / withdrawal requests / consolidation requests) into the EL block header as separate fields (instead of EIP-7685), and/or to create a EIP-6493 style StableContainer as their union, given their overlapping nature in common fields.

Currently the EIPs seem a bit… ad-hoc to me, which is alright for the initial devnet, but should be cleaned out later on.

Furthermore, all the extra BeaconState fields break trustminimized Merkle proof verifiers for decentralized staking pools such as RocketPool. It should be considered to combine this with EIP-7688: Forward compatible consensus data structures.

Have put it on the ACDE agenda as well: Execution Layer Meeting 187 · Issue #1029 · ethereum/pm · GitHub

Have the following scenarios been taken into account:

  1. initiating a validator exit with 32 ETH and then topping it up to 2048 ETH (would it allow me to go around the churn limits?)
  2. initiating a validator exit with 32 ETH and then consolidating other validators to the exiting validator (would it allow me to go around the churn limits?)

a separate question:

  • since on consolidation we are not really exiting the staked ETH, would it be possible to maintain a map of consolidated validators to their new indices for the period that would normally be driven by the churn limit without applying the actual churn limit delay? this would still allow us to slash the ETH (slash the target) while not delaying the consolidation of large operators