Require Minipools to Use Latest Delegate

Governance
1

Require Minipools to Use the Latest Delegate

UPDATE: The Sentiment Poll for this is now live

!!Alert!!
Read this and ask questions if you don’t understand, here or in the discord. This could be a contentious proposition and should be thoroughly vetted before proceeding to a sentiment poll.

Proposal: For a future Smartnode update, force minipools to use the latest delegate smart contract. The primary driver of this is to eventually, with community support/vote, allow forced exits of underperforming minipools.

Introduction

A meaningful number of minipools are underperforming, dragging down rETH yield and thus potentially harming demand. This could contribute to the minipool queue not clearing in a timely manner, which threatens our ability to transition cleanly to the Saturn 1 architecture (megapools, RPL fee switch, alternative protocol funding schemes, etc.). Even if/when the queue eventually clears, this drag on yield could continue to slow rETH adoption and exacerbate the above mentioned issues.

A proposal is in development that would allow the Smartnode to force node operators to use the latest protocol deployed delegate smart contract. This effect would only be relevant after updating to that version of Smartnode. Currently, users can choose to use the latest delegate or remain on a previous delegate of their choosing, thus avoiding certain smart contract changes they do not wish to partake in.

This proposal is a philosophical change in how Rocket Pool operates. It no longer allows node operators to avoid contract updates they do not want once they upgrade to this Smartnode version.

One likely consequence of this change will be to allow forced exits on underperforming minipools. This would be a separate vote or roadmap item, however.

This post:

  1. Summarizes the problem and why use-latest-delegate matters
  2. Outlines the proposed change: forcing use-latest-delegate = yes
  3. Presents a governance path to proceed to a formal proposal / snapshot

Summary

What is the minipool delegate?

Minipools are implemented using a proxy; the minipool contract does little work and instead forwards most calls to a delegate implementation contract (the delegate). The delegate contract controls things such as:

  1. Minipool lifecycle: Defines the state for a minipool, including allowed transitions (prelaunch, staking, withdrawable, dissolved) and who may trigger them.
  2. Validator launch: Enforces when and how a minipool is permitted to stake and become an active Ethereum validator.
  3. ETH distribution: Determines when balances can be distributed and how ETH is split between the node operator and rETH holders, including commission logic.
  4. Penalties & slashing: Applies penalty rates and slashing rules that reduce a node operator’s share when performance or withdrawal conditions are not met.
  5. Withdrawals & exits: Governs how validators are exited, when funds become withdrawable, and how final balances are handled or finalized.
  6. Governance & trusted-node actions: Defines which protocol or trusted-node contracts can intervene in minipool behavior (e.g., scrubbing or other governance-driven actions).
  7. Upgrades & fixes: Serves as the upgrade point for bug fixes, security patches, and protocol rule changes without redeploying minipools.

What is the use-latest-delegate flag?

Node Operators can currently choose whether their minipools:

  • Pin to the current delegate at the time the pool is created (default behavior currently)
  • Always uses the latest protocol delegate

Smartnode supports explicitly setting this behavior:

rocketpool minipool set-use-latest-delegate — when enabled, a minipool ignores its current delegate and uses whatever the latest delegate is.

The Problem We’re Trying to Solve

A large enough group of poorly performing minipools has real protocol-level consequences:

  • Lower rETH yield → weaker rETH demand
  • Weaker rETH demand → harder to clear queues / complicates transition to megapools
  • No Megapools → no RPL fee switch, less options for protocol funding, less options for institutional incentives

There is already longstanding discussion about forced exits as a protocol tool, but it becomes very difficult to enforce protocol-wide standards if a meaningful subset of pools (minipools) can remain permanently on older delegate behavior. Note that megapools do not have this same set of issues as they do not use this delegate model.

As of this post, there are 620 severely underperforming minipools, a majority of which are not attesting on the correct chain at all. See @steely’s performance website for current numbers. Note that an extensive effort to track these NOs down and give them support has been ongoing.

The effect on yield is estimated to be over 3% and note that once these NOs get in the hole (via leaking), they are a drag for a while as they need to go to back above 32 ETH to start earning for the rETH holders again.

Also, note that node operators are no longer at a premium. With Saturn 1 and 2 upgrades, capital efficiency dramatically increases. The protocol is struggling with rETH demand, not node operator demand.

Proposal (High Level)

Make a Smartnode version wherein all nodes that update to it are effectively forced to use the latest delegate, rather than pin to the current one.

This could be implemented as:

  • On Smartnode upgrade, use-latest-delegate is set to yes and cannot be toggled to no
  • On Smartnode upgrade, use-latest-delegate is set to yes but operator can toggle to no

Once a node operator upgrades to this Smartnode, their minipools by default will use delegate upgrades, enabling governance-approved protocol actions (including, potentially, force-exit mechanisms where applicable).

