Abstract

rETH is fully backed by staked ether but currently lacks a direct mechanism for stakers to signal a desire to exit. With the adoption of EIP-7002, Rocket Pool can implement execution-layer-triggered exits that respond to explicit rETH withdrawal requests without requiring coordination with node operators.

This RPIP specifies a Withdrawal Queue and validator-selection mechanisms for minipools and megapool validators.

Motivation

rETH currently exposes stakers to liquidity risk: although they can, in principle, withdraw their stake from the beacon chain, the protocol offers no direct mechanism for rETH holders to access it. Instead, they must rely on limited in-protocol liquidity or sell rETH on the open market. This creates a dependence on secondary-market liquidity and can make rETH less attractive, especially for larger investors and users with time-sensitive liquidity needs.

Specification

This specification introduces the following pDAO protocol parameters:

Name	Type	Initial Value	Guardrail
deposit_pool_collateral_target	pct	1
exit_hysteresis	ETH	120	> 32
megapool_exit_phase	boolean	false	can’t be set to false
staking_delay	days	28	> 7
max_exits_per_call	integer	50	> 0

This specification changes the following pDAO protocol parameters:

Name	Type	Current Value	New Value
network.reth.collateral.target	pct	1	0

Withdrawal Queue

• A Withdrawal Queue contract MUST exist to provide the interface for pool stakers to request exits at the protocol rate.
• Starting 28 days after the upgrade that implements this RPIP, the Withdrawal Queue MUST accept rETH deposits from users to create withdrawal requests.
• The ETH value of the rETH at the time of a withdrawal request MUST be recorded.
• Canceling a withdrawal request and exiting the queue SHALL NOT be possible.

Fulfilling Withdrawal Requests

• While the Withdrawal Queue is not empty:
• ETH from new rETH mints SHALL first go towards the Withdrawal Queue.
• Redemption of rETH outside the queue SHALL be prevented to the extent possible.
• The protocol SHALL allow the Withdrawal Queue to burn rETH.
• network.reth.collateral.target SHALL be set to 0 and a new buffer for withdrawals SHALL be implemented in the deposit pool, reserving up to deposit_pool_collateral_target percent of ETH backing rETH for rETH burns.
• When megapools distribute rewards, they SHALL send ETH to the deposit pool rather than the rETH contract.
• When a withdrawal request is fulfilled, the Withdrawal Queue SHALL burn the corresponding rETH. The user SHALL receive the stored ETH value at the time of the request or at the time of the rETH burn, whichever is smaller.
• Any remaining ETH corresponding to that rETH burn SHALL be transferred to the deposit pool.

Validator Exit Selection

For this section, the withdrawal_shortfall is defined as the remaining ETH required to satisfy all pending Withdrawal Queue requests after accounting for:

• requested_exit_eth (defined in RPIP‑80),
• voluntary_exit_eth (defined in RPIP-80),
• ETH held by the rETH contract, and
• ETH held by the deposit pool.

If the withdrawal_shortfall is more than exit_hysteresis ETH, additional megapool validators MUST be selected and added to the exit list as defined in this section.

If megapool_exit_phase = false

• The protocol SHALL allow the oDAO, by majority vote, to request minipools to exit as specified in RPIP-80. The amount necessary to cover the withdrawal_shortfall minus exit_hysteresis SHALL act as a hard cap on the possible exit requests.
• The oDAO SHOULD monitor the number of voluntarily exiting minipools and only request exits after accounting for them.
• The oDAO SHOULD select minipools by prioritizing higher-commission minipools and SHOULD ignore any minipool that has received a did_not_exit_penalty within the last did_not_exit_cooldown (defined in RPIP-80).
• The oDAO MAY use time until the next validator sweep as a tie-breaker between minipools with equal commission.

If megapool_exit_phase = true

Eligible megapool validator set

The protocol SHALL initialize a set of eligible megapool validators from which validators can be selected for exit under this proposal. A megapool validator MUST satisfy all of the following conditions to be included in this set:

