The Rocket Pool protocol is currently based on a balance between NOs making 16 ETH deposits and rETH being minted, which allows ETH to be matched and complete the 16 remaining ETH to create a minipool. As good as the current design is, it suffers from a serious inefficiency: all the ETH deposited for the creation of minipools sits idle, maybe for weeks or months, until it can be matched with deposits from the deposit pool. Today we have 225 minipools in the initialized state, representing 3,600 ETH sitting idle which could be earning effective rewards for the protocol and improving the rETH value. The protocol is keeping this amount of ineffective ETH for months now, blaming the lack of new rETH minting, but hey we have the ETH needed inside the protocol, why not put it to good use?
The proposal
This proposal is simple: Every ETH that enters the protocol should be put to work ASAP. To achieve this we should allow the protocol to match the remaining 16 ETH to form minipools not only from the rETH side but also with new ETH coming from minipool deposits.
This could be achieved with a simple solution. ALL deposits on the system would flow to the same deposit pool and be available to be assigned for minipool creations. rETH would still only be minted from regular deposits and not from minipool deposits.
In the case where we have a minipool queue, when a NO makes a new 16 ETH deposit, those funds would then be used to match the oldest minipool waiting in line, allowing it to start receiving rewards from attestations, block proposals (with tips + MEV after the merge) much sooner than the current scenario. Remember: no rETH is minted for NOs, so using their ETH immediately would improve rETH’s APR.
Pros
Greatly reduce the ETH that would sit idle after entering the RP system. The maximum amount of non-productive ETH would be reduced from the current ~3,600 ETH to 31.99 ETH;
A deposit for a new minipool could make the queue move even if we don’t mint new rETH. Being a better UX for NOs;
Slightly increased rETH APR when there’s a minipool queue (good for rETH holders). If there is a BIG queue the APR increase would be more relevant becoming an incentive for new users to mint rETH;
More RPL demand and more RPL locked (good for everyone who believes in RP);
More room for rETH minting (protocol growth);
This could simplify the LEB design: with this proposal, every minipool waiting in the queue would be holding 0 ETH, either a LEB minipool just created from a new deposit or one being converted from an old minipool. This way every minipool would need to be completely funded when its turn to be assigned arrives. Both would need 32 ETH from the deposit pool and no special treatment is required after they enter the queue;
This benefit for LEBs would make this proposal a good candidate to be implemented together with the LEBs required contract changes.
Cons
As the queue would move faster (able to create minipools even without rETH minting), we would expect the system to find a new balance, probably with more minipools in the queue (I’m listing this as a con because some people see it that way. For me, it would mean the system is growing faster and supporting more users);
Would require new implementation and audits (but as mentioned, LEBs will already require that, so we could ship these changes together)
The same logic described here is valid for 8 ETH deposits when LEBs are live, but I’ve used 16 ETH on examples so readers can relate to our current design.
We can also discuss a small variant of the idea where the minipool makes a first 1 ETH deposit into the beacon chain that could be used for scrub purposes and 15 ETH would go to the deposit pool.
As you know, I ended up against this due to small benefit (very marginal rETH APR, slightly faster queue which we’d expect to get balanced by a larger queue so no net benefit). On the costs side, I saw implementation time when other things are higher priority to me.
You did have a new pro on your list, which definitely caught my eye, about simplifying LEB design. If @kane thinks this makes implementing LEB8s easier, that’s very convincing to me (effectively makes the cost I see into a benefit).
If we were starting from a blank slate, this design would simplify LEBs as you say. But to go from where we are now to having this and LEBs would probably add more complexity. Complexity in the way of more changes to the protocol not the complexity of the protocol itself. So I’m not convinced that argument is one we should make the decision on alone.
The real question is whether the improved productivity of the ETH makes the change worthwhile. I’m of the opinion that in the long term will we be constrained not by user deposits but by node operators, so the current minipool queue is more of a short term problem. Happy to hear other opinions on this.
I will keep this idea in mind when getting into the more nitty gritty implementation details on LEBs to see if it does offer to simplify things.
I very much like this idea. The queue efficiency would be improved significantly in our current situation where node operator supply outstrips demand for rETH. If/when the tables turn on that and rETH gains the upper hand again, there’s still significant upside for SaaS like operators imo.
SaaS operators need their deposits to be staking asap, idle ETH is not good business for them. So regardless of the current market dynamics with rETH vs Node op supply, just having the promise that their ETH deposits on the node side would be put to work efficiently, rather than sitting idle is a great outcome imo and hugely marketable towards budding new SaaS providers.
Plus my two 32 ETH minipools might finally get funded
Great work guys! We could def have a look at fitting this in with LEBs imo.
I really want to be very explicit about what we can and cannot expect from this idea.
If we’re NO limited and have no queue, this has literally zero impact, so let’s ignore that case.
I’ll assume I have a queue 100 long, with 10 minipools dequeued per day and 10 new minipools added to the queue per day. This amounts to saying that potential NOs are willing to wait up to 10 days to have their minipools start. What should I expect if this idea gets implemented?
Immediate effect: For each minipool that gets added we immediately kick off 1 of the minipools in queue. If the market is being sensible, it’ll notice they can get the same slot in the queue, so we’ll actually see 100 new minipools added. Our queue is still 100 long, and now each minipool needs 32 ETH to start off.
Stable effect: if we still get 160 ETH from users per day and NOs are willing to wait 10 days, where do we end up? It turns out we end up at a queue length of 100 adding 10 minipools per day. The minipool deposits contribute another 160 ETH, which is enough to start (160+160)/32=10 minipools. The queue length doubled in ETH capacity, stayed the same in number of minipools, stayed the same in number of days.
So what have we seen overall?
Big benefit for the people that were already in queue when this policy started
No benefit for NO wait time once things have stabilized; this also means no change to ROI calculations at all
We can figure out how much ETH is generating additional rETH APR easily: it’s `queue_length * 16 * .85 = 1360. What’s the impact of that? We divide by total rETH TVL to get ~1.3%. That would move rETH APR from the current 3.62% to ~3.67%. This is a small effect (in fact, it’s exactly like the deposit pool drag, but in reverse).
(I left out a detail here - we likely need to reserve 1 ETH for prestaking, so the impact will be just a bit less; but the concepts apply)
As you can see, my analysis is we get a very small improvement to rETH APR and nothing else. This is why my focus is on the contract side.
Is it easier to implement LEBs alongside half deposits this way? I think the answer is yes, because we end up requiring 31 ETH to kick off any minipool (we still need to use 1 ETH to prestake) instead of having different deposit types. This is, to me, the thing to base our decision on.
Is it more gas-effective to do things this way? Again, I think the answer is yes (though it’s not a big advantage) because we’ll only have 1 queue instead of multiple per deposit type.
I have some starter code showing what this could look like. Not quite ready for a PR, but I’ll do that once I’ve given it another look.
Thanks for the reply @kane and @darcius. It means a lot.
I agree we will have moments where we have a NO queue and no ETH waiting in the deposit pool and moments where we have a full deposit pool and no NO queue. I don’t expect us to always be at one side.
But both cases today result in the protocol holding unproductive ETH. This proposal aims to fix the ineffective ETH issue from the first scenario while making LEB design easier.
We could in the future have a different proposal to better use idle ETH waiting in the deposit pool and tackle the scenario you believe is most likely.
I’m reviewing Valdorff’s SC draft and can only see benefits for the code simplicity.
So another idea that came up in the recent discussion on Discord (full discussion starts here, relevant discussion here) is to mint locked rETH for the NOs stake when they join the queue as a bookkeeping measure. When it is the NOs turn to be matched in the queue, enough of their locked rETH would be burned to account for their “lent” ETH (16 - 1 or less for LEBs). If their wait went past the price update, then there would be additional rETH remaining which I am proposing be sent to the pDAO treasury (this relies on whatever mechanism holds the locked rETH to be whitelisted from the redemption fee).
Effects:
There would no longer be an rETH APR bonus
The protocol will slowly grow a more diverse treasury in rETH during periods of NO surplus
For perspective, starting from @Valdorff’s queue figures (100 minipools) and current rETH APR of 3.62%, this would generate ~58 ETH worth of rETH/year (under the assumption all rETH is converted to ETH, so actual value would be higher)
One use mentioned could be for liquidity incentives (so the ETH used by NOs in queue is indirectly being used to benefit them by helping increase rETH demand)
NO queue opportunity cost stays the same (ETH is unproductive to them) so it shouldn’t balloon in size
Costs:
Further complexity (locking rETH, redemption fee whitelist)
Likely higher gas costs for going to staking (burning and tx rETH)
???
Whether something like this is worth it depends on the assumption that RP will be primarily NO restricted or rETH restricted which I think opinions in the community are still mixed.
It’s been a while since I looked at rocketpool’s logic. But why wouldn’t you want to treat queued node operators as regular rEth depositors, hold the rEth for them paying normal fees to the other node operator? Then the rEth is passed to the next depositor when a matching deposit is made. How much is held by the protocol vs in the wild fluctuates based off of the node operator deposits to non-node operator deposits ratio. All eth stays as productive as possible. Node operators receive yield while waiting in the node operator queue (granted at a lower rate than if they were actively operating–until they make it through the queue --but still much better than having everything locked up and it doing nothing until they make it through).
In the large queue situation, we have more potential NOs than we need. We shouldn’t be further incentivizing NOs by providing yield while in the queue. If we use that yield for something it should be for a different party than the NOs: rETH holders or “the protocol”.
I disagree that we should redirect yield away from waiting validators in the queue.
Ultimately, I see success for RP defined as “the most amount of ETH staked with RP as possible while preserving a healthy Ethereum.” In the long run, this means competing with other staking options for the same ETH (this is also why I think we have to compete on commission, but that’s another discussion).
Validators will go elsewhere if RP is unattractive, and especially in a post-withdrawal world, immediate yield will be very important to attracting validators. If we can put deposited ETH to use immediately, we should. It makes RP more attractive than it would be otherwise.
Remember - this proposal ONLY does anything when we have a queue (ie, people are literally lining up to be NOs). If we are bottlenecked by NO supply, then this cannot help because we’ll have a full deposit pool and no queue, so making the queue more efficient is ineffectual.
Yes, to clarify my position here, I believe RP should be as competitive as possible as quickly as possible. It’s going to be much harder to move the needle in 5 years when the Ethereum staking landscape is more ossified.
Well, except currently the problem with having a NO queue is that all that ETH is unproductive and does not contribute to Rocketpool’s growth. If we can use all NO deposits to fund active validators, all deposits are positive for Rocketpool.
