EIP-8061 Higher exit and consolidation processing limit (Increase Exit and Consolidation Churn)
No call decision · Consensus & staking · EIP status Last Call · created 2025-10-17
Increases the amount that validator exits and the consolidation queue process each epoch. The exit limit loses its cap and becomes proportional to total stake, and consolidation gets its own dedicated limit. The activation cap stays as it is.
Why it is needed
Ethereum limits how many validators can enter and leave per epoch. This is a safeguard against the case where both sides of a chain split get finalized. However, that limit is too conservative. EIP-7251 applied the cap that EIP-7514 placed on activation to exits as well, so the exit limit became tied to 256 ETH per epoch regardless of total stake. The more stake grows, the longer the queue gets. In practice, during the Kiln validator mass exit the queue exceeded 40 days. A long queue hurts user experience, keeps operators from responding quickly to market or operational incidents, and slows the reallocation of stake after an incident to regain finality. When liquidity is blocked, centralized services that can issue liquid staking tokens or hold liquidity reserves gain a relative advantage. Validator consolidation is held down by the same limit. Under current conditions, reducing about 32 million ETH of 0x01 stake takes 1.3 to 1.5 years. If consolidation is slow, the path to faster finality is slow too.
What changes
Today
- Activation and exits share one limit, and both are bound by the 256 ETH per epoch cap
- The exit limit is independent of total stake, so the queue grows longer as stake grows
- Consolidation uses only what remains after activation and exits, and cannot be tuned separately
- The weak subjectivity period is about 15.7 days (based on 36 million ETH of total stake)
After EIP-8061
- The exit limit loses its cap and is proportional again at 1/32,768 of total stake (about 4 times the current cap)
- Activation keeps the existing cap of 256 ETH per epoch
- Consolidation has a dedicated limit (1/65,536 of total stake) and can be tuned independently (about 2 times)
- The weak subjectivity period shrinks to about 7.0 days
Who is affected
- Stakers and validator operators: The exit queue gets shorter, so it takes less time to withdraw funds or move them elsewhere. They can respond faster to market or operational incidents.
- Operators who want to consolidate validators: The consolidation queue is separated from activation and exits, so consolidation processing is not blocked even when deposits surge. The validator set gets smaller faster.
- Node operators and consensus client teams: The weak subjectivity period shrinks from about 15.7 days to about 7.0 days. Clients must implement three new constants, three limit functions, and the weak subjectivity period formula.
- Liquid staking and centralized staking services: As the protocol's own liquidity improves, the relative advantage they gained from a lack of liquidity shrinks.
In depth
Constant changes: one halved, one new, one renamed only
CHURN_LIMIT_QUOTIENT is halved from 2**16 to 2**15 and renamed CHURN_LIMIT_QUOTIENT_GLOAS (32,768). This value is used only for activation and exits. For consolidation, a new constant CONSOLIDATION_CHURN_LIMIT_QUOTIENT is set to 2**16 (65,536). Consolidation thus receives half of activation and exits combined, one third of total throughput. The existing MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT becomes MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT and keeps the same value of 2**8 (256). EXIT is dropped from the name because the cap now applies only to activation. The source also explains why the deposit cap is left as it is. It states that growth of the active validator set was mostly solved by EIP-7251, but the validator array in BeaconState (including inactive validators) is still large and still growing, and that stake itself growing too fast is still a concern.
Three churn limit functions
The existing get_activation_exit_churn_limit is split into two functions. get_activation_churn_limit takes the larger of MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA and get_total_active_balance(state) // CHURN_LIMIT_QUOTIENT_GLOAS, rounds it down to a multiple of EFFECTIVE_BALANCE_INCREMENT, and then caps it at MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT. get_exit_churn_limit does the same calculation but has no cap. The new get_consolidation_churn_limit rounds get_total_active_balance(state) // CONSOLIDATION_CHURN_LIMIT_QUOTIENT down to a multiple of EFFECTIVE_BALANCE_INCREMENT, with neither a minimum nor a maximum. Previously the consolidation limit was set implicitly as the share left over after subtracting the activation and exit cap from the total limit. Once the exit cap is gone, the idea of a leftover share disappears, so a dedicated constant became necessary.
Weights in the weak subjectivity period formula
In compute_weak_subjectivity_period, the single line delta = get_balance_churn_limit(state) is replaced with a weighted sum of the three limits. It is delta = 2 * get_exit_churn_limit(state) // 3 + get_activation_churn_limit(state) // 3 + get_consolidation_churn_limit(state). Next, epochs_for_validator_set_churn = SAFETY_DECAY * t // (2 * delta * 100) is computed, MIN_VALIDATOR_WITHDRAWABILITY_DELAY is added, and the result is returned. The weights come from how much each operation erodes safety. One unit of exit is 4/3, one unit of activation is 2/3, and one unit of consolidation is 2, the sum of exit and activation. This is because consolidation is equivalent to doing one exit and one activation at the same time. Using a safety decay target of 10% as the baseline, WS_epochs = 256 + 0.1·S / (4/3·E + 2/3·A + 2·C). The 2 * delta in the code corresponds to this denominator. To convert to days, divide the number of epochs by 225.
What changes in deposit and exit processing
In deposit processing, process_pending_deposits computes available_for_processing as state.deposit_balance_to_consume + get_activation_churn_limit(state). Only the function name changes. The rest of the flow stays the same: waiting for unfinalized deposits, the MAX_PENDING_DEPOSITS_PER_EPOCH limit, postponing deposits of exiting validators, stopping when the limit is exceeded, and carrying over the remainder only when the limit is reached. In exit processing, compute_exit_epoch_and_update_churn takes per_epoch_churn from get_exit_churn_limit(state). If the exit amount is larger than the exit_balance_to_consume remaining at earliest_exit_epoch, the excess is divided by per_epoch_churn and rounded up, the epoch is pushed back by that many epochs, and the consumable balance is increased by the same amount. The source describes this as returning to the pre-Electra state, in which activations had a cap and exits did not.
The change in numbers: from 15.7 days to 7.0 days
The source computes with a total stake S of about 36 million ETH at the time of writing. Today A = E = min(256, S/2**16) = 256 ETH, which hits the cap. C = S/2**16 - A ≈ 293 ETH. The weak subjectivity period is about 3,533 epochs, or about 15.7 days. After this EIP, E = S/2**15 ≈ 1,098 ETH, A = 256 ETH (cap kept), and C = S/2**16 ≈ 549 ETH, and the period is about 1,573 epochs, or about 7.0 days. The Rationale summarizes this as an exit limit about 4 times the current capped value and exactly 2 times the old uncapped baseline, and a consolidation limit about 2 times larger. It also lists possible future cases. Removing the activation cap gives about 6.0 days (1,348 epochs), disabling consolidation gives about 10.9 days (2,457 epochs), and doing both gives about 8.4 days (1,894 epochs). Removing the activation cap shortens the period by only about a day and keeps it near one week, so the authors judged that this configuration can be kept as is if the cap is later removed.
Design rationale and why consolidation is urgent
The source gives four reasons. First, a separate consolidation limit can be adjusted independently. It can be raised to speed up validator set consolidation and lowered after a large consolidation wave has passed. Second, the exit limit scales with total stake again, and the consolidation limit stays proportional too. Third, activation keeps the EIP-7514 cap unchanged. Fourth, even after accounting for the different safety impact of exits and activations, the weak subjectivity period stays near one week, so the authors consider safety and functionality well balanced. The Motivation also explains why consolidation is urgent. Under current conditions, even running activations and exits at full capacity around the clock would take about 1.5 years to reduce the roughly 32 million ETH of 0x01 stake, and filling the consolidation queue completely would take about 1.3 years. Moreover, deposit throughput is also needed for new stake, so there is no guarantee it can be used for consolidation. A recent case in which over 1 million ETH arrived and monopolized the queue for about 20 days is an example.
Compatibility, document status, and core developer call records
The consensus rules change, so this is not backward compatible and must be activated as part of a scheduled network upgrade. The constant names carry a GLOAS suffix and the code comments are marked [Modified in Gloas:EIP-8061], which shows the specification is written against Gloas. The source status is Last Call, with a deadline of 2026-11-01. The core developer calls have not yet decided on fork inclusion. It was discussed at ACDC #185 on August 20 and ACDE #246 on September 24, but no decision was made. At ACDT #97 on September 21, the Glamsterdam CL block serving window and the BAL retention period were not settled on that call and were deferred to asynchronous discussion and ACDE. Three options were raised: keeping 33,024 epochs, reducing to about 14,299, and reducing to 8,192 (EIP-8383, a Hegotá candidate and therefore out of scope). It was agreed not to block the testnet launch.