• stake was already called for the validator.
• The validator is not already exiting.
• When stake is called for a megapool validator, the protocol SHALL schedule the addition of that validator to the eligible megapool validator set after a pDAO-configurable staking_delay.
• When an exit request is made for a megapool validator under RPIP‑80, that validator MUST be removed from the eligible megapool validator set or the scheduled inclusion MUST be canceled.
• When notifyExit is called for a megapool validator that is still in the eligible megapool validator set, that validator MUST be removed or the scheduled inclusion MUST be canceled.

Random selection

If the withdrawal_shortfall is more than exit_hysteresis ETH and the eligible megapool validator set is non‑empty, anyone SHALL be able to call a permissionless megapool validator exit function:

• Let k = ceiling((withdrawal_shortfall - exit_hysteresis) / (32 - base_bond_array[0])).
• The protocol MUST select minimum(k, max_exits_per_call, eligible_set_size) distinct validators uniformly at random without replacement from the eligible megapool validator set.
• The protocol SHALL request the first k' of those validators to exit, following the process defined by RPIP-80, where k' is the number of validators necessary to cover withdrawal_shortfall - exit_hysteresis.

Reentry Queue

This section modifies the behavior of the deposit queue defined in RPIP-59.

• In addition to the standard_queue and express_queue, there SHALL be a reentry_queue.
• When adding a validator, users SHALL be able to place their deposit in the reentry_queue by spending one reentry_queue_ticket.
• When matching ETH from the deposit pool to queued deposits, ETH SHALL first be matched to the oldest deposit in the reentry_queue.
• If the reentry_queue is empty, ETH from the deposit pool SHALL be matched to queued deposits as specified in RPIP-59.
• Node operators SHALL receive a reentry_queue_ticket when:
• A minipool was requested to exit for withdrawal liquidity, and that minipool was distributed (either finalise = true or userDistributed = true).
• A megapool validator was requested to exit for withdrawal liquidity and notifyFinalBalance was called for that validator.
• Node operators SHALL NOT receive a reentry_queue_ticket when a validator exits voluntarily, when a validator is requested to exit for underperformance, or when a minipool is requested to exit for liquidity and does not exit.

Permissionless Distribution of Minipools

• The protocol SHALL allow anyone to prove that a minipool has been withdrawn and immediately distributeBalance for that minipool.
• To achieve this:
• RocketDAOProtocolSettingsMinipool.getUserDistributeWindowStart() SHALL return a value stored in RocketStorage.
• That value SHALL be set to 90 days initially.
• That value SHALL not be modifiable with a pDAO Proposal.
• When a withdrawal is proven for a minipool, the value SHALL be temporarily set to 0 until distributeBalance is called.

Rationale

Withdrawal Queue

The Withdrawal Queue opens 28 days after the upgrade containing this RPIP is deployed, giving node operators time to upgrade to the new delegate and update their smartnode to a version that supports fulfilling exit requests. It also aims to ensure that validators in the eligible set are actively staking.

The protocol may exit validators to fulfill a withdrawal request. If users could cancel withdrawal requests, they could trigger unneeded exits and reduce rETH APR.

Changing network.reth.collateral.target from 1 to 0 is needed so that ETH from exiting validators flows into the deposit pool rather than remaining as excess collateral in the rETH contract. Including Withdrawal Queue demand in RocketDepositPool.getExcessBalance() ensures that ETH freed from exits and new deposits can preferentially be used to satisfy withdrawal requests, rather than being available for rETH burns outside the queue.

The redemption rate at which a request is fulfilled is set to the minimum of the rate at the time of the request and the time of fulfillment. rETH in the Withdrawal Queue cannot keep earning staking rewards, or there would be an incentive to keep rETH in the queue and mint new rETH once it can be fulfilled, improving the position’s liquidity without losing rewards. At the same time, being in the Withdrawal Queue should not protect against rETH losing value in extreme slashing scenarios.

Fulfilling Withdrawal Requests

Since the rETH contract is not upgradeable and includes built-in redemption via the burn method, prioritizing the Withdrawal Queue requires some thought.

