This would be a proposal to both: 1) Immediately close the node operator (NO) minipool queue until it clears of ALL existing minipools in the current queue, including the long-time waiting full minipools. 2) Once that has occurred, re-enable the NO queue with the full-minipool (32 ETH) deposit option disabled.
This proposal can be done by setting switches in the protocol and would not require a code change. Full minipools could be reenabled, if needed, at a future date once protocol improvements are made. Such improvements could be the proposal to mint rETH as a reimbursement method or by allowing full minipools the same FIFO queue processing privileges as half minipools. (N.B. It is unclear to the author if the RP protocol has a business need for full-minipools deposits.)
Justification: Currently, when the NO queue exists (i.e., the demand for minipools exceeds the demand for rETH minting) newly formed minipools are placed in a queue. However, the priority is such that half-minipools (16 ETH) are always placed ahead of full minipools. This means that full-minipool NO risks not advancing in the queue at a predictable rate. Worse full-minipool NOs risk being stalled (always at the back of the line) indefinitely. This results in these NO who did not realize the risk of locked capital ultimately having a bad user experience and frustration towards RP.
Cons: A node operator that wants to participle in either RPL staking rewards or ETH staking rewards will have to wait for the NO queue to advance before participating in the rewards. This could result in lost opportunity costs for both but comes at the risk of having 16 ETH of capital locked up for an indefinite amount of time.
I would also support simply hiding the the option in the smartnode (and asking allnodes to do the same). If someone has the know-how and goes out of their way to call the contract manually, they donāt need hand holding.
As a question, what would happen if someone tried to do a full/half deposit while the respective queue is disabled?
I donāt really like the proposed āsolutionā of disabling both queues, but all the other options seem even worse, so Iām inclined to support this.
Additional con: Once the queue is empty, MEV bots could capture deposits until the queue is reenabled, so I would suggest temporarily disabling rETH burning as well (if thatās possible).
For a better new NO experience while the queue is closed I suggest a new āwaiting for queue to reopenā role on Discord, which can be self-assigned and will be pinged once the queue opens again.
Iām supportive of disabling the 32 ETH option, but not supportive of disabling deposits entirely as a way to flush the queue. That seems like a heavy handed approach that would introduce significant downsides (poor UX, confusion/messaging, perception of RP failing or being unstable) to solve what is effectively a medium-impact issue.
IMO the fix here is simple: remove the 32 ETH deposit from the CLI (or sufficiently bury it with scary disclaimers), and let the existing 32 ETH minipools get cleared naturally when the next whale comes along.
Are you aware of 16 ETH minipools front-running the 32 ETH refunds? The 32 ETH queue did not get ācleared naturallyā when we had our last 5k ETH whale deposit because of that.
Unless we have someone watching and manually assigning all the refunds, weāll have the same issue the next time a whale comes along.
I support disabling 32 ETH deposits as users are usually not fully aware of the tradeoffs involved but I also think this is not a high-impact change worth closing the queues for new users so Iām against shutting down both queues entirely. Removing the option from the user interface should be enough until we can take other measures.
Iām one of the unlucky ones who is stuck in the full 32 ETH queue. I used allnodes to setup three validators and the disclaimer didnāt describe clearly the consequences of depositing 32 ETH.
I should have read the RP docs more thoroughly and thatās on me. I thought I would be put into the normal FIFO queue to receive my refund.
We donāt know when or if the refund queue will clear. Knowing this may go on indefinitely is very stressful. Iām out 48 ETH until then. Thatās a significant part of my life savings.
I think this should be fixed now (while in a bear market) before this becomes a bigger problem when retail starts flowing back in.
I agree with turning off or discouraging (hiding) the 32 ETH deposit option.
Iām not sure I like the freezing of the current queue however. I understand that the point is to let it clear and allow the remaining waiting 32 ETH deposits to clear as well, but I donāt like that it would stifle NO growth.
Obviously right now, minipool demand is in surplus, but that has not been the usual and I imagine as crypto begins to stabilize out of the bear, whenever that may be, weāll see this flip back to rETH demand surplus and Iād like to keep growing staking capacity as much as we can now.
While technically possible for the queue to exist in perpetuity, I donāt believe this is a realistic concern and the 32 ETH deposits will eventually clear.
I guess part of the question is how quickly can we toggle these? Is it just a setting oDAO can vote on or something? Can we turn off the half-pool deposits and then get to within 1 vote of turning them back on so itās very fast when weāve cleared the refunds?
Hi, I am one of the node operators who recently did the 32 option without realizing the consequence. It was really easy to make this mistake as there are comments in the docs/discord about the 32 option been a way to skip the queue and it was easy to assume that there was no downside risk.
This proposal would be awesome. I really appreciate this community. Every time Iāve asked a question I had an answer typically in minutes.
Its definitely something that needs to be warned and restricted more during minipool creation as a node operator who was thinking of 32 ETH deposits a long time before there was an empty dp.
I was not aware of the possible consequences of locking up your Eth indefinitely like we have with the current senario.
This issue will only be made worse with the introduction of LEBs as the minipool queue will grow as RP becomes even more attractive.
There is no parameter to disable full deposits so this is the method we would need to use to remove them. If someone is educated enough to bypass this and do a full deposit anyway then they probably understand the risks involved and more power to them! A contract upgrade would be required to fully disable them.
Iām not advocating for the removal of full deposits. Only commenting on the technical side of how it would be done.
I misread the code, as you and Kane pointed out, there is not, contrary to my OP statement, a way to use a setter to disable Full Deposit amounts. There is only the setting to enable or disable node deposits checkDepositsEnabled().
Perhaps a solution is a combination of pausing the NO queue to allow for the exiting full minipool in the queue to advance to a refund once as ETH deposits permit. Followed by removing the 32 ETH deposit option from the client software as Patches suggested in this PR. In addition, we would need to communicate the protocolās recommendation not to use Full 32ETH minipools to All Nodes as well.
I am in favor of discouraging the 32 ETH deposit option by hiding it in the CLI.
I strongly suggest not to pause minipool creation. Iām of the opinion that it will be impossible to explain to the general public what the reasoning behind this drastic measure is. It will only create negative PR and slow down Rocketpool adoption.
Also in favour of removing it in the CLI but not for pausing new deposits.
This is understandably frustrating for users waiting for refunds but ultimately it is a temporary problem that should resolve itself.
I would suggest politely requesting 0x7C5 pause new minipool creation or to do so in smaller batches to allow more time to free up refunds.
In the interest of minimizing damage I suggest we treat these as two separate proposals, the first being to remove the 32 eth deposit option (from CLI or otherwise) and the second being to flush the queue (latter dependent on the former).
It seems like every day a new disappointment spawns on discord, and I really hate to see it.