Now that the Atlas update has been successfully deployed and is running smoothly, we can turn our attention to the future of Rocket Pool.
The community is the heart of Rocket Pool. We believe that by working together, we can build the best possible decentralized staking protocol for Ethereum.
We need your help in co-creating and prioritising the Rocket Pool roadmap.
Some great ideas have already been raised in this Discord thread:
What is clear is that the core team will be engaged in a fair amount of research and design. There are exciting Ethereum roadmap potentials and emerging tech that we could leverage to further our mission.
What’s next? We need you. We want your opinions to shape our focus and decide the themes to tackle and the features we build. Tell us what matters to you, so that we can prioritise. Once we hear from you, we’ll build out a solid R&D plan.
We are very lucky to have a vibrant Grants and Bounties program so not all the work has to be undertaken by the team, some coordination will be necessary to determine how to resource the initiatives going forward.
Software development is not a straight line, especially when we’re on the cutting edge. But as things clear up, we’ll work with you to plan out our releases.
As we chart our course forward, your voice remains integral to Rocket Pool’s success.
Thank you, this initiative is wonderful and speaks to the strength of the Rocket Pool team and community.
Two thoughts:
How can the core team and pDAO (management committees) align on strategy to drive the protocol forward effectively? For example, if strategic objectives around H2 '23 focused on L2 scaling and reducing oDAO trust, versus finding new NOs and improving onboarding flows, the GMC could lean into that and make rather different decisions. This question is somewhat rhetorical because this entire conversation sets the tone, but I wonder if we can work toward addressing this specifically.
Where do bizdev and marketing fit into the picture? There is clearly some overlap with rETH as a theme, but I wonder if there’s an opportunity to further emphasize marketing in a coordinated, consistent manner where it has often been adhoc and grassroots (not that the two are mutually exclusive).
Lower oDAO rewards. Spend elsewhere or lower overall inflation.
Reduce duties that rely on oDAO where possible.
Remove guardian from pDAO.
Rocketpools biggest selling point is that it’s decentralized. Doesn’t help our cause to have oDAO members receiving $30k+ USD monthly stipends with no justification and the ability to completely destroy the protocol if 10 of them group up.
Protocol efficiency has been one annoying negative that just comes with Permissionless operators unfortunately. Would it be possible to combine forced exits of very low performing operators with advantages for high performing operators?
On the top of my head i could imagine something like a dynamic deposit qeue where the primary criteria of ordering is past node operator petformance and the secondary criteria is time in the queue.
For example past Performance ranks a operator from 1 to -1 and new operators are 0. A Operator with high past Performance would be queued in front of new operators and worse performers but behind of even better operators. Operators with the same score would be sorted by their time in the queue. Such a ranking should be deriveable from onchain data i assume?
I think we could probably come up with more ideas to disincentivice bad performance and incentivice high performers?
I think coming up with a well rounded and ideally trustless incentive structure to push node operators to perform better is a really important task for the future. We can foster the operator quality we need and deserve.
@langers is there a reason LEB4 was not on the teams workshop items? Is it just too early to work on that since LEB8 just launched and since we need forced exits for it?
Partly yes, partly because the gas fees associated with minipool operation really don’t make LEB4s as attractive as they look on paper. I think they’re going to be much more compelling if we can design a way to have one contract for all minipools instead of individual contracts, and “gas is expensive” is already a point on the list so it falls under that.
I am a rocketpool node operator, so I am speaking for my self interest as well as the interest of rocketpool protocol.
I would suggest a RPL Buyback&Burn Mechanism in the future. The RPL token’s annual inflation is 5%, which means RPL’s price will slowly decrease in the long term, if Rocketpool Protocol has reached the maturity stage in the future (for example if node operator numbers are large enough and no newcomers are joining). Every month, I need to sell some RPL tokens to cover my monthly expenses. This creates a selling pressure on RPL price, especially if every node operator does the same thing, this put further more pressure on RPL price.
I suggest the following buyback&burn mechanism for RPL token: currently, the 8-ETH minipool’s commission fee is 14%. I suggest 13% goes to node operator, 1% goes to a pool, which is used to buyback RPL tokens from the open market (for example uniswap) and burn them. To ensure safety and openness, this buyback&burn process should be fully automated by smart contracts and take place on the blockchain.
I haven’t done thorough research and calculation about how to fairly split the 14% commision fee. 13% and 1% split is just an idea. I think it is a good starting point.
With the RPL Buyback&Burn Mechanism in place, RPL price will be more closely alligned with the Rocketpool Protocol’s adoption by the market and ETH price.
Agree with the inflation issue and the suggestion to reduce it from 5%, because 3% net APR is not all that attractive from a node operator perspective.
We could discuss a free market auction based mechanism similar to EIP 1559 that allows holders to benefit from utility and rewards operators a little extra for their effort and risks.
Maybe the arbitrary inflation can be removed and minting is entirely via operator rewards. This will make RPL more attractive to operators than it currently is.
By the time RP reaches its saturation rate, there would have to be new use cases to drive utility and burn RPL.
We can also allow operators to split the RPL risk and reward with rETH stakers. For example if an operator is only comfortable with contributing the mandatory 10% to their RPL matching funds, then the remaining 140% can come from rETH stakers. From what I understand, there are several people in the community who are already doing this ad-hoc ETH+RPL complementary matching in joint node operator funds. Overall this may drive RPL demand and spread the risk across a bigger cohort of participants.
From what I undertstand this sort of shift of tokenomics would be similar to the dual token staking that EigerLayer is trying to generalize for new protocols.
This is a good point. Operator efficiency is a reasonable metric.
I would suggest prioritizing an open source process from the community to contribute ways for improving high availability and fault tolerance for operators. Currently the smart node stack allows for fallback CC and EC nodes, but in practice that is not sufficient. I’ve experienced several downtimes over a period of 6 months, each lasting a few days:
Power outage while I was away. All nodes were down for a few hours and it took several days to re-sync.
One node had a hardware issue that caused it to crash occasionally. It took some time to figure out the problem. About 2 days of downtime.
Last week’s ETH finality issues caused some nodes to crash. It was not immediately obvious what the workaround is. Overall about 2 days of downtime.
I now have several standby nodes just in case, but that is still not going to help if there are hardware crashes, power outages, or multiple failing clients.
I see that high availability and fault tolerance is high on the roadmap. Once there is a reasonably easy to setup solution that home node operators can use with geographic and client fault tolerance, we can talk about enforcing uptime rules at protocol level.
If we rush with enforcement of uptime too early, that will drive the protocol in the hands of few large professional operators.
One thing I think we need to work on is figuring out how to work together better - the community has expertise and interest (on everything from web design to trustless submission of balances), which I think we can leverage more. Having a shared roadmap that’s somewhat up to date (maybe quarterly updates?) would really help there I think.
On to what I personally think is important:
Critical
Minimize the need for oDAO trust (guard rails on settings, trustless oracle submissions, etc)
Minimize the need for pDAO guardian trust (multisig, guard rails on settings, fully on chain)
Penalty rework
Important
Transparency - scorecard like lido’s
Simplicity for newcomers (some of this might already be in the website redesign)
Clearer Intro
Simpler APR looks
RPL staking discussion - why are we rewarding/locking way past minimum, do we want to be? is there a good way to get rid of the timelock?
Some long term thoughts
How we want to self limit
Some way to leave the RP queue
Going below LEB8 likely requires a change (eg, node-level collateral or negative commission)
Some way to handle atrocious NO performance
I’m talking routinely missing 30% of rewards. Note that it’s important not to aim for perfection here. We don’t want to push away small operators, we don’t want to push people away from home internet to cloud solutions, we don’t want to push people to the most performant client regardless of diversity. I actually don’t think even HA options are sufficient here - an NO with a single 8-ETH minipool shouldn’t be expected to deploy a geographically distributed HA setup.
We should force exit at some point
I would personally like to see RPL used to mitigate the damage done to rETH (again, mitigate up to some threshold, to allow modest underperformance)
Explicitly not important to me
RPL use cases (“this gives access to ETH commission” is one hell of a strong use case; governance is nice too)
Eigenlayer or other specific protocol integrations
As always, thanks for taking community considerations into account @langers!
I’ll throw my vote behind changing minipools over to use a single contract. This isn’t flashy, but it will increase efficiency for everyone as well as lay the groundwork for a more flexible architecture in the future. Surely this isn’t an easy tech debt to pay since we have to somehow continue supporting individual minipool contracts, but this does represent a huge efficiency boost.
On a separate note, the RPL tokenomics debate certainly needs to happen. It’s been said before, but although terminal tokenomics are still far away, they remain unfavorable. As important as this topic is, however, it’s also a sensitive one. The last time we had this debate, the community tore itself apart in the process. I know several good folks who left because of this incident, so I’d like to see more research and forethought before anything major is proposed again.
Given this, it’s probably best to take smaller steps rather than a larger tokenomics overhaul, so I’ll propose the first baby step here of unlocking <150% collateral as the easiest bite-sized candidate for research. At first blush, it seems largely useless to lock up RPL post-withdrawals since anyone can exit, unstake, and restake again.
I want to emphasize that other tokenomics changes are a very separate discussion, though. Rewards ratio adjustments, inflation changes, etc are all going to be far larger topics and need significantly more research to understand the implications. I don’t think we’re in a good place to start proposing any economic changes here until we have more thorough supporting research. Repeating our past mistakes will embolden competitors and jeopardize the credibility that RP has worked so hard to engender.
Great points overall. I think we need to be very careful with weakening RPL Tokenomics though, even if there might be advantages on a theoretical level.
Making people buy into a protocol utility token and weakening tokenomics of said token afterwards is probably the single best way to destroy user trust in the project.
In my opinion, once a project is released with modelled tokenomics and users buy in based on those tokenomics, there should only ever adjustments be made if they both strengthen/improve the protocol and are at least a net 0 for token value.
We allready had our fair share of controversy with the max collateral debate and at least in my opinion, that was orders of magnitute less impactful than potentially reducing the max RPL bond to max=min would be.
It might not seem virtuous to put tokenomics before a potential protocol improvement but we have a large userbase of which many are significantly invested and we owe it to them to be considerate imo. Hurting existing users financially is a big deal.
I think a way better approach is to come up with new ways to add further utility to RPL and make the high collateral some people provide worth while for the protocol.
I think the break in trust usually comes when the changes are abrupt or unexpected. Eg, a decision to change inflation from 5% to 2% after passage of an RPIP is very different from reducing inflation by 0.25% every quarter for 12 quarters; the latter gives people time to make changes in how they value the protocol and reduce/increase risk, and gives the protocol time to adjust if the changes don’t have the intended effects or if the intended outcome is reached before completion.
Additionally, weakening tokenomics while boosting the protocol, for a utility token, may positively effect token price. But it’s usually not clear beforehand. Are withdrawals (bad tokenomics, good for the protocol) positive or negative for ETH price? Time will tell.
All this is to say I think these discussions should start soon but no decision should be made anytime soon.
Certainly. I would actually say the broader “changing” tokenomics. That said, I think there’s still a path with talking to find common ground, a significant heads up or slow changes, requiring a supermajority, etc. LEB8s were a good example of significantly changing the protocol and tokenomics with broad support (though before snapshot).
Highest priority for me would be oDAO trust minimization, pDAO guardian trust minimization and (MEV) penalty rework. These are essential to protocol security and credibility.
Of those, work is in progress on oDAO and penalty rework. The pDAO guardian has had earlier discussions on this forum, but they stalled in the pre-Atlas crunch. I think it would be good to revisit this topic soonish.
Other considerations in no particular order:
The single minipool contract seems like a big win to me in mitigating one of the protocol weaknesses (gas costs.)
Deposit ETH on behalf of - if I understand correctly, another advantage would be further reduced trust in the hot node wallet. One of the only remaining windows of vulnerability is a compromised node wallet where an attacker waits patiently for a large ETH deposit intended for minipool creation to hit the wallet. This would eliminate that attack vector and limit funds required funds for the node wallet to operational gas costs only.
Forced exits is definitely something to keep an eye on; use cases could be MEV theft resilience (LEB4 and otherwise), removing outlier bad performance / dead nodes, and enabling novel use cases like minipools that run for predetermined duration (Saas?)
Big challenge is of course enticing node operators to willingly upgrade to subject themselves to this. Might only apply to new minipools unless we can find some carrot to bundle it with.
On the topic of RPL use cases, we should not go out of our way to shoehorn in new use cases just to drive additional demand. I do think it makes sense to make good on the initial vision of RPL-as-collateral; the proposed usage in the redesigned MEV penalty system fits well here.
RPL tokenomics remain a tough subject, as others have noted. The tokenomics we have are far from perfect, but we also can’t make rash changes to a pre-existing, steadily maturing protocol. So, any large changes should be carefully deliberated and, if accepted, preferably take effect over a longer period of time so people have time to adjust. We may also have to accept certain radical changes may not be achievable within RP as it is now and should be implemented in a RP v2. (This has been informally mentioned in Discord - I don’t see it listed here explicitly though, where does it fit in?)
Likely related - ossified rocket pool is a very interesting topic, but it does seem slightly early to start this. There are a lot of puzzle pieces that would have to fall into place first for Ethereum and Rocket Pool.
Personally like gas optimisation roadmap items for node operators as it improves APR and liquidity (able to claim more often for same overall costs).
I like the options that work towards minimising and ultimately eliminating ODAO, not because I don’t like ODAO but it seems it’s the centralised piece of RP which is contrary to decentralization values. However, I appreciate there’s probably some hard problems to solve for full working decentralization.
RPL tokenomics I think it’s ok as it is in the current growth phase. Changes introduce unexpected risks to NOs (bad). Eventually if the ETH validator count hits steady state it may be worth gradually turning down inflation or off all together.
Should the Rocket Pool core team, pDAO, oDAO, IMC, GMC, etc. share one roadmap, or formulate roadmaps independently?
Does formal alignment on strategic goals have value? Or is the ad-hoc, bottom-up approach to independently observing themes that emerge across various discussions ideal for the Rocket Pool ecosystem?
