Thanks for an alternative view point.
I think a lot of us who wouldn’t have been for this in the past are now thinking that without this, RPL price won’t recover and we won’t be able to fund devs much longer so the protocol would be in deep trouble (done?). If we want maintenance, updates, frontend, etc., we need to do something about it. What’s the famous saying, “The Constitution is not a suicide pact”. Feels like we’re at that point. imo.
This is just incorrect, sorry. The duties of a node operator include staying up to date. See Rocket Pool Guides & Documentation . In particular note “It’s a big responsibility, and not a simple set-it-and-forget-it kind of job; you need to care for your node for as long as it’s staking.”
Rocket Pool does cater to stakers who don’t have time or resources, but it’s not via node operation. The way such people can and should stake is as pool stakers, by holding Rocket Ether (rETH).
Without updating your client software you’re going to be losing money and validating the wrong chain anyway. For the sake of the protocol, and yourself, I hope you choose to exit sooner rather than later.
I admit I’m not involved enough to know just how bad the situation is. If we’re truly close to lights out at the team then that changes things. Desperate times desperate measures? I get it, but there’s a cost to these things. If a large number of NOs end up feeling betrayed then that’ll haunt us for a while I think.
Maintaining the node yes, not being involved in governance. In fact all the responsibilities are listed under the link you posted and staying up to date on RPL governance is not included.
Let’s not overstate what the smart node is. The heavy lifting is done by the clients and it wouldn’t be difficult at all to keep an old smart node version alive with updated clients. I don’t know whether I’d do it myself but I’d wager there’s enough demand for this that it’ll get done either way.
It might be harder than expected to run updated clients on an old Smart Node. In my experience, CLI flags change enough between versions to cause real issues. I nearly bricked my node trying to do exactly that.
Strongly in favor.
Long time reader and node operator. The uncomfortable truth stated here: RocketPool is in trouble. As stated, our PRIMARY concern is driving adoption of rETH. What drives rETH adoption? Higher yields. What drives higher yields? The ability to exit NOs who aren’t holding up their end of the bargain.
As a NO you are entrusted with stranger’s ETH and this is the contract:
If the market decides RocketPool isn’t favorable and keeps winding down the TVL of rETH then there needs to be mechanisms to exit and distribute mini pools back to the rETH holders. I’m happy to see things are moving in the right direction.
Fully in favor. I don’t see how this voids or backtracks on any of RP’s governance values or expectations of node operators if the pdao is giving the final say on this. If there is still concern about this, can defaulting to “yes” and allowing to toggle to “no” for a period of time be a bridge between the two states? Seems more than reasonable.
Philosophically i don’t love it.
Practically i love it. We have no better way to protect rETH users from node operators who aren’t taking their responsibility seriously. rETH users cannot vote, nor do they have any mechanism to defend their stake from NOs. We need to help them.
In addition, this is strongly protective of NO stake. There are individuals who have been offline for months or years; this would prevent all that loss of funds in the future.
And it’s protective of RPL value, since rETH yield/demand is what will drive this.
Just needs to be voted on and everyone given enough warning that they can exit if this is a bridge too far; i don’t think we’ll see many leaving though.
I’m in favour for this change.
The product of Rocket Pool is rETH, so it’s important to have an competitive yield for rETH holders.
Without rETH demand we are in trouble.(no Megapools, no RPL revenue, no growth, no funding for the team)
As for the open questions:
100% this!
Strongly in favour.
lets do it. seems reasonable and we need it
Have to agree with @cderpz here on all his points. Forcing an NO to upgrade via a backdoor (which can be circumvented anyway), breaks an important trust assumption which NOs signed up too, that they are in control of their deposits and how they’re handled in minipools. If a back door is implemented, it breaks this trust. With Megapools on the way, I’d only support this kind of change if the NO is made fully aware of the change and can opt out when installing whichever smartnode version might include this.
As a side note, this also raises another interesting point which is not to distract from the above (discussion for another day imo), but worth considering. Since the smart node is the labs implementation of the client which interacts with the protocol, they should definitely weigh in pDAO sentiment significantly, but ultimately any changes would fall with their decisions on what to include in their implementation. I’d actually love to see competing implementations just like we have with the client teams to help eliminate any single point of failure, this would also give NO’s the freedom of choice to choose what aligns with their principles the most when interacting with the protocol at the client level.