RPIP-74 says Rocket Pool should close the legacy minipool queue ahead of Saturn 1 by setting `node.deposit.enabled` to `false`, but it also defines a deposit-pool threshold safeguard. If deposit pool utilization rises to 80% or more, the Security Council should re-enable minipool deposits until utilization falls below 20%. In other words, the default is closure, with a high-utilization escape hatch so the protocol can still absorb large ETH inflows when needed.
The main rule
The core of RPIP-74 is simple: Rocket Pool should close the minipool queue before Saturn 1 so deposit-pool ETH can be directed toward megapools instead of new legacy minipools.
In specification terms, the proposal says new minipool deposits are disabled by setting `node.deposit.enabled` to `false`. The closure is supposed to happen soon after enactment and no later than six weeks before Saturn 1 launch.
What the threshold behavior actually is
The threshold behavior is not a normal operating target for day-to-day queue management. It is an explicit safeguard for exceptional demand conditions.
RPIP-74 says that if deposit pool utilization reaches at least 80%, the Security Council should temporarily re-enable minipool deposits. Those deposits stay enabled until utilization falls below 20%, at which point the queue should close again.
- Default state after enactment: minipool queue closed.
- Re-enable trigger: deposit pool utilization at or above 80%.
- Close-again trigger: utilization below 20%.
- Purpose of the safeguard: let Rocket Pool absorb large ETH inflows without waiting for another governance cycle.
Why RPIP-74 does this
The proposal gives three main reasons. First, Saturn 1 is built around megapools, so letting late legacy minipool entries consume deposit-pool ETH works against that transition. Second, the proposal argues that late-arriving node operators could get stuck in a less desirable path if they create minipools too close to the Saturn 1 shift. Third, it says active minipool queues worsen rETH peg pressure because that ETH cannot instead support redemptions.
So the threshold behavior is a compromise. It tries to keep the protocol pointed toward the Saturn 1 transition while preserving a way to respond if the deposit pool becomes heavily utilized.
What RPIP-74 does not change
RPIP-74 does not say existing active minipools are shut down or rewritten. It also does not say existing queue entries are cancelled.
The backward-compatibility section says active minipools are unaffected, existing minipool queue entries continue until matched, and megapool functionality itself is unchanged. That is important because the proposal is specifically about new queue behavior before Saturn 1, not a protocol-wide rewrite of existing positions.