Intro:
A staging pool (SP) offers RP users to deposit any arbitrary amount of eth into the protocol to recieve reth as soon as possible.
Problem:
So far, the reth demand exceeds by far the amount of new NOs. Therefore, the deposit pool (DP) is basically always full.
- Users have to wait and check for when DP empties.
- Users might have to split up their eth deposits in batches.
- DP size. Nr. 2 gets very problematic when the size of deposits exceeds the size of the DP by far (e.g. 10k eth deposit vs. 2k eth DP size limit)
A user might face one or all of the above mentioned problems. Gas costs, timing, management makes the overall experience very problematic.
Proposed Solution:
Add another pool called Staging Pool on top of the DP (naming by @knoshua). A staging pool is an unlimited pool that users can send their eth to in any arbitrary amount. eth deposited into the SP is not yet staked and gets no rewards. In exchange, they dont have to care about timing, management, or gas costs since the protocol itselfs manages the process of getting their eth staked as reth.
Additional:
- A Staging Pool could be deployed on L2 as well. eth on L2 could then be transfered batchwise to L1 which should save gas costs.
- We will get to know a more accurate demand for reth
Questions:
- Priority of eth deposits into the DP vs from the SP
- Who pays the gas costs of transferring eth from the SP to the DP
- Should the choice be given to the users what pool they deposit eth into?
I have some more thoughts, might add them later these days. But more interestingly, what are your thoughts?
1 Like
I like the idea but two questions:
1 - how difficult is this for the devs to implement
2 - could this be done outside of the RP devs, as its own project? Maybe get a grant from RP?
I really like the idea of using the Staging Pool as an L2 mechanism to receive rETH. To me that seems a great way to open up the staking world to smaller and smaller ETH holders. (I guess I would define them as those that would like to deposit 0.05 ETH and less. )
Would the user then receive “L2-rETH” in return?
From my reading today, this would make rocket pool have similar economics to lido:
https://twitter.com/RyanBerckmans/status/1396591162664919057?s=20&t=Lsju1KvdN-Z6ED2sn2azIQ
And asking about this on the Lido discord:
That said, your proposal seem to address this concern with the staging tier, where unlike lido’s immediate socialism, your proposal works more like a preorder
eth deposited into the SP is not yet staked and gets no rewards
1 Like
the core of the problem isn’t around deposit or demand. It’s specifically about attracting more node operators.
16 ETH is ~$48000 in today’s price for ETH. The issue is Specifically that the barrier to entry as an operator requires two things:
- ability to operate a linux environment and be comfortable with it. People can learn, but it also scares some folks away, which is one reason why people prefer rETH.
- capital to deploy. $48k USD is a sizeable risk and a vast majority of users globally don’t have 16 ETH today. That creates a limit on the available supply of capital.
You have to solve for those two issues if you want to solve the issue of the pool being full all the time. The solution as proposed is really intractable to the actual issue.
The UEB proposal is a far better solution to the issue of the supply vs. demand problem, but the inherent problem is one of trust that the NO will maintain high uptime and avoid being slashed.
Slashing is and should be pretty rare with the existing solutions within the client today (to turn on slashing protection and the attestation wait when bringing a node back online due to maintenance, etc. to avoid accidentally bringing two nodes online at once and getting slashed).
node supply is the key. This won’t really do or fix much of anything and the implementation would also be overly complex and time-consuming from the dev. side. There are much better uses of time and grants, IMO to fix the supply-side problem.
