This post seeks to discover community sentiment on RPIP-71: rETH Withdrawal liquidity via EIP-7002.
The idea of guaranteed redemption of rETH at the protocol rate have been long discussed on discord, particularly in this thread. Guaranteed redemption at protocol rate requires the protocol to be able to exit validators on behalf of users and without coordination with node operators, which means such exits are forced.
The RPIP formulates the intent to enable such a mechanism in the protocol, in the following Saturn 2 upgrade, without much detail of implementation at the moment.
Below is a sentiment poll as required by RPIP-4; more specific polls regarding nuances of implementation may follow.
That said, I believe it’s important to clearly define the selection priorities so node operators can understand how they may be impacted - to support voting. Particularly in this case where they can be force exited.
The RPIP outlines characteristics that may influence selection, but I think we should be explicit about how factors like RPL stake or node size will be weighted in the process.
A complete specification isn’t required, but clearly outlining the intent is important.
It is an implementation nuance but I mentioned in the thread that this process should be a fallback to the rETH withdrawal liquidity mechanism. People could use this mechanism but we service the burn automatically if rETH withdrawal liquidity is available.
I totally agree. It would be amazing if the team researched this topic and gave their recommendations so that pDAO can make an informed choice in a separate RPIP. Is it possible?
I support this. It will be hard to come up with the actual factors to exit validators.
Looking at performance is probably the best indicator. Size of node operator comes next. RPL staked is more of a bonus, and doesn’t matter that much to me as it doesn’t improve rETH performance or decentralization of the node set.
Here’s a quick idea of a system I could support (I have no idea how to implement any of this):
performance below below 80% => exit a random minipool as long as the node of that minipool has more than 5 in total
performance below 90% => exit if the node still has 10 in total
performance below 95% => same but for 20
That’s just to avoid people losing their only validator, or loosing a significant part of their stake. RPL staked could then be factored in somehow.
Just spitballing an idea here, but could the forced exit offer the choice to the node operator to exchange rETH against ETH at the going rate, as an alternative to exiting his node?
I think RPL staked should play a role. We should always be looking for any way to increase RPL demand. RPL price should be a concern in all areas of change.
Spitballin here: Could we use some of the votershare ETH to spin up rocketpool-owned validators that could be exited via vote or preset algo?
Would amending the RPIP so that the current list of selection criteria is described not as an unordered list but rather as a priority-ordered list be sufficient?
So this general idea has been around for 6 months or so and while there has been some conversation going on in the discord, it seems like there is really nobody in the pDAO willing or able to work out these important details. I think the idea of the RPIP is to ask the team to work on it instead, so that we don’t have to wait around until someone steps up.
I would totally understand if the team isn’t comfortable making these kind of choices without pDAO input and I don’t think they need to. You guys could come up with some options, research and analyze them and then present that work to the pDAO to vote on for example. If you feel strongly that one option is the way to go, it could also be a vote to ratify that choice. This allows us to get the ball rolling now and lock-in details later. And it would hopefully give pDAO a better understanding of what we would vote on, based on your work. We could throw a vote together now as well, but it feels like people would just be picking something on gut feeling and without really understanding the impact. If we can’t find a single person willing to work on this, I don’t expect the average voter to analyze options deeply either.
Just add an idea I haven’t fully fleshed out yet: What if the exit process worked more like an auction? Node operators could set their own exit fee rates, and those fees would be charged to rETH burners who want to exit.
rETH is already charged a pretty high commission. Why would they need to pay extra just to unstake? It would also mean there would be a persistent discount because you don’t have to pay that fee when swapping out.
This would be my preference for selection priorities:
First sort megapools by their RPL/ETH ratio (megapool_staked_rpl/megapool_bonded_eth). Exit from lowest to highest RPL/ETH ratio
As a tie-breaker (for example ETH-Only megapools with RPL/ETH ratio = 0):
a. Group megapools by megapool_bonded_eth amounts. If it is less than “X” it is considered “small”. Otherwise it is considered “not-small”. For “X”, an example value could be 16.
b. If any “not-small” exist: randomly exit from this group
c. Else, sort “small” group from largest to smallest megapool_bonded_eth amounts. Exit from largest to smallest (for tie-breakers, randomly exit)
Some explanations for why I prefer the above:
Relatively simple
Rewards protocol alignment
Messaging is clear: stake more RPL to avoid being exited
Provides additional utility for staking RPL (even staking a small amount can give significant benefit compared to no RPL). Increases voter base since even a small amount of RPL can now allow you to vote (where previously, staking a small amount of RPL only provides a small amount of voter share rewards which may not be worth it vs. ETH Only)
For tie-breakers, the “small” prioritization helps since the node operator experience of an ejected validator is increasingly worse the less bonded ETH you have
X = 16 as an example since it prioritizes decentralization (likely independent actors who only provide < 16 ETH total), but avoids incentivizing sock puppet with bond curves in place (requires the node operator to miss ~half the difference in boosted APY they could be getting by consolidating larger amounts of ETH to the same megapool). See the pic from https://rpips.rocketpool.net/RPIPs/RPIP-42 below for reference:
I think Node Operator performance is a lower priority and should be addressed more comprehensively as a separate issue. (Something like rETH restitution has previously been discussed - where Node Operators should always be held accountable to making rETH whole for significant under-performance).
I think sorting by commission (and allowing Node Operators to set their own commission) unnecessarily complicates things, especially right after we will have just simplified the protocol with UARS where node operator commission is set to the same value universally for all megapools.
(You can jump to the bottom for the questions, but I’ll start with the context):
After some further discussion with @knoshua in #tradingnear ~here, to here, I would prefer to optimize for keeping things as simple as possible, and expedite forced exits for rETH withdrawals in Saturn 2. I don’t think we should expect most NO’s to be meaningfully impacted by withdrawals unless the protocol is experiencing significant downsizing/winding down - but in that case most NO’s are likely to be impacted anyways and priority selection shouldn’t make a large difference as most are eventually exited. The goal with UARS is that we should be able to better manage supply vs demand dynamics, and with megapools the cost to recreate the validators after being exited shouldn’t be a huge deal.
In practice I think the most straightforward implementation would be random selection, as it seems the most “fair”. I think it could still be helpful to categorize megapools by: “small” and “not small” and exit randomly from “not small” first, and only exit from “small” if there are not any “not small” megapool validators left. (I’m defining small/not small in the same way as my previous post/current rpip71 as of today). I don’t think the “sort from largest to smallest” within “small” would be necessary as I would expect it to be a rare scenario anyways to exit from “small”.
I plan to delete most of the details I had added to rpip71 to simplify it so that there could be a vote for inclusion in Saturn2 and the research/implementation details could still take place in parallel.
On another note, the other feature I would want to prioritize for Saturn 2 inclusion would be a basic form of “rETH protection”, where significantly under performing megapool validators would be force exited. This could be a stepping stone toward “rETH restitution” (where rETH is made whole from penalized NO’s for their underperformance prior to them being exited). For nodes that are fully offline / causing significant drag on the protocol we could at least start with “rETH protection” by at least exiting them before they incur significant costs on rETH. I think this feature should be simple and feasible for Saturn 2. I think this should be an independent mechanism from withdrawals, and would warrant it’s own RPIP.
TLDR:
I was curious what the teams feedback would be on implementing these two items in Saturn 2 (forced exits for rETH withdrawals, and rETH protection)? At what point would Saturn 2 scope have to be frozen to avoid delays in Saturn 2 release? Does the team find these two items feasible to include in Saturn 2? Would it meaningfully improve the schedule if the GMC were to fund research and spec work in parallel for these two items similar to the rest of the Saturn RPIPs? At what point would the specs need to be completed to avoid delaying the team’s dev work on Saturn 2 if this work were to happen in parallel?
