EIP-8061 - Increase churn limits

Created 2025-10-17
Status Draft
Category Core
Type Standards Track
Authors
Requires

Abstract

This EIP triples the global churn limit, by quadrupling the churn allocated to activations and exits and doubling the consolidation churn. It does so by introducing a separate churn limit quotient for consolidations, so that it can be adjusted independently of activations and exits. The choice of parameters balances maintaining a long weak subjectivity period (~6 days), while allowing for faster consolidation of the validator set, in turn accelerating the timeline to a protocol with faster finality, as well as relieving deposit and exit queue congestion.

Motivation

EIP-7514 introduced an activation cap of 8 validators per epoch (now 256 ETH per epoch) to prevent overly rapid validator set growth. EIP-7251 extended this cap to exits, in part to maintain symmetry between the two queues, but most importantly to make room for the newly introduced consolidation operations. With the process of validator set consolidation having begun, the validator set has already decreased from a peak of roughly 1.1 million validators to about 1.02 million, and the original concern of runaway validator set growth has been addressed.

Given this trajectory, the remaining reason to keep the churn dedicated to activations and exits lower than the maximumg given by the CHURN_LIMIT_QUOTIENT is to allow for consolidations, as one consolidation is equivalent to one activation and an exit, and should therefore consume as much churn. However, doing so with a fixed cap prevents the activation and exit churn limit from being proportional to total stake, which, all else being equal, leads to longer queues as stake grows. Moreover, the CHURN_LIMIT_QUOTIENT is set quite conservatively in the first place, requiring more than 3 months for 1/3 of the validator set to exit, a time which would now be more than doubled due to the cap.

Recent episodes have stressed for more headroom to improve liquidity and staking user experience, as the exit queue has stretched beyond forty days as a consequence of the mass exit of Kiln validators, while the activation queue beyond twenty days due to mass inflows from staking ETFs. Long queues degrade user experience, slow operator response to market or operational events, and keep capital idle. They also reduce the network’s ability to reconfigure stake more quickly after adverse events, for example to regain finality (a double-edged sword, as preventing double finality is the reason these queues exist in the first place, as discussed in the security section).

Moreover, all churn-limited operations are useful for shrinking the validator set: consolidations are the dedicated operation, but exit-and-re-deposit have been the most used path so far, and are the only path for staking setups where withdrawal credentials point to an immutable smart contract (not able to initiate a consolidation operation). Increasing churn limits can then shorten the path to a smaller validator set and, in turn, the path to a protocol with much faster finality. Under today’s parameters, even the best-case timelines are long: using only activations and exits, fully saturated around the clock, shrinking the roughly 32M ETH of 0x01 stake would take on the order of ~1.5 years; dedicating the consolidation queue continuously would still take ~1.3 years. However, deposit capacity is also needed for new stake and is thus far from guaranteed to be available for consolidations (as evidenced by the recent >1M inflows), while adoption of the consolidation operation has been very low up to this point, with most consolidations still occurring via the exit-and-re-deposit path. Moreover, the exit-and-re-deposit path has costs (opportunity cost from missed rewards) proportional to the length of the deposit queue, so that increasing the activation churn limit leads to not only faster consolidation times, but also weaker incentives against consolidation in the first place.

The EIP proposes to address these issues by:

Considerations around stake growth

An increase to the activation churn limit might bring about a faster growth to the staking deposit size, in a situation where the current staking level already is sufficient to uphold security. However, keeping the churn limit lower than what is necessary for upholding security—in order to prevent stake from entering (and exiting)—degrades welfare for both existing and prospective stakers. Making stake more liquid, as proposed in this EIP, is an opportunity to improve staker welfare. Arguably, existing solo stakers and new entrants suffer the most from a lack of liquidity today. A low churn limit also does not prevent new willing stakers from joining, eventually. It only decreases the equilibrium deposit size to the extent that a lower liquidity reduces staker utility, making stakers require a higher yield to stake.