Setting the collateral target to 0 ensures that fully withdrawn minipool user ETH goes to the deposit pool. Reward distributions from old minipool delegates will still stay in the rETH contract and can be used to redeem rETH outside the Withdrawal Queue; this is why the specification calls for “to the extent possible”.

rETH also uses ETH from the deposit pool for burn, based on the value RocketDepositPool.getExcessBalance() returns. The Deposit Pool contract can be upgraded, but we need to ensure that rETH burns are possible for the Withdrawal Queue and rejected when someone other than the Withdrawal Queue attempts to burn. This may involve setting a state flag in the deposit pool to change the behavior of RocketDepositPool.getExcessBalance() during a burn transaction from the Withdrawal Queue.

Exit Hysteresis

The design only allows exits when the withdrawal_shortfall is more than exit_hysteresis ETH. This prevents us from exiting a whole validator to cover a residual amount that future rewards or natural inflows can reasonably cover.

The initial value is chosen based on the expected time between validator exit and ETH becoming available and the expected rewards earned during that time, using the following values:

• 890k active validators
• no beacon chain exit queue
• 380k ETH in rETH
• 2.3% rETH APR

With these values, it takes ~5 days on average for ETH to become available, and during that time, rETH earns ~120 ETH in rewards. In other words, if the withdrawal_shortfall is below 120 ETH, withdrawals will be filled from rewards before ETH from exited validators becomes available. exit_hysteresis is tunable, so pDAO can adjust it when the underlying assumptions change significantly.

Minipool Exit Phase

This design uses a phased approach, with minipools exited before moving to megapools.

The definition of the withdrawal_shortfall aims to trigger exits only when existing sources of liquidity are insufficient to satisfy the Withdrawal Queue, to the extent feasible (for example, ETH rewards in minipool contracts are not included here). While minipools still exist, we rely on the oDAO to track voluntary minipool exits off-chain because tracking this on-chain would be challenging.

Using the oDAO for minipools also lets us order exits by commission, which marginally improves rETH APR when rETH demand falls.

We focus on minipools in the first phase, not only to keep the reliance on the oDAO as short as possible, but also because this aligns with the overall desire to move away from minipools and towards megapools: to support the new RPL tokenomics, the new Universal Adjustable Revenue Split mechanism (RPIP-46), and to reduce complexity of future upgrades.

We also considered a trustless design for minipools. This would increase complexity and add gas costs that the protocol or pDAO would either have to fund or add to oDAO’s duties. The trusted oDAO duty appears preferable because it is temporary, low-risk, less complex, and lower-cost in gas.

The megapool_exit_phase toggle allows the pDAO to switch to the second phase once minipools are largely exited or known to be unresponsive. Once the remaining minipools largely consist of minipools on old delegates that do not respond to exit requests, the withdrawal mechanism stops working as intended. At that point, the pDAO can consider voting on a final penalty for any remaining minipools. The pDAO decides when to switch to megapools and how to handle remaining minipools.

Megapool Exit Phase

Once the protocol has only megapool validators, it becomes feasible to implement exit selection using a trustless mechanism. How to initialize the eligible megapool validator set at upgrade time is left as an implementation detail.

The staking_delay applied after the stake call ensures validators are added to the eligible set only after they clear the beacon chain queue, avoiding requests that would take a long time to execute. This also protects new validators from being exited immediately.

The pDAO decided to keep validator selection entirely random, because they favored the simplicity and relative fairness of it over other criteria that were considered. max_exits_per_call ensures that gas per call stays manageable. During random selection, the design assumes the least possible ETH returned for rETH and then only exits as many validators as actually necessary, based on the bond of the selected validators.

Reentry Queue

From node operators’ perspective, the reentry queue is a form of restitution for being randomly chosen for liquidity, while meeting the performance threshold set by RPIP-73. From the protocol’s perspective, prioritizing proven node operators that met the performance threshold over unknown (potentially underperforming) node operators is rational.

We also considered a direct ETH payment, financed from rETH in the withdrawal queue that stops earning rewards, as restitution. This appears harder to implement and harder to justify from the protocol’s perspective. Withdrawal liquidity exits mean supply exceeds demand, and this would pay the supply side. By contrast, the benefit from the reentry queue depends on demand returning to the previous level.

