This EIP proposes an optional mechanism to set custom balance thresholds for sweep withdrawals for compounding withdrawal credentials (0x02, 0x03) validators. This mechanism allows validators to specify above which balance they want their rewards to be swept to their withdrawal address, providing greater flexibility and control over their staking rewards.
2026-08-26: EIP and consensus specs updated to limit effective balance at custom sweep threshold and support custom sweep threshold setting at validator registration using free bytes in WCs
Nice, this EIP checks out with respect to the concerns outlined in EIP-8068 as far as I can tell. It restricts the sweep withdrawal threshold to the EB (whole ETH at the moment), so no new gaming vectors there.
Hi, @yorickdowne! We can indeed increase maxEB or eliminate it completely. However, adding this directly into this EIP will make it heavier and can delay possible inclusion. Since changes to maxEB are complimentary to the custom thresholds but not required, I would rather keep them separate
EIP and specs were updated to limit the effective balance at the custom sweep threshold and support the custom sweep threshold setting at validator registration using free bytes in WCs.
Now this EIP fully covers all uncovered edge cases and can serve as a useful tool for future changes to MAX_EFFECTIVE_BALANCE. If implemented, every 0x02 validator will have custom sweep threshold set (either to the current MAX_EFFECTIVE_BALANCE or any allowed custom value). That means that CL devs can change MAX_EFFECTIVE_BALANCE and all of the current 0x02 validators will have an opt-in path to use it or stay at the old value.
EIP 8148 is the key to unlocking validator consolidations for all validator operators.
Why? Because validator type 0x02 was flawed in is original design and failed to consider validator behavior along the following lines:
It failed to recognize that many validator operators (both pro and solo) need predictible income in order to pay taxes, business and living expenses, etc. While 0x01 validators provide for this ability with their automated sweep feature at 32 ETH, 0x02’s need for an Ethereum transaction below the 2048 ETH threshold followed by a highly unpredictable time in a withdrawal queue (a poor UX in itself) removes the predictible income nature of the 0x01 validator.
The 2048 ETH threshold for automated sweeping is too high for both smaller operators and potentially for larger operators too. That level is so high that each validator key would now be worth ~$5 million with ETH at $2,500 (or potentially ~$20 million per key with ETH at $10k) eliminating the possibility of its adoption by the vast majority of solo stakers and potentially also being too high for professional operators that might prefer a lower risk-per-key threshold of, say, $500k -or $1mil, etc. If the 0x02 automated sweep level was configurable, it would encourage a far greater lavel of validator consolidation than we have experienced so far.
Those operators that do consolidate to 0x02 at some number less than the 2048 ETH threshold are now trapped by the unpredictable timing of withdrawal cashflow that 0x02 demands. The best solution to mitigate this problem is EIP 8148 to make the sweep threshold configurable.
Given that a dramatically smaller validator set makes almost every ambitious consensus redesign easier and that Ethereum also wants many independent operators (not necessarily millions of validator indices), EIP 8148 helps encourage both of these two ideals simultaneously. It deserves vigorous support.
We believe EIP-8148 could bring meaningful benefits to institutional and non-custodial staking by improving capital efficiency and operational flexibility beyond the 32 ETH model.
We support further discussion and believe configurable MaxEB would be valuable for Node Operators and staking protocols.
I run 48 Lido CSM validators, alongside a few solo 0x02 compounding validators.
Personally I do not mind letting rewards accrue on my solo validators. But I think EIP-8148 would be really useful for a future version of CSM.
Being able to choose a lower sweep threshold would make 0x02 much more workable for CSM operators. You could compound into more effective-balance increments, but still have rewards sweep automatically at a level that makes sense for you instead of only at 2,048 ETH.
If CSM could work this way, I’d be comfortable running more validators through it. I think that would help bring more stake to independent operators and improve decentralisation.
So from my side: I support EIP-8148 as an optional feature!
Kukis Global, a node operator in the Lido Curated Module, supports EIP-8148 for Hegotá.
We believe it could bring meaningful benefits to institutional and non-custodial staking by improving capital efficiency and operational flexibility beyond the 32 ETH model. For node operators and staking protocols, a configurable per-validator sweep threshold is what makes consolidation under EIP-7251 practical: rewards keep arriving on the sweep as they do for 0x01 validators today, with no permanent triggered-withdrawal pipeline to build and run.
We support further discussion and would be glad to help test once client implementations are available.
From a node operator perspective, we are supportive of EIP-8148 and see configurable sweep thresholds as a valuable improvement for Ethereum staking, particularly as the ecosystem moves towards validator consolidation and broader adoption of 0x02 withdrawal credentials.
Validator consolidation brings clear benefits by reducing validator count and associated network overhead. However, the current fixed 2048 ETH automatic sweep threshold creates an unnecessarily rigid operating model. We think operators and stakers should have the flexibility to determine how much ETH they want to maintain within a consolidated validator.
A configurable sweep threshold provides exactly that flexibility. Operators could benefit from consolidation while selecting a threshold that better reflects their operational, liquidity and risk requirements, rather than having 2048 ETH as the only automatic sweep point.
We also see significant operational value in retaining the simplicity of automatic withdrawals. Relying on manual partial withdrawal requests for routine reward management adds additional transactions, operational processes and dependency on withdrawal queue conditions. Configurable automatic sweeps provide a much cleaner mechanism.
Importantly, we see this as useful beyond any particular staking protocol. Solo stakers, institutional stakers and professional node operators can all have different requirements around liquidity, consolidation and validator balances. Providing this flexibility at the protocol level makes consolidated validators more practical for a broader range of Ethereum participants.
From our perspective at Launchnodes, EIP-8148 complements validator consolidation very well. It preserves the efficiency benefits of consolidation while giving stakers greater control over how their validators operate.
We are supportive of the proposal and believe this would be a useful addition to Ethereum’s staking infrastructure.
We at P2P org support this EIP.
We run validators for a broad mix of institutional clients who want to migrate but stay on 0x01 specifically because 0x02 breaks their reward flow, as rewards stop arriving at the withdrawal address on a predictable schedule.
Partial withdrawals have not been a workable substitute for us, for the reasons already listed in the EIP plus one operational one: each request is a signed EL transaction per validator. Where the withdrawal address sits behind a multisig or an internal approval process.
The net effect today is that the network does not get the consolidation. Stake that would happily run at 512 or 1024 ETH per validator stays at 32, because reward delivery matters more to the client than validator count does.
RockX team support this EIP-8148.
Custom sweep thresholds allow validators to maintain a more predictable and timely reward flow to the withdrawal address, making 0x02 validators much more flexible and practical to operate.
Thank you for putting forward EIP-8148 and driving it through the consensus specs.
The rigid dichotomy under EIP-7251—either sweeping every gwei above 32 ETH (0x01) or locking all yield into auto-compounding until the full 2,048 ETH cap (0x02/0x03)—creates severe operational friction for Liquid Staking (LST) and Restaking (LRT) protocols.
Below is an analysis of how EIP-8148 directly resolves these protocol-level constraints, alongside key implementation considerations:
1. Unlocking Capital Efficiency & Predictable Cash Flows for LSTs/LRTs
Liquidity Buffer Maintenance: LST/LRT architectures require constant, predictable inflows of liquid ETH to satisfy redemptions and protocol fees without forcing validator exits. Under pure EIP-7251 compounding, staking pools either have to sacrifice compounding benefits entirely (remaining on 0x01) or absorb the transaction overhead of automated keeper bots calling execution-layer partial withdrawal requests to skim rewards.
Granular Validator Sizing: Node operators in pooled ecosystems often have optimal operational sizes (e.g., 64, 128, or 256 ETH per validator) to balance peer-to-peer load, slashing risk distribution, and node runner collateral requirements. EIP-8148 allows pools to consolidate validator counts to their ideal risk-weighted balance while letting native consensus sweeps stream all excess yield directly back to redemption pools.
Elimination of Keeper Gas Drag & MEV Risk: Replacing execution-initiated partial withdrawals with automated consensus sweeps eliminates ongoing L1 gas overhead, smart contract surface area, and reentrancy/MEV exposure associated with managing withdrawal request queues on-chain.
2. State Footprint & Byte-Packing Ergonomics (August 2026 Update)
Encoding the threshold into unused bytes of the 32-byte Withdrawal Credential (WCs) array is particularly well-suited for institutional and programmatic stakers:
Zero Net-New State: By leveraging existing credential space, consensus clients evaluate sweep eligibility during standard sweep rounds with zero additional state reads or SSZ schema expansion.
Deterministic Deployment: LST staking contracts can programmatically generate deposit data with target thresholds baked into the credential bytes at deposit time, requiring no post-registration execution-layer configuration.
3. Considerations for Protocol Integrators
Threshold Mutability vs. Validator Re-allocation:
LST protocols frequently adjust validator allocation targets based on deposit pool depth and queue dynamics. Since encoding the threshold into WCs sets it at registration, what is the envisioned path for active validators seeking threshold adjustments? Does updating the threshold require a future withdrawal credential rotation envelope, or is it intentionally immutable per validator lifecycle?
Hysteresis & Downward Divergence:
If a compounding validator experiences inactivity leakage or penalties that dip its balance below threshold $T$, does the standard 0.25 ETH hysteresis upward apply until $T$ is restored, and does effective_balance cap strictly at $\min(\text{balance}, T)$? Clarifying client consensus rules here is critical for LST accounting contracts that track total pooled assets.
Integration with Staking Tooling & Deposit Contracts:
Ensuring that deposit generation tools, institutional custody APIs, and LST deposit contracts correctly format and pack the threshold bytes without invalidating existing credential validation routines will be vital prior to mainnet activation.
Everstake supports EIP-8148. From a node operator perspective, configurable sweep thresholds would make the transition to 0x02 validators significantly more practical, allowing operators to benefit from validator consolidation while maintaining predictable reward flows and greater operational flexibility.
We believe this is a valuable improvement for Ethereum staking infrastructure and support its consideration for Hegota.
I’m adding my support for EIP-8148 as a solo staker with institutional interests.
EIP-7251 was meant to shrink the validator set, but adoption is held back in part because 0x02 loses the automatic reward stream that 0x01 provides. Operators and their clients choose predictable payouts over consolidation, so stake that could run at higher balances per validator stays at 32 ETH.
A custom sweep threshold removes that trade-off, which matters for a few reasons:
A smaller validator set. More consolidation means fewer validators, a lighter beacon state, and less signature and p2p load. That moves us closer to faster finality.
Decentralization. Large operators can automate partial withdrawals. Solo stakers and small operators mostly can’t, so today the benefits of consolidation go mainly to the big players. This EIP makes 0x02 practical for everyone.
Less withdrawal-queue pressure. Automatic sweeps replace a steady flow of manual partial-withdrawal requests that compete for space in the queue.
Thanks to @dgusakov for driving this. Like the many other voices of support, I’d love to see it in Hegota.