In essence, the right knob for controlling the equilibrium staking level is the issuance reward curve. Using the churn limit is not suitable, particularly when we suspect that lower liquidity degrades the staking experience for solo stakers the most. Increasing the churn limit and moderately reducing the yield would arguably improve welfare while maintaining the same equilibrium staking level. Of course, a change to the issuance curve is more consequential and controversial. Although we may think it is the "right knob", it may not be available to us in the near term. However, an artificially low churn limit is certainly the "wrong knob" for addressing the staking equilibrium, and we must instead address each concern by shifting the timelines under which we tune the "right knob".

In conclusion, the moderate long-term effect on the equilibrium staking level is only due to improved welfare—where solo stakers may be relatively better off. Concerns regarding the equilibrium staking must be addressed through the issuance reward curve. This EIP strengthens the case for lowering the issuance yield, but that policy should be considered independently.

Specification

The CHURN_LIMIT_QUOTIENT is halved, from 2**16 to 2**15, and fully dedicated to activations and exits, as it was prior to the introduction of a cap in EIP-7514 and of consolidations in EIP-7251. Consolidations now have their own dedicated churn, determined by CONSOLIDATION_CHURN_LIMIT_QUOTIENT. This is set here to 2**16, so that consolidations are allocated half as much churn as activations and exits, and a third of the total churn. Finally, get_balance_churn_limit simply sums up the two churns to determine the global one, which is now exclusively used as an input to the calculation of the weak subjectivity period (otherwise unchanged).

Configuration

Name Value
CHURN_LIMIT_QUOTIENT_GLOAS uint64(2**15) (= 32,768)
CONSOLIDATION_CHURN_LIMIT_QUOTIENT uint64(2**16) (= 65,536)

Churn computations

def get_activation_exit_churn_limit(state: BeaconState) -> Gwei:
    """
    Per-epoch churn limit for activations + exits (shared).
    Derived from total active balance and rounded to EFFECTIVE_BALANCE_INCREMENT.
    """
    churn = max(
        MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA,
        get_total_active_balance(state) // CHURN_LIMIT_QUOTIENT_GLOAS
    )
    return churn - churn % EFFECTIVE_BALANCE_INCREMENT
def get_consolidation_churn_limit(state: BeaconState) -> Gwei:
    """
    Per-epoch churn limit reserved for consolidations (EIP-7521)
    Derived from total active balance and rounded to EFFECTIVE_BALANCE_INCREMENT.
    """
    churn = get_total_active_balance(state) // CONSOLIDATION_CHURN_LIMIT_QUOTIENT
    return churn - churn % EFFECTIVE_BALANCE_INCREMENT
def get_balance_churn_limit(state: BeaconState) -> Gwei:
    """
    Total per-epoch churn used in weak subjectivity accounting.
    Sum of activations+exits and consolidations.
    """
    return get_activation_exit_churn_limit(state) + get_consolidation_churn_limit(state)

Rationale

Backwards Compatibility

This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade.

Test Cases

TODO

Security Considerations

Weak subjectivity period

With MIN_VALIDATOR_WITHDRAWABILITY_DELAY = 256 epochs, the weak subjectivity period (in epochs) for a 10% safety decay target is:

$\text{WS}_{\text{epochs}} = 256 + \frac{0.1 \cdot \text{total-stake}}{2 \cdot \big(\text{activation-exit-churn} + \text{consolidation-churn}\big)}$

In days, it is $\text{WS}_{\text{epochs}} / 225$.

Under this EIP:

Hence the sum is $\text{total-stake}\cdot(1/2^{15} + 1/2^{16})$, and the total cancels out in the fraction. This yields:

$\text{WS}_{\text{epochs}} = 256 + \frac{0.1}{2\cdot(1/2^{15}+1/2^{16})} \approx 1348$

$\Rightarrow\ \textbf{WS} \approx \mathbf{6\ \text{days}}$

If consolidations were disabled (i.e., only activations and exits contribute), then:

$\text{WS}_{\text{epochs}} = 256 + \frac{0.1}{2\cdot(1/2^{15})} \approx 1894 \Rightarrow\ \textbf{WS} \approx \mathbf{8.4\ \text{days}}$

On the other hand, the current period is:

$\text{WS}_{\text{epochs}} = 256 + \frac{0.1}{2\cdot(1/2^{16})} \approx 3523 \Rightarrow\ \textbf{WS} \approx \mathbf{15.7\ \text{days}}$

Copyright

Copyright and related rights waived via CC0.