Protocol Development - Roadmap Update (November, December, January)

Hey everyone!

Here is a quarterly roadmap update for November, December, January.

Tokenomics Prelude (Saturn 0 / RPIP-62)

The team applied the parameter changes necessary for Saturn 0 with the release of the Houston Hotfix (RPIP-62).

The team worked with @patches to develop the v10 reward tree implementation that included the dynamic commission components of the Saturn 0 specification. The v10 reward tree implementation was challenging but @patches did an amazing job, culminating in its release for interval 30 (2024-12-19).

Saturn 0 has now been completely delivered.

Saturn 1

The team have made good progress on the devnet-1 deliverables as outlined in the timeline post.

Devnet-1 focuses on the deposit process:

  • Megapool delegate
  • Megapool upgrade process
  • Deploying a megapool
  • Depositing a validator
  • Assigning ETH from the deposit pool
  • Staking a validator
  • Standard and Express queues
  • Express queue ticket allocation

A devnet contract deployment and development smart node build is targeted for end of this month (January 2025). The code will still be very much in-development but we invite active participation from testing enthusiasts to test the new features.

Much of the remaining devnet-1 work is smart node based with some contract fixes/refinement. The team have now started working on the contract components for devnet-2; focusing on ETH reward distribution & penalties.

Smart Node v2

The v2 smart node release is a substantial ground up rewrite of the smart node. It applies lessons learnt from developing v1 to improve overall performance, developer experience, and integration opportunities.

As we have developed v1 we have tried to keep v2 inline with the changes. The v10 reward tree implementation needs to be merged into v2 and then we can deploy it to Holesky for final testing. In the last report period, we performed substantial functional testing so we have a high degree of confidence. Once Holesky testing is complete, the team will deploy v2 onto, at least, one of our odao nodes for mainnet testing. If that is successful, we will make the jump to v2.

We are very keen to migrate to v2 as soon as possible because it takes capacity to maintain both branches. We are prioritising devnet-1 at this stage but we will have to bite the bullet and migrate v2 after this launch.

Websites & APIs

The team have worked on a long list of additions and performance improvements for the main Rocket Pool website. We have added new API endpoints and improved performance.

The team have prototyped a Cow Swap integration on the liquid staking website. The aim is to leverage their routing and MEV protection to get the best deal for liquid staking users. We are currently evaluating the integration and assessing the pros/cons.

The team have worked on a dedicated Node Management website to separate out node functions from the liquid staking website.

The team have worked on delegate onchain voting support so that delegates that do not operate a node or do not want to expose their node, can vote using the website. We have also hardened security of the delegates’ website.

The team have delivered a number of documentation display and content improvements.

In addition, the team have a fair amount of devops work maintaining, monitoring and upgrading servers.


Please let me know if you have any questions or concerns.

14 Likes

Thanks for the detailed report! It looks like everything is going as planned. Do you think the original roadmap timeline is still accurate?

Thanks for an update.

Is the smart contract code for devnet-1 available yet?

This sounds like a position for hiring and which won’t draw too much capacity from the team.

Will RP v2 include the possibility to set parameters for unique Test Networks?

Yes! Things are progressing to plan and the timeline is looking good.

1 Like

This is our current working branch:

Please bear in mind the code is in a great deal of flux and so is not audit / review ready and it certainly is not covered under the bug bounty, as yet.

Additionally we will verify the contract code when we deploy the changes to the devnet for convenience.

2 Likes

We will certainly consider a hire in that space if needed. To be honest, we have optimised efficiency in that space so general maintenance is nowhere near as burdensome. In that period, we just decided to upgrade a bunch of our testing infra, which took come capacity.

Most of the devops work is a background hum rather than being enough for a dedicated resource. I am mindful of it becoming more though.

2 Likes

I don’t think that is something that has been raised before - or at least I haven’t seen it.
Would this be for development networks? Or a specific testnet?

1 Like

As a learning project, I have been working on deploying Rocket Pool Protocol to the Ephemery test network. Publishing the contracts to Ephemery was relatively simple work, however, the Rocket Pool Wizard tool only has hard-coded options for Mainnet and Holesky. I think it would be in the interest of Rocket Pool to consider developing a more flexible design by incorporating Execution RPC and Network_ID options into the Wizard along side the current Mainnet/Holesky options.

To keep things simple the network selection in the smart node cli is actually a combination of an Ethereum network and a deployed Rocket Pool instance (storage contract address). So we would have to separate those to allow custom networks/deployments.

I see it potentially not being trivial from a TUI perspective but I will check with the team. If it is trivial then I will try to get it into v2. If it is difficult then it may have to wait until we have more capacity, unless someone wants to raise a PR.

1 Like