Use Latest Delegate in Smart Node — Sentiment Poll

Governance
, ,
1

Smart Node: Use Latest Delegate for Minipools

Status: Sentiment Poll - Passed
Discord Discussion: #Require Use Latest Delegate in Smartnode
RPIP Finalized: RPIP-77

:warning: Please read before voting
Although this proposal does represent a philosophical shift in how Rocket Pool operates, the language here is softened from the original forum post discussion. Without encouraging bypassing this proposed change, voters should understand it is possible to set the delegate to other versions outside the scope of Smartnode.

Overview

This post is intended to gauge support for a proposal that specifies a future Smart Node update will by default set minipools managed via Smart Node to use the latest delegate smart contract and remove supported Smart Node configuration options for setting older delegate implementations. The intent is to improve protocol-wide consistency among minipools, enable pDAO approved minipool changes, and remove some technical blockers to future enforcement mechanisms (including, but not limited to, forced exits of persistently underperforming minipools).

If sentiment if favorable, the RPIP will proceed to a snapshot vote.

Motivation

A non-trivial number of minipools are persistently underperforming, reducing overall rETH yield and harming demand. Reduced rETH demand complicates the protocol’s transition to the Saturn 1 architecture which includes megapools, the RPL fee switch, and alternative protocol funding mechanisms.

While support efforts to remediate underperforming node operators are ongoing, the protocol currently lacks an enforcement mechanism since, by default, minipools are not set to use the most recent delegate contract and it is easy for minipool operators to opt out of delegate upgrades. This creates a situation where governance approved protocol logic cannot be universally applied. Currently, only 7% of operators have proactively selected to use the latest delegate and many of those who have not are likely not even aware of this option.

Background