Permissionless Distribution of Minipools

Minipools don’t immediately make ETH available for rETH burns. ETH must first be distributed, which is initially exclusive to the node operator and is very delayed for others (currently 90 days after the distribution window starts). Therefore, if we exit minipools to fill the Withdrawal Queue and node operators don’t distribute, the wait time may be unexpectedly long.

We can’t reliably address this with a delegate upgrade, since these are opt-in. Instead, the design allows distribution without delay by temporarily removing the restriction and requiring proof that the validator has already been withdrawn.

Security Considerations

Fulfilling Withdrawal Requests and rETH Updates

Without further changes to the oDAO balance-tracking duty that informs the rETH exchange rate, the proposed mechanism redistributes staking rewards from rETH in the Withdrawal Queue to other rETH holders when a withdrawal request is fulfilled. Potentially, this could lead to a very large rETH rate increase with the following update that could become “sandwichable”: someone could mint a large amount of rETH right before the update and burn it right after to profit at the expense of rETH holders. However, rETH protects against this type of exploit with a pDAO-configurable rETH mint fee, currently set to 0.05%. This means, for example, that if 30% of rETH supply is in the Withdrawal Queue for 2 weeks, the resulting rETH rate update still could not be profitably sandwiched when rETH yield for that day is approximately average. If a large request fulfillment coincides with a high-yield day for rETH, the threshold for profitably sandwiching is lower. For example, a day with an 80ETH MEV block, plus 20% of the rETH supply queued over two weeks, can be sandwiched. If the pDAO wants to protect against even more extreme scenarios, it could slightly increase the mint fee.

Protection Against Repeated Minting and Withdrawing

A concern is that a malicious actor could reduce rETH yield by repeatedly minting and withdrawing rETH, keeping a share of staked ETH in a constantly unproductive state. The design makes this attack both costly and largely ineffective.

rETH already has a mint fee, so an attacker would currently lose 0.05% per round trip. They also would not earn any yield, based on how the redemption rate is defined.

Furthermore, the new withdrawal buffer in the deposit pool means that a repeatable attack requires more capital than the buffer size (controlled by deposit_pool_collateral_target) and only the amount above that buffer can create validator churn.

oDAO selecting minipools

The oDAO has discretion in selecting minipools during the initial phase and must factor in voluntary exiting minipools when determining how many to exit. However, the withdrawal_shortfall limits the number of exits. At most, the oDAO could exit unnecessary minipools equal to the number of minipools currently exiting voluntarily, provided there is sufficient withdrawal demand at the same time. So the exposure here is mostly limited to ordering and a small amount of extra exits. Because the rules are known and the actions are transparent, the pDAO can monitor the execution of this duty.

Correlated Slashing Penalties

Ethereum slashes validators for breaking protocol rules that could support an attack on the chain. The slashing penalty for a slashed validator increases when many other validators are slashed in the 18 days before and after the slashing. In extreme scenarios, when the slashing penalty exceeds the node operator bond (about 5% of validators are slashed within a 36-day window), this correlation penalty can cause the rETH exchange rate to decline. Sophisticated rETH holders could anticipate this and use the withdrawal mechanism to avoid losses, increasing losses for rETH holders who cannot withdraw in time.

To handle this extreme scenario, we considered a Security Council toggle to pause withdrawals. However, such a mechanism would undermine the withdrawal guarantee this RPIP aims to introduce, and the protocol has so far avoided pausing exits (rETH burns and distribution of validator balances). There are also concerns about the pressure such a toggle would put on the Security Council in the discussed extreme slashing scenario and other scenarios. Therefore, we believe the limited protection already provided by the node operator bond sufficiently mitigates this risk.

Copyright

Copyright and related rights waived via CC0.

Citation

knoshua, "RPIP-71: rETH Withdrawal liquidity via EIP-7002," Rocket Pool Improvement Proposals, no. 71, May 2025. [Online serial]. Available: https://rpips.rocketpool.net/RPIPs/RPIP-71.