Big picture:
This is totally my opinion, maybe it’s right or wrong. There is a lot of work being done in RPIP 71 Discord and RPIP 73 Discord regarding execution level (or other) exits for liquidity and underperforming NOs respectively.
I think that it may be beneficial to break these into a couple pieces, specifically generally team facing RPIPs to help define HOW to enact exits, and then community facing RPIPs to determine WHY and WHO to exit. The team facing RPIPs are going to be technical and likely above the ability of most NOs to participate directly, instead relying on trusted delegates; in this case, there are likely many correct ways to reach a specified output, and the decisions of which are most favorable are understood by only a handful of knowledgeable individuals. The community facing RPIPs would be both accessible to NOs in real terms, and may also change in the future as either the DAO changes or new information arises.
The intent is more participation by the DAO overall. Additionally, avoiding a vote where NOs have to vote Yes/No on a package that includes both technical and political parts, either delaying the former or agreeing to the latter to avoid delay. So I’m going to release a few forum posts regarding the political parts (here penalties for people who are not obeying NO responsibilities, later exits for performance, exits for liquidity, and possibly penalties for MEV theft); they may eventually form new RPIPs or get rolled into existing structures. This one may be the most controversial.
Motivation:
With the passage of RPIP-77 Smart Node Default to Use Latest Delegate, the pDAO has indicated that it is interested in pursuing forced exits; this will need a voluntary upgraded delegate by the NO, rules governing exits, and a system in place at the protocol level to execute. These discussions are critical due to increased staking competition, most of which provide better performance AND liquidity than rocket pool, and (in the case of CSM) are increasingly seen as a decentralized option. Rocket pool, for example, misses ~2.8x as many attestations per validator as CSM, and is easily the worst performer amongst all named staking solutions https://beaconcha.in/explorer ,
Forced exits are beneficial for NOs indirectly by improved rETH staking rewards leading to increased rETH staking, which then increases RPL rewards proportional to TVL and increases NOs rewards when NO_share can be raised (or not lowered).
Forced exits are also beneficial for NOs directly by preventing complete loss of stake in several circumstances (loss of private key, death or disability of NO, loss of interest by NO, forgetting the minipool exists).
Unfortunately, in a tragedy of the commons, a NO may feel that it is not advantageous for them personally to ULD, while acknowledging it is very markedly advantageous for everyone else to do so; if enough NOs feel the same the indirect benefit is diminished for everyone. Similarly, it is hard for anyone to rationally price rare but devastating events (like your own death); no one thinks that they are the one to lose a private key, and yet we have many minipools that have been dead for years.
All megapool validators will have upgraded delegates, so this is intended for minipools that have chosen to not ULD.
Proposal:
Create a penalty system for minipools that meet DAO prescribed criteria for execution level exits, but cannot be exited due to not allowing ULD; this would be enacted only after a mechanism for forced exits goes live.
Suggested messaging:
Rocket Pool has a recommended pathway and rules of conduct that encompass all NOs. NOs may have reasons to choose a different advanced user pathway, but avoiding core NO responsibilities will not be one of the reasons.
Community input requested:
1. In general terms, should we adopt a penalty system for minipools that meet criteria to be force exited but cannot be? Do we have any other reasonable way to reach these minipools (smartnode may not be a good method due to presumably it not being updated).
2. Regarding exits for performance, is it sufficient to make the penalty equal to the losses that the NO would otherwise have felt due to exiting? Or equal to the amount of damage to rETH that reward period (For NOs with >50+% performance as validator balance remains >32). Should these penalties compound each period the NO doesn’t exit.
3. Regarding exits for liquidity, what penalty should occur if a minipool is not able to be exited (optimally nodes should be given the chance to exit voluntarily at consensus layer first without penalty)? A fixed amount, a proportion, some formula based on queue lengths or amount of liquidity demand?
4. Are we comfortable with this being an oDAO duty?
5. Is the risk of bad debt at exit trivial (if penalties are assessed but minipool still bleeds out to 16ETH)? From my standpoint, this event will happen in about 20 years, and is through enough event horizons that it likely does not matter.