RPIP-74 Minipool Queue Closure - Sentiment Poll

Governance
1

With Saturn 1 approaching, many have expressed interest in closing the minipool queue. The time window to implement this is closing fast. This post:

  1. Summarizes the status of those discussions.
  2. Presents a sentiment poll for RPIP-74: Minipool Queue Closure Pre-Saturn 1.

If support wins the vote, RPIP-74 will go to a snapshot vote.

Background

When Saturn 1 launches, the minipool queue will be closed to new requests. Those wanting to launch validators via Rocket Pool will go instead into the megapool queue. At launch time, new ETH deposits to the deposit pool would first be used to clear whatever is left in the minipool queue and after that, the megapools (this is also where express tickets will kick in). There is general and rough consensus that in the days before Saturn 1, allowing the deposit pool to be used for minipools is worse for both the protocol and the minipool operator and, thus, the queue should be closed some time before launch.

Summary of the Discussions

Should Rocket Pool close the minipool queue ahead of Saturn 1 (targeted ~Oct 29), to preserve Deposit Pool (DP) ETH for megapools?

General sentiment: Many lean pro-closure (with caveats). A minority flags permissionless/UX concerns and unclear net benefit to the rETH discount.

Queue Close Time Frame: The two main time frames discussed were to close one month prior to Saturn 1 or two weeks.

Governance/process: Define automatic re-enable triggers (e.g., “if DP ≥ 80% capacity, Security Council SHALL re-enable deposits”) to avoid governance delays if a large deposit(s) appears.

User communications/optics: Prominent UI banner, docs,forum, smartnode updates: “Closed in anticipation of Saturn 1—learn more about megapools & rETH here.” Avoid the impression of “closed shop” and try to keep would-be NOs in the RP orbit.

Mechanics/queue behavior concerns: Post-Saturn, minipool queue cannot be exited → risk of users stuck if they join late. Some argue disabling minipools may discourage exits now (since NOs can’t immediately re-enter), potentially delaying ETH flowing to redemptions.

rETH discount thread:

  • Pro-closure view: minipool queue consumes DP ETH; closing frees capacity for redemptions/burns, helping the peg.

  • Counterpoints: effect may be modest; higher minipool queue can raise rETH APR; a discount is bad for sellers but good for buyers; we’ve survived larger discounts; better to increase rETH demand.

  • Several real users minted then felt burned by discount → reputational hit; frontend now warns, but UX still matters.

Permissionless debate: Some worry closure “gives up permissionless.” Others argued that permissionless ≠ “no rules”. Temporary metering with equal rules is compatible, especially for upgrades or security incidents.

Pros of closing the minipool queue early

  • Protects DP ETH for megapools, aligning resources with the new architecture.

  • Peg health: more DP capacity can route mints to redemptions/burns, improving the rETH discount.

  • Avoids allowing newcomers into the old system: Prevents late entrants from starting less desirable minipools soon before Saturn.

  • Clearer UX: Reduces confusion at launch—fewer active queues.

  • Governance agility: If the RPIP encodes re-enable triggers (e.g., DP ≥ 80%), the Security Council can act fast if a whale appears—no multi-week revote.

  • Messaging opportunity: With strong docs/UI copy, you can steer traffic to rETH and megapool education rather than disappointing would-be NOs.

Cons / risks of closing early

  • Permissionless optics: Some will perceive “closing” as anti-permissionless (even if rule-based and equal for all).

  • Uncertain peg impact: Closing may worsen the discount, effects depend on many moving parts.

  • Might delay beneficial exits: If NOs can’t re-enter minipools immediately, some may not exit now, slowing ETH flow that would help redemptions.

  • Lost short-term NO intake: You’ll likely miss some NOs who would have joined (though several argue that’s acceptable before a major upgrade).

  • Comms burden: Requires crisp, proactive UI + docs + social to avoid “Closed, go away” vibes.

Consensus and RPIP

After discussions, RPIP-74 was drafted to:

  • Close the minipool queue 14 days before Saturn 1 launch (currently estimated as October 15, 2025).

  • If Deposit Pool utilization ≥ 80% the Security Council SHALL re-enable minipool creation. Subsequently, if DP falls back below 20%, minipool creation SHALL be closed again.

  • Strong comms: The team and pDAO SHOULD clearly communicate minipool closure and alternatives to creating minipools (mint rETH, wait for megapools, etc.) via the RP frontend, smartnode, forums, discord.

RPIP-74: Minipool Queue Closure Sentiment Poll

This poll will lead to a snapshot vote if it shows promising community sentiment after 7 days.

  • Support moving to snapshot vote on RPIP-74 minipool queue closure pre Saturn 1
  • Oppose moving to snapshot vote on RPIP-74 minipool queue closure pre Saturn 1
  • Undecided
0 voters