ether.fi (@ether_fi): How We Redeemed 20% of TVL Without Adding a Day to Ethereum's Exit Queue

How We Redeemed 20% of TVL Without Adding a Day to Ethereum's Exit Queue In late April 2026, a security incident at another liquid restaking token sent the market scrambling to redeem at once. Over the following month, EtherFi processed 542,792 ETH in withdrawals, 19.6% of its total value locked, in 33 days, without force-exiting validators into Ethereum's shared exit queue. Every withdrawal request became claimable within 4.9 days (median). Here is how the method worked, and why it kept EtherFi's redemptions from lengthening the wait for every other staker on Ethereum. The backdrop: one shared queue, everyone heading for the door When redemptions spike across the market, they converge on a single shared resource: Ethereum's validator exit queue. Exits are rate-limited at the protocol level, so when many stakers leave at once, the wait grows for everyone behind them. After April's rsETH incident, that is what happened. The exit queue lengthened to roughly 9 days at its peak (9.22 days on May 2, 2026), meaning a validator requesting an exit would wait well over a week before its stake could be withdrawn. The naive path, and what it would have cost everyone The obvious way to fund 542,792 ETH of redemptions is to exit validators and wait for their stake to unlock. The problem is the rate limit. Post-Pectra, Ethereum caps combined validator activations and exits at 256 ETH per epoch (MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT, 256 × 10⁹ Gwei), about 57,600 ETH per day across the entire network. Funding EtherFi's redemptions through ordinary exits would have consumed roughly 9.4 days of the whole network's exit capacity (542,792 ÷ 57,600). Stacked on a queue already near 9 days, that pushes the wait toward about 18 days, roughly two and a half weeks, for every staker in line, not just EtherFi's. One protocol's redemptions would have become everyone's problem. What EtherFi did instead: Spillover withdrawals EtherFi sourced the ETH through consolidation, a method we call Spillover: accelerated withdrawals that route around the exit queue entirely. The mechanism rests on three facts about post-Pectra Ethereum, all defined in EIP-7251: The network runs three separate, rate-limited queues: the Activation Queue (validators joining), the Exit Queue (validators exiting), and the Consolidation Queue (moving balance from a source validator into a target). Consolidation draws from its own churn budget, the network's total balance churn minus the 256 ETH per epoch reserved for activations and exits (get_consolidation_churn_limit). Because exits are capped at that 256 ETH per epoch regardless, a congested exit queue does not slow consolidations. Pectra raised the maximum effective balance for compounding validators to 2,048 ETH (MAX_EFFECTIVE_BALANCE_ELECTRA). Any balance above that ceiling is paid out automatically by the protocol's withdrawal sweep. A consolidation carries its own delay, about 27 hours (256 epochs, MIN_VALIDATOR_WITHDRAWABILITY_DELAY), but that clock runs in the consolidation queue, not behind the exit queue. The Spillover strategy in one validator: take a target validator already sitting at the 2,048 ETH ceiling. Submit a consolidation that transfers a source validator's balance into that target. The target is now over the ceiling, so on its next turn the Beacon Chain automatically sweeps the excess and pays it out. The source validator's stake is freed through the consolidation queue and the sweep, never entering the congested exit queue. When the protocol sets the source validator's exit, it spends the consolidation churn budget, not the exit churn (compute_consolidation_epoch_and_update_churn). That is the whole trick: the exit queue's congestion and the consolidation queue's are accounted separately. In this window EtherFi executed 12,315 consolidation operations to meet redemptions without adding to the queue everyone else was stuck in. The result: speed under load Withdrawal requests were claimable in a median of about 5 days, and every request in the window was claimable within 17 days (the slowest at 16.7). "Claimable" here is measured onchain: the moment EtherFi finalized a request and locked the ETH. It reflects protocol processing time, not how long a user waited before clicking claim. What Spillover does not do Spillover is fast, but it is not unlimited, and it is worth being precise about where it ends. It has a ceiling. Consolidation runs on its own churn budget, but that budget is finite (the network's total balance churn minus the 256 ETH per epoch reserved for exits). Our redemptions averaged about 16,400 ETH per day, well inside that budget. A redemption several times larger or faster would eventually saturate the consolidation queue and force a partial fallback to ordinary exits. It is shared. The consolidation queue is network-wide. If many large operators consolidated heavily at the same time, that queue would lengthen too, just as the exit queue does. It has prerequisites. It needs compounding (0x02) target validators with headroom under the 2,048 ETH cap and source validators with execution withdrawal credentials. It is an operational capability, not a default behavior. What Spillover reliably does is keep one protocol's redemptions off the queue that every other staker shares. That is the claim the data supports. Tested, not theorized EtherFi just cleared a redemption worth a fifth of its TVL in a live, ecosystem-scale stress test. And because the consolidation route never touched the shared exit queue, EtherFi's redemptions did not extend the wait for any other staker on Ethereum. The numbers