Hey everyone!
As per RPIP-37 Protocol Development (RPIP-37: Protocol Development), the core protocol team will facilitate a prioritisation discussion with the Rocket Pool community.
With the following RPIPs’ imminent ratification there is a significant amount of work ahead of us.
- RPIP-49 Tokenomics Rework
- RPIP-42 Bond Curves
- RPIP-43 Megapools
- RPIP-44 Integrating Execution Layer Triggerable Exits
- RPIP-46 Universal Adjustable Revenue Split
- RPIP-47 Enable Forced Delegate Update
- RPIP-59 Deposit Mechanics
- RPIP-60 Protocol Upgrade Guardrails
- RPIP-57 Node Distributor User Fund Unbundling
- RPIP-58 MEV Penalty Guardrail
- RPIP-61 Balance Submission Guardrail
These RPIPs and prioritisation generally can be organised around particular themes to help guide what we want to achieve and identify any gaps. I have organised them around the following themes but I would love to hear the community’s opinion on what themes are appropriate.
Tokenomics - the outcome being long term sustainability
rETH Demand - obviously rETH demand is essential for growth of the protocol
Node Operator Supply / Efficiency - again this is essential for growth of the protocol, and with Lido CSM on the horizon, a side order of competition
Decentralisation - to ensure the protocol is open, permissionless, decentralised, and as trustless as possible
Protocol Safety - to ensure the security and smooth running of the protocol
Emerging Research - to facilitate innovation so that we can push the boundaries
As we deliver the Saturn RPIPs, it is likely that new prioritises emerge.
But to kick off the discussion here are some questions but please feel free to go in other direction:
- Are there themes missing?
- Is there a better way to organise it?
- Are there areas we should focus on in the future?
- Are there strength areas we can double down on?
- Are there weaknesses that we should strengthen?
- Are there threats that we should be prepared for?
8 Likes
I’m not sure if this is the right place to put this but its something I want to share with the community.
One of the key areas where I see a failing is being scammed when getting support. Even after a year of learning how to avoid a trap on Discord I still feel uneasy when asking for support. This is even more daunting for a new user and could quite easily put someone off using Rocketpool right from the start.
I ran my own healthcare software as a service company for 20 years so I know how important safe and knowledgeable support is to a businesses reputation.
My suggestion is to identify trusted support operatives, maybe vote them in and categorize them based on there knowledge and experience, similar to choosing a voting delegate. This way the support queries can be directed to the appropriate support operatives, say through a smart contract. The support questions could be generated from the operators node however it should still remain transparent like on discord for security reasons.
As the director of a software company employing technical developers, my battle was always trying to keep things simple for the end user. At the end of the day it is the non-technical end user that builds the business.
1 Like
As I understand RPIP-37, this roadmap is linked to the next year of funding for the core team, until October 2025.
During the last roadmap and prioritisation process in May 2023, two key priorities emerged:
- Minimizing trust in the pDAO guardian role
- Minimizing trust in the oDAO by reducing roles and responsibilities
The Houston upgrade takes a step toward reducing trust in the pDAO guardian role. Looking through the Q1, Q2 and Q3 development updates I couldn’t find anything on minimizing trust in the oDAO. Has the core team made any progress on the other key priority since May 2023? I’m also wondering how EIP 4788 (implemented with the Dencun upgrade) changes what’s possible in this area. Is oDAO role reduction still a key priority or is it pushed back in favor of tokenomics work? Is this something that can be worked on in parallel? What’s realistically achievable in this area by October 2025?
1 Like
We can only really deliver progress when we launch code and for most of that time we have been working on Houston. As you said, Houston included pDAO guardian trust minimisation features. From a research/design perspective, we have explored ways of minimising oDAO trust. There are small wins such as RPL price oracling but most require significant investment in design/development focus.
We have spent time on the Saturn design that will effectively remove the scrub check responsibility from the oDAO as we can use a withdrawal credential proof (utilising 4788) instead.
4788 makes a big difference to the design space. We are already making use of it to reduce oDAO responsiblity but we need to explore how it could be applied to each role to make them trustless (through state proof or optimistically).
It is still a key design priority for us as a team but ultimately our priorities are driven from the RPIPs that are ratified. So tokenomic work does come first. Obviously, your RPIPs go a long way in reducing the trust but not removing the responsibility.
Saturn potentially lays some extremely useful groundwork for oDAO responsibility reduction. Part of the infrastructure for Saturn (at this stage) is a generic 4788 state proof verifier - this will be used in many places for Saturn but may also be a perfect platform for making the oDAO responsibilities trustless. As part of UARS, it is likely we will have to review how treegen is constructed so this may also be a good opportunity to deliver the foundations for trustless treegen. Houston itself has also potentially delivered some groundwork - through the design and implementation of the optimistic fraud proving system.
Delivering Saturn and the RPIPs that are ratified will be our top priority but can work in partnership with the community to research the responsibilities and provide technical advice on how these infrastructure elements can be leveraged to remove oDAO responsibility. I believe you have already done some work in this area - so it would be good to continue that. With combined research and technical aspects covered we can draft future RPIPs for delivery.
4 Likes
This exists. Look for the Rocket Scientist and Club Awesome roles.
Also, please close your DMs. Nothing good ever comes of them. There’s a setting in Discord to allow friend requests only from “friends of friends”, not from everyone or people on the same server. Set that.
2 Likes