Rocket Pool minipools are implemented using a proxy pattern. The minipool contract itself contains minimal logic and instead forwards most calls to a delegate implementation contract (the "delegate”). The delegate controls, among other things:

  • Minipool lifecycle and state transitions
  • Validator launch conditions
  • ETH balance distribution between node operators and rETH holders
  • Penalty and slashing logic
  • Withdrawal, exit, and finalization behavior
  • Bug fixes and protocol rule updates without redeploying minipools

Node operators may currently configure each minipool to either:

  • Use the delegate active at the time of creation, then upgrade to future delegates of their choosing, or
  • Use the latest delegate at all times

The opt-in model was originally designed to:

  1. Protect node operators from potentially malicious or unsafe governance upgrades.
  2. Allow minipools to converge on a long-lived (“Lindy”) delegate without mandatory churn.
  3. Provide node operators an exit path if they disagreed with protocol changes.

This proposal revisits these assumptions in light of changes to Rocket Pool’s governance and security model.

Proposed Change

  • A Smart Node update SHALL set by default the use latest delegate flag to true for minipools.
  • The Smart Node update SHALL remove supported Smart Node configuration options for setting older delegate implementations.
  • The Smart Node update SHOULD be implemented at the earliest reasonable opportunity that does not interfere with the Saturn 1 launch.

Scope

  • Applies only after upgrading to the specified Smart Node version.
  • Does not retroactively modify minipools on older Smart Node versions.
  • Does not itself implement forced exits; it enables future governance-approved mechanisms.
  • Does not grant any emergency or unilateral powers to the core team or governance bodies beyond existing delegate upgrade mechanisms.
  • Does not prevent an older delegate from being used, it just removes the ability to change the use latest delegate option via Smart Node.

Delegate Update Oversight

  • Delegate updates that materially affect validator exits, reward distribution, penalties, or governance authority MUST only be implemented following pDAO vetting via vote.

Any forced-exit mechanism would require a separate proposal and vote.

Summary

This proposal involves tradeoffs:

Pros

  • Improved alignment with pDAO approved changes – eventually including forced exits
  • Improved rETH yield competitiveness
  • Reduced operational complexity
  • Better alignment with Saturn-era architecture

Cons / Risks

  • Increased importance of governance process integrity
  • Sacrifice of long-lived (“Lindy”) delegate stability
  • Partial enforcement until/unless Smart Node upgrades are widely adopted

Note that a knowledgeable and/or determined operator can change delegate outside the Smart Node infrastructure if they so choose.

Poll

Should this proposal proceed to a vote?

  • Yes, proceed to vote
  • No, do not proceed to vote
  • Undecided - comment below
0 voters

Next Steps

  • If sentiment is positive, the RPIP will be finalized and proceed to pDAO vote
  • If pDAO vote succeeds, the changes above will be implemented

Final Notes

This proposal reflects a reassessment of earlier design assumptions in light of Rocket Pool’s growth, Saturn-era governance safeguards, and observed protocol limitations. It also takes into account operator reluctance to lose all possibility of delegate choice.

1 Like
Require Minipools to Use Latest Delegate
2

I voted to proceed with a vote.

Since it’s an important topic and I’m yet unsure about my final stance on it, I’d also like to just list my thoughts in order of their importance to me. Not with any partial intent, just so that the views of a small NO are out there :slight_smile:

Why vote yes Stuff that makes me consider voting no
I think it’s ok to “force” NOs to upgrade to a new delegate. If we’re not ok with changes, we can exit our validators. I don’t like that this will be happening automatically. I want to control when gas is spent to initiate the delegate update. My money should not just vanish without me noticing. The last two years didn’t bring me much earnings from my validators, so having it vanish because the delegate update was done when gas was expensive is a very sad thought. So ideally, Smartnode version 2.X would use delegate 2 and when updating to Smartnode version 3.X it would tell me that this will trigger a delegate update for all my validators and it will cost Y gas. This way I could time the Smartnode update for when gas is cheap.
I think forced exits are needed for underperforming NOs. I cannot believe the people that don’t take care of their validators. My validators are like my babies, I can’t let them suffer and die! I don’t like that sometimes the talk is to also force exit appropriately performing NOs if rETH demands it. The NO provides the infrastructure, the power, the maintenance and the performance of the validator. When somebody “gives me credit” by purchasing rETH, they know upfront that it’s for staking and that means it gets locked away in a smart contract. If I do my duty well, I should never ever have to fear a forced exit. (I know this vote has nothing to do with forced exits yet. As I said, just my thoughts.)
Easier development brings speed and safety. As a software developer in a long-living industry, I know how hard and frustrating it is to always also think about the one product out there that still uses the version from thirteen years ago. So eliminating the need to consider old code should help immensely. “Does not prevent an older delegate from being used”. With this, though, it won’t help with easier R&D and development. Moreso, the “normal” NO will be impacted, but the savvier ones not. If somebody has an underperforming validator, chances are, that they are not updating the smart node and thus this change doesn’t achieve what it ultimately wants! So ideally, we would actually force delegate upgrades and not just hide the option in the GUI.
Adaptive change is good. Adjusting to a situation and being flexible enough to change things is why I love Ethereum and just kinda look weirdly towards Bitcoin. Rocket Pool seems to change into something I no longer recognize. Minipools turn to Megapools. RPL turns from “insurance promise” to “no longer needed since we didn’t use it for insurance anyway”. The promise for the NO to be able to stay on the old delegate gets washed away. Note: Not all of the changes listed are “bad”, Megapools are awesome! But we constantly bounce between “Ah, too much rETH, need to make NOs more attractive” and “Ah, too many NOs, need to boost rETH” and don’t stick to just one philosophy. The idea of a well-thought-out protocol vanishes with every “urgent” vote about “Ah, we need to close the minipool queue!”. It feels like we are just wiggling back-and-forth in the current instead of defining how the river should run.

So there you have it, my inner discussion with myself.

Basically, I agree with the general direction, just not particularly with the way it would be done.

3 Likes
3

Thanks for your thoughtful post.

Only on your last point do I somewhat disagree. The discord discussions are well thought out and are often ongoing for quite a long time before becoming forum posts and sentiment polls etc. and anyone is welcome and encouraged to participate (and many do). Things like closing the queue and setting the latest delegate default have been bouncing around for months.

From my point of view, I don’t feel we are fickle and jumping between ideas too quickly. If anything, I feel we are often much too slow to react to obvious issues. As a DAO, we have to make decisions differently than a centralized structure like Lido. As the landscape changes, we will often have to use forums and sentiment polls as community debate instigators since it takes a while to turn this ship with public consensus. Because of this, to the community outside the discord, I suppose it can appear that ideas pop up quickly and are demanding votes asap since you are seeing the internal workings that are usual hidden by other protocol leadership. Meaning that once a problem has been identified and debated by a few dozen people with different views in the discord and a solution agreed on, the entire thing could still get killed or modified during the next stage of community debate so we have to get attention on it quickly and with a little pushiness, otherwise it will fester unlooked at and either never get implemented or get implemented with complaints of “why didn’t I know that was going to happen, you all should have said something.” It is complex running a protocol with so many chefs stirring the pot, but it is the decentralized model we have chosen for better or worse.

4 Likes
4

It feels like we are just wiggling back-and-forth in the current instead of defining how the river should run.

I don’t disagree with this, but it’s important to recognize that megapools are what let us define how the river runs. The minipool delegate model was poorly thought out and we are in fact wiggling around trying to find a good way to deal with repercussions of that model. If we can get people to move on to megapools, we have much better ways to balance demand.

The NO provides the infrastructure, the power, the maintenance and the performance of the validator. When somebody “gives me credit” by purchasing rETH, they know upfront that it’s for staking and that means it gets locked away in a smart contract. When somebody “gives me credit” by purchasing rETH, they know upfront that it’s for staking and that means it gets locked away in a smart contract. If I do my duty well, I should never ever have to fear a forced exit.

As you said, this is somewhat off-topic for this specific sentiment poll, but I still want to discuss it because I think it is important. I strongly disagree. People want to stake their ETH to eventually have more ETH. If they can never unstake, they’re just burning it. You are providing a service for them by staking their ETH and you are indeed getting paid for it in the form of commission. Just because you are doing a good job does not automatically mean your services are needed forever. How do you suggest we ensure an rETH holder can get their deposit back without potentially exiting well-performing nodes?

6 Likes
5

don’t like that this will be happening automatically. I want to control when gas is spent to initiate the delegate update.

I think you can control it: just set the latest delegate flag before the upgrade and there will be no automated transaction.

2 Likes
6

HOLD ON!

Are you saying that once this flag is set, there is no other transaction needed once a new delegate is released? Because I thought setting this flag would mean:

  • Smartnode monitors for new delegate releases.
  • If a new release is found, it will automatically initiate transactions to update to the newest delegate, thus costing gas every time.

If I understand you correctly, you are saying that there is a mechanism which makes it possible to have the minipool contract always point to the newest delegate without needing an update? So if I set this flag once, I never have to upgrade to a new delegate because it somehow magically always points to the newest one?

If so, then that’s a huge difference!

1 Like
7

I have no idea and I see that it’s a problem.

But what I’m saying is that when I entered as a NO, the premise to me seemed to be “Hey, you can validate without 32 ETH and still be independent. ” This has now somehow transformed into “NOs work for rETH”.

In my country I have to declare my earnings as “income from self-employment” for taxes, which I always thought was kinda correct. But now I seem to no longer be self-employed but rather work for Rocket Pool…

1 Like
8

Yes, that’s right. One transaction and that’s it.

1 Like
9

Even if you’re self-employed, you can run out of customers and then you have nothing to do. Can’t force them to keep paying you. I think contractor for Rocket Pool is probably the closest in reality. If you want full autonomy, you’d have to solo stake.

1 Like
10

I suggest we leave the delegate upgrades manual, but when an update is done to the client, an clear and specific message is provided during the steps between updating and restart that describes in detail what the delegate upgrade will do, and provide the command to update to it if desired.
If this mandatory delegate upgrade can be used to kill off the remaining ~14% minipools, than rocketpool is dead. and mega pools have no chance. I will not be investing in something that can be “tweaked” into meaninglessness.

1 Like
11

I’m not exactly sure why the DAO would vote to kill the protocol? If so the oDAO would not approve the change.

1 Like
12

That fact that only 7% of operators are using the latest delegate should tell us that we are not getting the message out about what a delegate contract even is. What version number are we on? Where is the change log? What does it control? Because AI told me it cant change my commission but this post and others seem to suggest it does everything.

If I understand correctly that major changes will have to be voted on and most people don’t think exiting well performing nodes is a good idea then I am in favor.

3 Likes
13

The sentiment poll period has ended and the poll is closed.
Feel free to keep commenting below, but it will not affect the outcome.

With 34 votes and 97% approval, this is considered passed.
RPIP-77 is finalized and the snapshot vote will begin soon.

1 Like