RPIP 71:
The oDAO SHOULD select minipools by prioritizing higher-commission minipools and SHOULD ignore any minipool that has received a
did_not_exit_penaltywithin the lastdid_not_exit_cooldown(defined in RPIP-80).
I think this is probably not appropriate. Commission is frequently node clustered, and this language means that all minipools of multiple nodes will be exited before other nodes are even touched. When making a change in the tokenomics i think as much as possible the negative effects should be spread as widely as possible.
Additionally, exiting 14% minipools before 5% minipools also means that a large amount of RPL that would be previously locked will be free- since there would be no way to make new megapool validators i assume this will be sold; that has negative impact.
Additionally, you will have to exit >two 20% validators for every 14% validator, so loss of TVL is going to be more than double. The marginal benefit of 20% vs 14% is not worth it.
All this is to say, I think exiting higher commission minipools is marginally better, but not enough to be picking winners and losers when making tokenomic changes.
I stand by (the unpopular argument) that I think megapool and minipools should both be eligible simultaneously, because megapools are a very small group of NOs (who tend to be elite in RP in some way), and specifically protecting them from negative repercussions risks appearance of non-neutrality. Additionally, less TVL needs to be removed per rETH for megapool vals.
The oDAO MAY use time until the next validator sweep as a tie-breaker between minipools with equal commission.
I can see why you would suggest this. However, to me it is possible this can be gamed by the oDAO, and also runs afoul of potentially exiting all minipools/megapool vals of a single node (many created at one time so would be grouped in validator sweep). The benefit is relatively marginal (a few days) and not worth risking concentrated negative repercussions of this vote.
Exit Hysteresis
This is currently targeted at rewards ~5 days; i would increase that. The token can always be sold immediately, and I think an amount above breakeven makes sense.
RPIP 73:
I think this is great. Overall, the tactic of the RP releases has been to trust NOs to make financial decisions in their own best interest; this has not been incredibly effective. Exiting NOs for performance is definitely less desirable than NOs improving performance. I think this would be a good place to request the RP team to prioritize additional notification options that are done more simply/seamlessly through smartnode, to avoid churn, bad feelings, and diminished decentralization.
The other small question is whether there should be an upper guardrail on the performance threshold- is there any theoretic time when exiting (let’s say) 97% effectiveness validators for performance will be needed without being willing to wait for oDAO hotfix?
RPIP- 80:
Looks good I think. Is the
did_not_exit_base * did_not_exit_backoff ** i
intended to be exponential? Is there a reason for this, and more generally why would you increase the amount on the 2nd or 3rdattempt?
I personally think that the 0.1E penalty is too low. A rough calculation is that a 14% minipool will earn about 0.11 E more than rETH each year, so by purposely avoiding exits it’s likely a minipool will come out ahead except in the case of complete protocol collapse (ie multiple exit requests in a year).
RPIP 44: looks good
RPIP 77:
seems good as written, trusting the implementation/audit. Is this intended to be an oDAO duty, as 12 hours is short for manual community member checks. Or is someone already planning to automate proofs “permissionlessly”? While the threat of repercussions remains, it’s toothless without an implementer.
RPIP 46:
agree that alternative use of voter_share is more of a “nicety” rather than a must have. Can be done later. I assume this needs an explicit RPIP addendum to specify why the previously voted-on action is not being performed?
RPIP 42: bond decision to decrease to 1.5 will need to be explicitly addended out.
RPIP 83:
So I strongly approve of the motivation here.
I think i disagree with a permanent setting here, for the same reasons of UARS- we don’t know what the optimal amount is, and 6 might be correct or might be wrong. I think that a pDAO setting between 1.5 and 8E is reasonable. Similar to the ideas of < Options forum thread - #7 by epineph > Preferential queue for higher ETH bonded minipools , it’s challenging for us to determine in advance what the demand would be. I think limiting changes to 1E every ?3 months? is likely to be able to find the sweet spot for migrations without perpetual RPIPs.
Additionally, I’m not knowledgeable enough to know how well this short RPIP plays with the rest of the protocol- ie, when your bond is going up each time a distribution happens, how does that affect smoothing pool generation (like is the rETH/NO bond when reward tree is generated, or is it calculated based on where node bond was during each attestation)? Is it possible to go above node bond, and in that case how do you receive your ETH reimbursement?
It seems that there will still be a substantial benefit for nodes that have already gotten 4E minipools compared to others for a decade. Adding additional bond would increase your earnings by less than solo staking (if i’m calculating correctly), why would people would do that? We may have to be more aggressive with underbonded nodes (eg, calculate all rewards based on a bond of reduced_bond regardless of the actual bond. However, if being below bond is more punitive and people exit megapools to hit bond requirements, is that a win?
I think this is a tricky topic, I’m not sure the correct number or the full reprocussions, so I think generally smaller iterative changes are preferable.
RPIP 82: Seems necessary for ETH, reasonable for the others if not terribly complex.
RPIP 85: I think this is low priority. Signaling with votes don’t need the high fidelity of on-chain, i think this is “nice to have” but would not want it to delay other rpips.
RPIP 87:
RPL Inflation: I wonder if a more granular, lower frequency inflation change is better- eg, keep 1% but make it so it can only be raised every 14 days.
Proposal quorum: I agree with lowering the guardrail; I would disagree with lowering the setting.
Upgrade veto: I disagree that a lower quorum is not inherently less secure - there are risks and tradeoffs. In this case, a single malicious member could veto a hotfix in perpetuity if security council is under 10 members. i don’t know if removing a member is veto-able, but seems like 10% is low. On the other hand, what is the point of setting veto threshold to >50%? I can see risks, but no benefits.
I’m also going to make another pitch for exit fee for liquidity exits. I realize this is seems unlikely to gain traction, but as always I’d prefer to say my piece than to see something suboptimal be rolled out. It’s a pretty rough proposal, so please attribute any inaccuracies to stupidity rather than malice.
Liquidity exit fee
This fee is going to be indexed to the queues- essentially charging the exiting rETH holder the opportunity cost of both the exit and the entrance queue. A central idea is that if there are large queues to enter or exit, the asset shouldn’t be expected to trade at NAV, but should tolerate small fluctuations.
Negative ramifications of no fee:
- stakers may choose to exit rather than sell into liquidity for a miniscule difference, or none at all. Like 100rETH on cowswap is currently -0.09% swap; if exited . However, the difference to the protocol and NOs is substantial between that sale (which has no effect on TVL/income) and exiting 4-7 validators.
A discount does have some harm for the seller, but also an opportunity for the buyer if the system goes to NAV. So assuming it is not extreme, it should be tolerated.
2 If TVL in a few weeks after liquidity exit is lower, there is no harm to the protocol. However, if TVL either remains stable or rises then there is a direct injury to all rETH holders that aren’t selling, which can be calculated by ((2)entry wait + exit wait)/365 * staking percentage, or about 0.5%. As the RPIP currently written, the fee is approximately (exit wait)/365 *2, or about 0.02%. As the queue decreases, those injuries drop.
-
A new source of (near) arbitrage would be available for bots to buy the discount that is accepted by sellers and use it to exit validators, keeping the profit; any negative deflection from NAV> ~0.02% would do. This is not necessarily a service to the protocol- obviously the sellers were still selling despite having the ability to request exits themselves.
-
A possible source of significant griefing becomes possible, which (to me) doesn’t seem explained in your repeated mint/burn: An actor could mint 1 million ETH and then request exit for 1 million ETH, reducing rETH APR by 2/3 for 3 months while gaining more than gas prices in rETH appreciation (estimate 0.33% appreciation with 0.05% cost).
Even repeated small malicious actions would appreciate in ETH terms despite the cost (ie holding rETH for 7 days breaks even in ETH terms). repeating this 52 times in a year would cause no loss of principle to the malicious actor but 26% loss to the protocol of whatever principle was used. Obviously these “small” actions would still need to be well above the 100E level.
My conclusions:
I don’t think a small exit fee will have a negative effect on rETH demand, most particularly returns for [all rETH] remains the same- while some will be less, some will be more. Or if you assume that some people will not buy rETH because they may get additional fees when exiting, you should also assume that some people will buy rETH because they will get additional fees while holding. Additionally, there is a benefit to NOs/protocol/rETH holders for people choosing not to exit but rather to sell.
Other possibilities:
The fee does not go to rETH holders, rather it acts as incentive for minting (hence keeping TVL the same)