Set how much ETH stays in your validator. Let rewards add to your stake up to that amount. Receive the excess automatically.
Double signing, browser edition: one validator, two tabs.
Ethereum gives stakers two fixed options: receive rewards above 32 ETH, or let them compound up to 2,048 ETH.
Each partial withdrawal starts with a request from the withdrawal address. The transaction has a gas cost and a request fee. The exit queue can add a delay before the rewards become available.
Stakers use rewards for operating costs or as income. They may also want those rewards to increase their stake.
Solo stakers run validators with their own ETH. Rewards can cover hardware, electricity, or other expenses.
A service runs the validator, but the client controls its withdrawal address. This is a non-custodial staking service.
Even a large operator can serve many clients with less than 2,048 ETH each. It cannot send withdrawal requests for them. Each client must send their own requests.
In some pools, operators supply a bond: ETH that can cover penalties. The pool supplies the rest of the stake. A full 2,048 ETH validator can require more bond than a home staker can supply.
Stakers who need automatic rewards can keep separate 32 ETH validators. Consolidation into fewer 0x02 validators would replace those withdrawals with manual requests below 2,048 ETH.
P2P.org reports that some clients keep separate 32 ETH validators to receive automatic rewards. EIP-8148 would let these clients consolidate and keep automatic withdrawals at a threshold they set.
This proposal changes withdrawals from the validator balance. It does not change transaction fee or MEV payments from the execution layer.
EIP-8148 lets each 0x02 validator use its own sweep threshold. This is the balance above which Ethereum sends automatic withdrawals.
Below the threshold, rewards stay in the validator and increase its stake. Above it, Ethereum sends the excess balance to the withdrawal address through the automatic withdrawal sweep.
The sweep sends the excess in each cycle. You receive it automatically, without a transaction or fee.
Ethereum uses the effective balance to calculate rewards and voting weight. It updates in steps and is capped by the threshold. It must be at or above the threshold before automatic withdrawals start.
Select a value from 32 to 2,048 ETH, in steps of 1 ETH. There are two ways to set it.
Only the withdrawal address can change the threshold. This keeps control with the staker, including when someone else operates the validator.
The new threshold must be at or above the validator balance when the network processes the request.
Set the threshold to the amount you want to keep staked. The sweep sends rewards above that threshold to your withdrawal address.
The sweep sends further rewards in later cycles. The interval between withdrawals depends on the sweep cycle.
You deposit 128 ETH into a new 0x02 validator with a 128 ETH sweep threshold. The validator keeps 128 ETH staked. The sweep sends the rewards to your withdrawal address.
For a balance of 128.2 ETH, the next sweep works as follows:
Before you add stake, make sure the threshold is high enough. If you increase it, wait for the network to accept the change. Then add ETH or transfer stake from another validator through consolidation. The sweep uses the total balance, so it can also withdraw deposits above the threshold.
To set a threshold below the current balance, first make a partial withdrawal. After it completes, set the new threshold. This preserves the normal withdrawal queue.
Custom thresholds are optional. At activation, registered 0x02 validators keep the 2,048 ETH default. Rewards still compound below it, and the sweep automatically withdraws the excess above it.
The change is backward compatible for stakers. If you do nothing, validators with 0x00, 0x01, or 0x02 credentials keep their existing withdrawal behavior.
For protocol details, start with the EIP specification, then see how clients validate a threshold change, calculate sweep withdrawals, and update effective balance.
EIP-7251 lets operators move stake into fewer 0x02 validators. EIP-8148 lets them keep automatic reward withdrawals at a balance they select.
256 ETH, either way
Today · 0x01
8 × 32 ETH
32 ETH threshold per validator
With EIP-8148 · 0x02
1 × 256 ETH
256 ETH custom threshold
Custom thresholds let more stakers consolidate, so fewer validators send votes for the network to process. Proposals for faster finality also use a smaller validator set. The same flexibility lets staking pools design smaller 0x02 validators with automatic reward withdrawals. Each pool sets its own bond requirements.
For operator context, read about validator consolidation, then watch the discussions about smaller staking setups and operator bond requirements.
EIP-8148 adds a system contract, a request type, and a threshold for each validator. Requests and withdrawals use mechanisms clients already implement.
EIP-7002 defines the queue and fee model. EIP-7685 defines how execution clients send requests to consensus clients.
Clients already run the withdrawal sweep and update effective balances.
Validator container unchanged.Implementing EIP-8148 in a client? Start with the protocol specification, follow the beacon-chain changes, and review the system contract implementation.
EIP-8148 is proposed for Hegotá. The specification, system contract, and Prysm proof of concept are available for review.
Next steps: other client implementations, devnets, the system contract audit, and a decision on Hegotá inclusion.
Manual withdrawals let you select an amount each time. Each request has a gas cost, a request fee, and a possible queue delay.
A custom threshold lets the sweep send the excess balance automatically. You do not need a new request for each withdrawal.
No. Custom thresholds are optional. At activation, registered 0x02 validators keep the 2,048 ETH default. The withdrawal rules for 0x00 and 0x01 validators stay the same.
You can use a custom threshold after switching to 0x02 under EIP-7251, without creating a second validator. The switch starts with the 2,048 ETH threshold.
After activation of EIP-8148, the withdrawal address can send a request for a custom threshold.
The partial withdrawal mechanism stays available with the same eligibility rules, fees, and queue delay. A custom threshold does not change the exit rules.
The validator must have 0x02 credentials and must not have started its exit. The request must come from its withdrawal address.
The threshold must be from 32 to 2,048 ETH, in steps of 1 ETH. It must be at or above the validator balance when the consensus layer processes the request. Rewards can increase that balance before processing.
If the consensus layer rejects the request, the threshold stays the same. There is no fee refund.
Each request has a gas cost and a request fee. The minimum request fee is 1 wei.
The fee mechanism has a target of two requests per block across the network. The fee increases with excess demand. Earlier demand can keep the fee above its minimum.
With a threshold in the initial deposit, you do not send a threshold request.
A multisig or contract can send the request if it is the withdrawal address. The contract must have a function that sends the request to the system contract. The consensus layer compares the caller address with the withdrawal address. The consensus layer rejects a request from a different address.
Each request contains one validator public key. A contract withdrawal address can send more than one request in one transaction. Each request has a fee.
The system contract sends up to 16 requests per block to the consensus layer. A long queue can increase the time before processing. Network demand can increase the request fee.
Read the validator’s entry in validator_sweep_thresholds in the beacon state. Make sure that it contains the value you set.
The transaction receipt shows the result of the contract call. The beacon state shows the threshold after request processing.
The fork sets defaults for registered validators. It does not read a threshold from their credentials.
For a new validator, the first deposit contains the credentials. A zero threshold or a value outside 32–2,048 ETH gives the 2,048 ETH default. Top-up deposits do not replace these credentials or change the threshold.
The list keeps thresholds outside the Validator container. It uses the validator index, as the balance list does.
Each threshold is a uint64 value in Gwei: eight bytes before list and database overhead. The withdrawal sweep and effective balance updates read this value.
Custom thresholds and a higher maximum effective balance have different effects. A higher maximum lets each validator hold more stake. A custom threshold sets the balance for automatic withdrawals below that maximum.
The authors keep these changes in different proposals to limit the scope of EIP-8148. They explain the trade-off in the proposal discussion.
Node operators are backing EIP-8148 for a practical reason: consolidate validators and keep rewards accessible. See validator signals, operator use cases, Hegotá priorities, and feedback on the design.
9 signals · 9 yes · 0 no · 0 abstain
49,330 ETH represented
Langers · Core team
The Rocket Pool core team support this EIP.
We still have a lot of design work to confirm but we believe this EIP will support our migration to 0x02 validators.
Node operator
Blockdaemon supports EIP-8148 and would like to see it considered for Hegotá.
We run Ethereum validators for a large number of institutional clients, and a configurable sweep threshold is one of the most frequently requested features we hear from them. The reason is nearly always the same. Institutions need rewards to arrive as a predictable, automatic stream.
Andrew · Node operator
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.
Amir · Node operator
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.
Yash · Node operator
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.
Node operator · Solo staker
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.
Solo staker
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.
Ethereum Foundation researcher
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.
EIP-8148 is Proposed for Inclusion in Hegotá. The final scope is still under discussion.
Help client teams review the proposal for Hegotá. Rank it, describe how your validators would use it, or comment on the specification.
Compare EIP-8148 with the other Hegotá proposals. Explain your ranking on Forkcast.
Rank on ForkcastDescribe how your validators would use custom thresholds. EthVA weights feedback by stake.
Give feedback on EthVAAdd a use case, question, or implementation concern to the Ethereum Magicians thread. Give the reasons for each change.
Comment on Magicians