The problem EIP-8148 addresses
EIP-8148 · Proposed for Hegotá
Custom sweep threshold for validators
Set how much ETH stays in your validator. Let rewards add to your stake up to that amount. Receive the excess automatically.
Interesting case
You can set the threshold below your current balance. It takes two operations.
- Send a partial withdrawal
- Once the balance drops, set it to 32 ETH
Why this proposal matters ↗
Follow the Hegotá roadmap ↗
Proposals under consideration
Explore the client changes ↗
Beacon-chain specification
Review the system contract ↗
Execution-layer implementation
Video
Presentations about EIP-8148
The problem
Compounding makes rewards harder to access
Stakers use rewards for operating costs or as income. They may also want those rewards to increase their stake. Today, Ethereum gives them two fixed options.
Manual withdrawals add work and delay
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.
Even a large operator can have clients with less than 2,048 ETH each. When clients control their own withdrawal addresses, the operator cannot send withdrawal requests for them. Each client must send their own requests.
The need for automatic rewards can prevent consolidation
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.
This proposal changes withdrawals from the validator balance. It does not change transaction fee or MEV payments from the execution layer.
Hear directly from operators in the EthStaker discussion and ACDC #179. The EIP motivation explains why automatic sweeps matter.
The solution
Compounding with a threshold you set
EIP-8148 lets each 0x02 validator use its own sweep threshold. This is the balance above which Ethereum sends automatic withdrawals.
How rewards move
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.
Set the threshold
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.
Example: keep 128 ETH staked
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:
- Stays in the validator
- 128 ETH
- Goes to the withdrawal address
- 0.2 ETH
The sweep sends further rewards in later cycles. The interval between withdrawals depends on the sweep cycle.
Adjust the stake later
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.
The default stays at 2,048 ETH
Custom thresholds are optional. At activation, registered 0x02 validators keep the 2,048 ETH default. Validators with 0x00 or 0x01 credentials keep their current withdrawal rules.
For protocol details, start with the EIP specification, then see how clients validate a threshold change, calculate sweep withdrawals, and update effective balance.
Effect on the network
More stakers can consolidate
EIP-7251 lets operators move stake into fewer 0x02 validators. EIP-8148 lets them keep automatic reward withdrawals at a balance they select.
Fewer validators for the same stake
Today · 0x01
8 × 32 ETH
32 ETH threshold per validator
With EIP-8148 · 0x02
1 × 256 ETH
256 ETH custom threshold
Fewer validators send fewer votes for the network to process. Proposals for faster finality use a smaller validator set.
Smaller validators for staking pools
In some pools, operators supply a bond: ETH that can cover penalties. The pool supplies the rest of the stake. The bond for a full 2,048 ETH validator can be too large for a home staker.
Custom thresholds let 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.
For client developers
Built on mechanisms clients already use
EIP-8148 adds a system contract, a request type, and a threshold for each validator. Requests and withdrawals use mechanisms clients already implement.
Execution layer
Already in use
EIP-7002 defines the queue and fee model. EIP-7685 defines how execution clients send requests to consensus clients.
New in EIP-8148
- Add a system contract that accepts a validator public key and the new threshold.
- Add a threshold request type for transfer to consensus clients.
Consensus layer
Already in use
Clients already run the withdrawal sweep and update effective balances.
New in EIP-8148
- Store thresholds in a separate list in the beacon state. Keep the
Validatorcontainer unchanged. - Process the new requests. Validate the withdrawal address, validator status, and threshold.
- Use each validator’s threshold in the current sweep and effective balance updates.
- Initialize defaults at the fork and on a switch to 0x02. Read custom thresholds from new validator deposits.
Implementing EIP-8148 in a client? Start with the protocol specification, follow the beacon-chain changes, and review the system contract implementation.
Status ·
Progress toward Hegotá
EIP-8148 is proposed for Hegotá. The specification, system contract, and Prysm proof of concept are available for review.
- EIP-8148 proposal
- Published · Draft
- Hegotá proposal
- Proposed for Inclusion
- Consensus specification
- Published in consensus-specs
- System contract implementation
- PR #54 available for review
- Client implementations
- Prysm proof of conceptOther clients pending
- System contract audit
- Pending
- Devnets
- Pending
Next steps: other client implementations, devnets, the system contract audit, and a decision on Hegotá inclusion.
Questions
Operation, fees, and compatibility
The basics
Why not use manual withdrawals?
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.
Do I have to set a custom threshold?
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.
Can I use this with one 0x01 validator?
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.
See how the consensus specification applies the default threshold during the switch.
Can I make a partial withdrawal below the 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.
Operation
What can prevent a threshold change?
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.
For the exact checks, see how the consensus layer validates a request.
How much does a threshold change cost?
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.
Can a multisig or contract send the 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.
See where the system contract records the caller and how the consensus layer checks the withdrawal address.
Does one request set thresholds for more than one validator?
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 request format and per-block queue rules.
How do I read the threshold?
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.
Client implementation
Which deposits can set a threshold?
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.
Why are thresholds outside the Validator container?
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.
Read why EIP-8148 keeps threshold data outside the Validator container, or inspect the corresponding BeaconState field.
Why does the maximum effective balance stay at 2,048 ETH?
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.
Support the proposal
Support EIP-8148 for Hegotá
Help client teams review the proposal for Hegotá. Rank it, describe how your validators would use it, or comment on the specification.
Client teams and community
Rank the proposal
Compare EIP-8148 with the other Hegotá proposals. Explain your ranking on Forkcast.
Rank on ForkcastValidators
Give validator feedback
Describe how your validators would use custom thresholds. EthVA weights feedback by stake.
Give feedback on EthVAResearchers and protocol teams
Comment on the specification
Add a use case, question, or implementation concern to the Ethereum Magicians thread. Give the reasons for each change.
Comment on Magicians