Pros of forcing use-latest-delegate = yes

  • Protocol-wide consistency: Everyone runs under the same minipool logic
  • Enforceability: Governance-approved mechanisms (including performance enforcement / exit tools where applicable) become practical
  • Yield protection: Raises the floor on validator performance over time, supporting rETH competitiveness.
  • Operational simplicity: Reduces “why does this minipool behave differently?” support/debug burden.
  • Saturn 1 readiness: Helps remove one of the biggest practical blockers to clearing queues and moving cleanly into the new architecture.

If Node Operators can opt out of enforcement, rETH holders are subsidizing negligence.

Cons / risks

  • Permissionless/opt-in optics: This is a philosophical shift away from “NOs can choose the rules their pools live by”
  • Governance risk concentration: Delegate upgrades become more powerful; any governance compromise becomes more dangerous
  • Trust and process requirements go up: We likely need stronger/more public facing DAO and team alignment and communication on exactly what goes into each delegate upgrade
  • Backward compatibility: Some NOs may strongly object to losing the ability to pin a delegate for stability

Rocket Pool intentionally made minipool upgrades opt-in historically to reduce the risk of a malicious oDAO majority harming NOs. Although some would argue that a malicious oDAO can hurt the protocol just as much without this.

Path Forward

The Require Use Latest Delegate thread on discord and this forum should be used to debate this issue. We must reach out via discord pings and ping channel pings to the broader community for input on this issue.

When/if we feel we have settled in the discussion, a sentiment poll will be taken and the regular governance process will proceed.

Open Questions

  1. Is the rETH yield more important than Node Operator control?

  2. Are there ways this can be abused we are not ready to deal with?

  3. What governance controls should be required for delegate updates if we remove opt-out? For example, should pDAO have to vote on delegate updates or on certain types of updates?

Conclusion

This is a major philosophical change, but this design was created before we could know what the limitations of it would truly be. Make your case so we can proceed with what the DAO and team think is best for the protocol.

9 Likes
2

Do it now, as fast as possible. We need this yesterday.

5 Likes
3

Answers to the open questions:

  1. Yes
  2. No
  3. Yes (pDAO votes)
3 Likes
4

Interesting proposal. From a governance perspective, I recently analyzed RP’s voting patterns and found that top 10 wallets control 53.1% of voting power with a Nakamoto coefficient of 10.

If this proposal is contentious as mentioned, it would be valuable to see:

1. How participation rates change for controversial vs routine proposals

2. Whether the voting bloc patterns shift when node operator interests are at stake

Based on recent data, RP averages 70-86 votes per proposal. For a decision this significant, would be interesting to see if participation increases.

Happy to share more detailed governance metrics if useful for the discussion.

5

I don’t think that’s correct. Did you just go by token holdings to calculate it? The largest current delegate (@Patches) has a voting power of 1763 out of a total of 73,297, so there is no way you get to 53% with 10 wallets. The largest 10 are just about able to reach the quorum of 15%.

1 Like
6

Good catch - I should clarify the methodology.

My analysis is based on Snapshot voting data from recent proposals, not current on-chain RPL delegation. The 53.1% figure represents the top 10 wallets by voting power EXERCISED in recent Snapshot votes (10 proposals, 146 unique voters).

You’re right that current on-chain delegation shows different numbers. That’s because my analysis measures “who controlled outcomes in recent votes” not “who has delegated power available today.”

These are both valuable but different metrics:

- Snapshot historical data: Shows actual influence on past decisions

- Current on-chain delegation: Shows potential influence on future votes

The discrepancy actually highlights an interesting point - not everyone who has delegated power participates in Snapshot votes. The gap between available power and exercised power is itself worth analyzing.

Thanks for pointing this out - I’ll make the distinction clearer in future analysis. Both metrics matter for understanding governance health.

7

I’m in favor of doing this. Really, we made the philosophical change when voting in RPIP-47 (for good reason) and this initiative would just be attempting to fix old mistakes and give us the ability to backport some megapool features to minipools in the future.

8 Likes
8

I’m very much in favor of this and is about time we get something like this going to improve the health of the protocol/rETH and its only fair for the wider group of node operators (who are putting in the effort+time for good performance) and rETH users in my opinion.

4 Likes
9

I think we should try a campaign to get NOs opt in to the latest with the expectation that we will implement a performance based forced exits delegate. We could see how much support there really is for rETH first. I’m not really opposed to backdooring it in the smart node but I think explaining to NOs why it’s important and seeing how much buy in we can get would be a good first step.

10

What does this mean? Would 14% nodes that are performing ok be forced over to the fee switch model? if so I think that’s a little much but for severely underperforming nodes a forced exit is needed but I thought ETH did that already.

11

No. If you are performing efficiently, your minipools would stay as is. If that were going to change, it would need a community vote. If you are not performing efficiently, this could lead to you being force exited, but that also will be a community vote. This proposal is to give the protocol the ability to do that.

