EIP-8071: Prevent using consolidations as withdrawals

Cancels consolidation if the max effective balance of the target validator will be exceeded, preventing the withdrawal of the unused balance

Metadata

Status: DraftStandards Track: CoreCreated: 2025-10-29

Authors

Mikhail Kalinin (@mkalinin), Francesco D'Amato (@fradamt)

Links

GitHub page Discussion on Ethereum Magicians

Abstract

Cancels a consolidation request if the effective balance of the target validator would exceed the max effective balance after processing it, which would result in the excess balance being withdrawn. This is an unintended way to speed up withdrawals when the consolidation queue is faster than the exit queue.

Motivation

The existing design of consolidation mechanism leaves an opportunity to use consolidation queue for exits which becomes appealing to be abused when there is an imbalance between exit and consolidation queues favoring the latter.

At the date of writing this EIP, the consolidation flaw is being heavily exploited. There are public write ups on how to speed up withdrawals by using this vulnerability.

Even though this is a UX rather than security issue, consolidation queue was never meant to be used for withdrawals, which makes the fix introduced by this EIP an important modification.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Starting from the beginning of the epoch when this EIP is activated, Consensus Layer client MUST use modified process_consolidation_request function which code is outlined below.

New `get_pending_balance_to_consolidate`

Modified `process_consolidation_request`

Note: This function is extended with the check of the target's balance after consolidation and cancels consolidation request if the balance exceedes the max effective balance.

Rationale

Iterating over pending consolidaitons

The new design introduces an iteration over pending consolidations which increases complexity of consolidation processing.

This is done to handle the case when there are multiple consolidations with the same target and each of them doesn't exceed the max effective balance while all of them together does.

Backwards Compatibility

This EIP introduces backwards-incompatible changes to the Consensus Layer and must be activated via scheduled network upgrade.

Test Cases

test_single_consolidation_request_at_max_eb
test_no_pending_consolidations_exceeding_max_eb
test_single_pending_consolidation_exceeding_max_eb
test_multiple_pending_consolidations_at_max_eb
test_multiple_pending_consolidations_exceeding_max_eb
test_exceeding_max_eb_with_the_target_balance_but_not_eb
test_exceeding_max_eb_with_the_source_eb_but_not_the_balance
test_multiple_pending_consolidations_exceeding_max_eb_with_the_source_eb_but_not_the_balance

All of the above test cases are implemented here.

Security Considerations

When consolidation reuqest results in max effective balance exceed it is cancelled on the Consensus Layer, neither request fee nor transaction gast cost are refunded in this case.