RPIP-77 is a Rocket Pool proposal to make Smart Node push eligible minipools toward the latest approved delegate by default and to remove the normal Smart Node-supported path for intentionally staying on older delegates. In practical terms, it is not a forced-exit proposal by itself. It is a proposal to narrow the gap between governance-approved minipool logic and what Smart Node-managed minipools actually run.
The core change
RPIP-77 is about Smart Node default behavior, not about replacing the minipool architecture itself. Rocket Pool minipools use delegate contracts, so a meaningful part of their live behavior depends on which approved delegate path they are actually running.
The proposal says a future Smart Node release should check whether a minipool is finalized and whether it is using the latest delegate. If it is not finalized and not already using the latest delegate, Smart Node should try to enable that setting. That is why the proposal matters more than a cosmetic default tweak: it changes the practical operating path for Smart Node-managed minipools.
Why the proposal was made
The proposal's motivation is largely about protocol consistency and enforceability. RPIP-77 argues that too many minipools remain on older delegate behavior because the existing default leaves the latest approved delegate as something an operator can avoid in ordinary Smart Node usage.
In the proposal's framing, that creates a widening gap between governance-approved protocol logic and what many minipools actually run. That gap matters most when Rocket Pool wants consistent behavior around underperforming validators, rETH yield drag, or future Saturn-era mechanisms.
- The proposal treats optional delegate upgrades as a governance and enforcement gap.
- It links older delegate behavior to underperformance and protocol inconsistency.
- It presents latest-delegate defaults as an enabling step for later governance-approved tools rather than a complete solution by itself.
What it does and does not do
RPIP-77 is narrower than it first sounds. It does not by itself implement forced exits, slash operators, or instantly rewrite every minipool on the network. Its immediate scope is the supported Smart Node path after a relevant update.
The proposal also does not simply erase every technical possibility of older delegate use at the contract level. What it does is make 'stay on an older delegate' much less normal and much less supported in the ordinary Smart Node workflow, while making latest-delegate behavior the default path.
- It applies through a future Smart Node release rather than as an instant network-wide rewrite.
- It matters most for Smart Node-managed, non-finalized minipools.
- It does not grant new emergency powers on its own.
- It changes the default and supported operator workflow more than the entire contract permission surface.
Why it became a philosophical governance question
RPIP-77 is not just a software-default change. It touches an older Rocket Pool norm that node operators could deliberately avoid later delegate changes and remain on a long-lived implementation if they wanted to.
That is why the debate often sounds bigger than the implementation itself. Supporters tend to frame the proposal as necessary protocol coherence, while critics tend to frame it as expanding governance's practical reach over operator-controlled minipools. In other words, the argument is partly about software defaults, but it is also about autonomy, trust, and what governance approval should entitle the protocol to make normal.