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.
The current default sweep threshold (2,048 ETH) for validators using compounding withdrawal credentials (0x02, 0x03) may not meet the needs of all validators. Some validators may prefer to accumulate rewards on the validator balance, while others may want to sweep before reaching the current threshold of 2,048 ETH. By allowing optional custom sweep thresholds, validators can optimize their reward management according to their individual strategies and preferences.
Since the introduction of the 0x02 compounding withdrawal credentials type, we have observed a very low rate of validators transitioning to 0x02. One reason is that many validators do not want to wait until they accumulate 2048 ETH in rewards before being able to participate in the automatic sweep of withdrawals. While partial withdrawals were considered a viable method for manually withdrawing portions of the validator balance, this approach was not widely adopted by staking protocols, node operators, and solo stakers for several reasons. First, it requires a user-initiated transaction to perform a withdrawal. Second, partial withdrawals utilize the general exit queue, which makes the time between partial withdrawal initiation and fulfillment unpredictable and heavily dependent on network conditions (see the recent spike in exit queue size in October 2025). This EIP aims to address this issue by allowing validators to set a custom threshold for sweep withdrawals.
A simple example illustrates the utility of this feature. Consider a validator who wishes to accumulate rewards on their validator balance until reaching 128 ETH, at which point they want to sweep the rewards to their withdrawal address. Without this feature, the validator would have to initiate partial withdrawals at certain intervals manually and wait in the partial withdrawals queue, which can be time-consuming and inconvenient. The first inconvenience is that if staking protocols widely adopt partial withdrawals at some point, the queue for these withdrawals might become long and unpredictable, similar to the exit queue. The second inconvenience is that the user must monitor the validator's balance and manually initiate partial withdrawals, which adds complexity and overhead to the staking process. The third inconvenience is the frequency with which the validator can request partial withdrawals. A 128-ETH validator will receive approximately 0.07 ETH in rewards each week. Initiating partial withdrawals TX, for such a low amount might be considered unreasonable. At the same time, the sweep cycle will likely drop to a weekly cycle relatively soon, allowing the validator to automatically receive these 0.07 ETH of rewards on their withdrawal credentials. In general, with this EIP, the validator can set their desired sweep threshold and automatically benefit from sweep withdrawals.
The proposed mechanism is completely optional and does not change anything in the default registration / withdrawal / exit process for validators. It's just an additional feature that could be ignored if not interesting, but provides a useful feature for many validators incentivizing switching to compounding validators.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
| Name | Value | Comment |
|---|---|---|
SET_SWEEP_THRESHOLD_REQUEST_TYPE | 0x03 | The EIP-7685 type prefix for set sweep threshold request |
SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS | TBD | Where to call and store relevant details about set sweep threshold request mechanism |
SYSTEM_ADDRESS | 0xfffffffffffffffffffffffffffffffffffffffe | Address used to invoke system operation on contract |
EXCESS_SET_SWEEP_THRESHOLD_REQUESTS_STORAGE_SLOT | 0 | |
SET_SWEEP_THRESHOLD_REQUEST_COUNT_STORAGE_SLOT | 1 | |
SET_SWEEP_THRESHOLD_REQUEST_QUEUE_HEAD_STORAGE_SLOT | 2 | Pointer to the head of the set sweep threshold request message queue |
SET_SWEEP_THRESHOLD_REQUEST_QUEUE_TAIL_STORAGE_SLOT | 3 | Pointer to the tail of the set sweep threshold request message queue |
SET_SWEEP_THRESHOLD_REQUEST_QUEUE_STORAGE_OFFSET | 4 | The start storage slot of the in-state set sweep threshold request message queue |
MAX_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK | 16 | Maximum number of set sweep threshold requests that can be dequeued into a block |
TARGET_SET_SWEEP_THRESHOLD_REQUESTS_PER_BLOCK | 2 | |
MIN_SET_SWEEP_THRESHOLD_REQUEST_FEE | 1 | |
SET_SWEEP_THRESHOLD_REQUEST_FEE_UPDATE_FRACTION | 17 | |
EXCESS_INHIBITOR | 2**256-1 | Excess value used to compute the fee before the first system call |
| Name | Value |
|---|---|
MIN_SWEEP_THRESHOLD | MIN_ACTIVATION_BALANCE + Gwei(1 * 10**9) (33 ETH) |
FORK_BLOCK -- the first block in a blockchain after this EIP has been activated.The new set sweep threshold request is an EIP-7685 request with type SET_SWEEP_THRESHOLD_REQUEST_TYPE consisting of the following fields:
source_address: Bytes20validator_pubkey: Bytes48threshold: uint64The EIP-7685 encoding of a set sweep threshold request is computed as follows.
Note that threshold is returned by the contract little-endian, and must be encoded as such.
The contract has three different code paths, which can be summarized at a high level as follows:
uint64 threshold value.If call data input to the contract is exactly 56 bytes, perform the following:
msg.value >= get_fee()).Specifically, the functionality is defined in pseudocode as the function add_set_sweep_threshold_request():
The following pseudocode can compute the cost of an individual set sweep threshold request, given a certain number of excess set sweep threshold requests.
When the input to the contract has zero-length, interpret this as a get request for the current fee, i.e. the contract returns the result of get_fee(). The contract reverts if any value is sent to prevent loss of funds.
At the end of processing any execution block starting from the FORK_BLOCK (i.e. after processing all transactions), call SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS as SYSTEM_ADDRESS with no calldata. The invocation triggers the following:
dequeue_set_sweep_threshold_requests())update_excess_set_sweep_threshold_requests())reset_set_sweep_threshold_requests_count())In response to the system call, the contract returns an opaque byte array of concatenated SSZ-serialized dequeued requests. There's no specific reasoning behind it, except aligning with the existing behaviour of the similar EIP, see EIP-7002, and possible simplification of the processing flow for client teams.
Each set sweep threshold request must appear in the EIP-7685 requests list in the exact order returned by dequeue_set_sweep_threshold_requests().
Additionally, the system call and the processing of that block must conform to the following:
30_000_000 (SYSTEM_TRANSACTION_GAS) and is not subject to the transaction limit cap introduced in EIP-7825.SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS, the corresponding block MUST be marked invalid.The functionality triggered by the system call is defined in pseudocode as the function read_set_sweep_threshold_requests():
The following bytecode is produced by the geas compiler from the source code in the sys-asm repository.
The set sweep threshold requests contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:
The defining feature of this EIP is allowing validators to set custom sweep thresholds for their withdrawals when using compounding withdrawal credentials (0x02, 0x03).
The Rationale section contains an explanation for this proposed core feature. A sketch of the resulting changes to the consensus layer is included below.
BeaconState container to include a validator_sweep_thresholds mapping.SetSweepThresholdRequest container to represent the set sweep threshold requests dequeued from the execution layer contract.ExecutionRequests container to include a list of SetSweepThresholdRequest items.process_set_sweep_threshold_request function to handle the processing of set sweep threshold requests from the execution layer.process_execution_payload function to include the processing of set sweep threshold requests.is_partially_withdrawable_validator predicate to take into account the custom sweep threshold.get_effective_sweep_threshold helper function to compute the effective sweep threshold for a validator.get_expected_withdrawals function to use the custom sweep threshold when determining partial withdrawals.By default, all validators will have their sweep thresholds set to the current default MAX_EFFECTIVE_BALANCE, both for existing validators and new ones. Validators can choose to set a custom threshold above their current balance by submitting a set sweep threshold request through the execution layer contract.
Most of the considerations regarding the messaging format, queue, and rate-limiting are similar to those discussed in EIP-7002 for withdrawal requests, and so we refer the reader to that EIP for more details.
The primary motivation for this EIP is to allow validators to set custom sweep thresholds for their withdrawals when using compounding withdrawal credentials (0x02, 0x03). This feature provides greater flexibility and control over how and when validators can access their staking rewards.
validator_sweep_thresholds mapping in BeaconStateTo store the custom sweep thresholds for each validator, we introduce a new mapping in the BeaconState container called validator_sweep_thresholds. This mapping associates each validator index with its corresponding sweep threshold. This approach was chosen instead of adding a new field to the Validator container to avoid modification of this type, which had not been changed since phase-0. Modification of the Validator container would have required more extensive changes to the consensus layer and potentially affected existing implementations of the applications using this container. Also, this is the standard way of adding info about validators into the state (e.g., validator balance is stored in balances field of BeaconState and several other PoS-related info have their own lists where each item corresponds to validators' data)
This design decision is made to prevent usage of the custom sweep threshold mechanism to trigger immediate withdrawals. By enforcing that the threshold must be set above the current balance, we ensure that validators cannot use this feature to bypass the standard withdrawal process. Should a validator wish to set sweep threshold below current balance, they can first withdraw down to the desired level using partial withdrawals, and then set the sweep threshold accordingly.
Unlike partial withdrawal requests, which are queued on the consensus layer, set sweep threshold requests are processed immediately upon being dequeued from the execution layer contract. This design choice simplifies the implementation and reduces the complexity of managing a separate queue on the consensus layer.
MIN_SWEEP_THRESHOLD of 33 ETHTo ensure that validators do not set sweep threshold equal to MIN_ACTIVATION_BALANCE, we introduce a minimum sweep threshold of MIN_ACTIVATION_BALANCE + 1 ETH (33 ETH). This ensures that people will opt-in to compounding withdrawal credentials only if they really want to accumulate rewards on the validator balance.
This EIP introduces backwards incompatible changes to the block structure and block validation rule set. But neither of these changes break anything related to the current user activity and experience.
Most of the security considerations regarding fee overpayment, system call failure, and empty code failure are similar to those discussed in EIP-7002 for withdrawal requests, and so we refer the reader to that EIP for more details.
Copyright and related rights waived via CC0.