2 Likes
12

I’m supportive of making this change to enable potential minipools forced exits in the future. Let’s proceed with the sentiment poll.

6 Likes
13

I’m in favor of this proposal.

Getting kicked can be seen as a safety feature for operators. It effectively limits downside risk by preventing infinite or prolonged losses in situations where an operator is no longer able to manage their infrastructure due to unforeseen circumstances.

5 Likes
14

Yeah, it makes sense.

Let’s do it.

5 Likes
15

Fully in favor.

  1. Is the rETH yield more important than Node Operator control?

    Node operators may still re-enter afterward. A poor performing minipool is abusing the common pool resource of ETH deposits and harms the community of Rocket Pool Node Operators as well as rETH owners. This option will allow Node Operators to better to manage the common pool resource.

  2. Are there ways this can be abused we are not ready to deal with?

    Directionally adds additional power to delegate deployer, but I’m not sharp enough to see a meaningful magnitude increase in risk. The method of enforcement for under performing minipools will be important, but that is a future step.

  3. What governance controls should be required for delegate updates if we remove opt-out? For example, should pDAO have to vote on delegate updates or on certain types of updates?

    Informed pDAO voting for delegate upgrades is reasonable.

4 Likes
16

Very much in favor. Signally my support.

7 Likes
17

@Semp_re Can you use Nakamoto on a delegated and quadratic voting system in this way?

The top 10 surely must be delegated because quadratic voting makes it almost impossible to have a significant percentage of votes, and delegates can override anyway.

Surely governance capture can only happen through total apathy. I don’t think there is any system that can deal with that at the protocol level.

Have I missed the point?

1 Like
18

Fully support this proposal.

  1. Yes
  2. Almost certainly, that’s why we need to think carefully about 3.
  3. This can come later. Let’s go to sentiment vote.
3 Likes
19

I’m honestly surprised at how little push back this proposal is receiving, especially considering how aware everyone is of the potential for controversy.

We would be using the smart node as a back door to force updated smart contracts on our node operators. That is a very significant change of the relationship between the protocol and its operators. We’ve been telling our operators that nobody can force them to exit and the proof is on-chain, ultimately guaranteed by the first principles of Ethereum. Whether that was a wise decision or not is up for debate, but with this proposal we would not only go back on that promise, we would be doing so in a way that comes fairly close to essentially putting malware on the nodes of our operators. I’m choosing the word “malware” because we all know that no matter how public this process would be, a large proportion of our node operators would remain unaware and would unknowingly install software that could ultimately close their node for whatever reason the majority of RPL-votes chooses, going back on what they were promised when they created it. And no, I don’t think that a prerequisite for being a node operator is to stay current on the affairs of the protocol. The whole point of this protocol was to engage home stakers who don’t have the time or resources to make this their livelihood.

I also don’t agree that this would only affect node operators neglecting their duties. As the OP says, most of those nodes aren’t attesting at all and it stands to reason that they don’t update their smart node and thus couldn’t be reached through this mechanism. It is far more likely that Saturn 1 doesn’t quite go as originally planned and the community decides to force migration to megapools by closing old nodes. That may seem unlikely now, but we’re already in a fairly bad spot and we may just become too desperate to ignore this back door.

That said, I’m not entirely against this. Developing the smart node uses protocol resources and the protocol is entirely within its rights to use its resources for the benefit of the protocol. I would just urge everyone to do this without any semblance of deception. Instead of hiding this back door in a normal smart node update, make it part of a new version of the smart node and make it impossible to install without being very clearly told during installation that this version will force smart contract updates and that this entails a possible forced exit. If a node operator does not agree with that change they can continue using the old version, which would no longer receive significant updates.

I’ll tell you what I will do if this goes through: No way in hell will I install that update and I suspect neither will most of you. I will choose myself when to exit my minipools, thank you.

6 Likes
20

Yes, but that is made possible by rETH depositors. Allowing a node operator to exclusively choose when to exit fundamentally means 16 - 24 ETH of rETH per minipool become unredeemable until that decision is taken. The worst case with forced exits is for the node operator to stop earning yield (for which there are other opportunities), the worst case without forced exits is for an rETH holder to lose their deposit.

most of those nodes aren’t attesting at all and it stands to reason that they don’t update their smart node and thus couldn’t be reached through this mechanism

Yes, this doesn’t help if they stay offline in perpetuity from here on out. But just being back online for a short period of time would be enough to set the delegate flag.

It is far more likely that Saturn 1 doesn’t quite go as originally planned and the community decides to force migration to megapools by closing old nodes. That may seem unlikely now

We might not do this directly, but it stands to reason that if validators need to be exited for withdrawal liquidity, minipools would be the first to go, which is a similar effect over time.

5 Likes