Ethereum is considering a change that would let compounding validators set how much ETH should remain on a validator before excess rewards enter the network’s automatic withdrawal sweep.
An Aug. 20 edit to draft EIP-8148 lowered the proposal’s minimum custom threshold from 33 ETH to 32 ETH and added a way to set the initial threshold when a new validator is created. If activated, the proposal would let 0x02 validators select a level between 32 ETH and the current 2,048 ETH default. The change would affect reward-sweep timing while Ethereum’s existing exit rules continue to govern principal withdrawals.
Ethereum’s 32 ETH change controls reward-sweep timing
Ethereum currently treats its two execution-address withdrawal credentials differently.
Validators using legacy 0x01 credentials have a 32 ETH effective-balance cap. Any balance above 32 ETH is periodically swept to the withdrawal address, so those rewards stop compounding on the validator.
Compounding 0x02 validators can increase their effective balance in 1 ETH increments up to 2,048 ETH. Under Ethereum’s current withdrawal-credential rules, their balance is automatically swept only after it exceeds 2,048 ETH. Accessing ETH below that level requires a manually requested partial withdrawal.
| Validator setup | What happens to rewards | Automatic sweep threshold |
|---|---|---|
| Current 0x01 | Excess rewards stop compounding once swept | Above 32 ETH |
| Current 0x02 | Rewards compound in 1 ETH effective-balance increments | Above 2,048 ETH |
| Proposed 0x02 | Rewards compound until the selected level | Custom level from 32 ETH to 2,048 ETH |
EIP-8148 would let a new 0x02 validator encode an initial threshold in the deposit that creates it. An absent or invalid custom value would default to 2,048 ETH until a valid post-creation change is processed. Existing compounding validators would also begin at the default and could later submit a valid request.
The draft prevents that setting from becoming an immediate withdrawal tool. A post-creation request must set the threshold at or above the validator’s current balance. If a creating deposit encodes a threshold below the amount deposited, the protocol would ignore it and use the default. A validator seeking a lower level would first have to use the standard partial-withdrawal process.
Once a valid custom threshold is in place, future rewards above it would become eligible for Ethereum’s normal automatic sweep. Principal withdrawals would still use Ethereum’s existing partial-withdrawal or full-exit paths, followed by ordered withdrawal processing.
Why the stake affected is larger than the validator count
Compounding credentials remain unusual by validator count, yet they already cover a significant amount of ETH.
The latest accessible Pectrified snapshot, dated July 28, counted 16,926 active 0x02 validators. That was 1.91% of active validators, but they held 13.36 million ETH, or 32.43% of active stake.
The gap means validator count alone understates the amount of ETH exposed to the 2,048 ETH default. These figures establish scale rather than an increase in provider concentration. The proposal changes a balance-management setting, while operator adoption and threshold choices remain unresolved.
Ethereum exit queues and sweep cycles measure different backlogs
Current queue data also shows that automatic sweep eligibility and receipt occur at different stages. A live Validator Queue snapshot on Aug. 25 showed 160 ETH in the exit queue, with an estimated four-minute wait. The same dashboard estimated that the network-wide automatic sweep cycle would take 7.8 days.
Those figures describe different stages. The exit queue governs validators leaving the active set, while the sweep cycles through eligible validator balances. The cited queue data provides exit and sweep-cycle estimates while omitting a separate public backlog for partial-withdrawal requests. Measuring how much congestion the proposal could remove would require that missing data.
EIP-8148’s narrower benefit is that rewards crossing a custom threshold could enter the automatic sweep without repeated partial-withdrawal requests. When those rewards would become available to a staking customer is a separate product question.
Lido’s documentation says staking and execution-layer rewards feed its pooled accounting, while stETH holder balances are updated through oracle-driven rebases. Coinbase Prime says rewards on Pectra-enabled 0x02 validators compound and can be claimed through its existing partial-withdrawal process, subject to stated conditions.
Threshold policy remains unresolved for both services in the supplied materials. Their current models show how validator-level sweep timing can diverge from customer payout timing. A lower threshold could make ETH leave a validator sooner without determining when a service credits, rebases or releases value to users.
The proposal therefore transfers timing discretion at the validator layer, while broader customer liquidity remains a product-policy outcome. Ethereum would supply the optional validator setting; operators and staking products would determine how, or whether, the resulting reward flow changes what customers experience.
EIP-8148 remains at the proposal stage
EIP-8148 remained marked Draft on Aug. 25. Forkcast listed it as proposed for Hegotá, while the related consensus-spec change was merged on Aug. 24.
Fork placement, activation timing and final implementation all remain pending. The Aug. 20 edit made the draft more concrete by adding a 32 ETH floor and deposit-time selection. Ethereum mainnet continues to use the existing rules.
Until developers select and finalize the proposal, the current split remains in force: automatic sweeps above 32 ETH for 0x01, compounding up to the 2,048 ETH default for 0x02, and manual partial withdrawals for compounding validators that want rewards sooner.
Featured,Staking,Technology,ethereum,Lidoethereum,Lido#Ethereum #EIP8148 #draft #custom #sweep #thresholds1787682253
