Post Mortem - Rocket Split Grant

Grants / Bounties
1

1. Introduction

2. Objectives and Goals

  • Initial Objectives:
    • Launch a website (rocketsplit.xyz) where users can custom-configure and deploy a smart contract (a Rocket Split) that can become a Rocket Pool node’svalidator’s withdrawal address. A Rocket Split will share validator rewards as configured between a maximum of two parties (typically an ETH contributor and an RPL contributor).
  • Final Outcomes:
    • Rocket Split does not have an audit but remains available for use in production.
    • Rocket Pool has released the Houston upgrade in June 2024, enabling TWO potential withdrawal addresses, an ETH withdrawal address and an RPL withdrawal address. Rocket Split is designed to work with RPL withdrawal address NOT SET. Website will provide alerts if it recognizes the RPL address set.
    • Version 1 deployed December 2023 and a Rocket SplitRocketsplit was used in Main net Ethereum (now exited)
    • Version 2 is available for use. There are interested parties but no new Rocket Splits yet created.

3. Successes

  • Achievements:
    • Main net smart contract deployment March 2024
    • Initial Rocket Split launched March 2024. Validator exited June 2024.
    • Upgraded smart contract deployment July 2024
    • Wave 2 of production Rocket Splits, July 2024
  • Milestones Met:
    • Smart contract configuration website launch
    • Deployed Rocket Split smart contract factory
    • Rocket Split used in production to share rewards

4. Challenges and Issues

  • Major Challenges:
    • Funding:
      • Difficulty in estimating cost and value: Rocket Split has taken 100s of hours for development, testing, and governance management over the course of 15+ months. If grants are designed to cover a market value, the grant would have cost multiples higher. Contributions from the teams were more altruistic in nature.
      • Early-stage decentralized governance: This feature request Grant was denied 3 times. Two times on the initial submission and once for an audit. Full payment not yet received
    • Testing:
      • Challenging test environment. To test, users need to have an active validator on the Holesky testnet, registered with the Rocket Pool protocol. Users could then either act as both the ETH contributor & the RPL contributor, or find a partner tester.
    • Changing technical landscape
      • The Rocket Pool Houston upgrade introduced an additional withdrawal address, the RPL withdrawal address. This was a fundamental change to how Rocket Split was designed.

5. Lessons Learned

  • Technical Lessons:
    • Nick: From a front end perspective I think taking more time up front to identify all the user personas and respected workflows would have served us better. We originally tried to build the UI off an initial prototype that was pure HTML/JS. This became unwieldy as we were managing different user perspectives and respected workflows of which could be in different states at any given time. We switched gears to using React and the wagmi library. This allowed for improved isolation of concerns within the app. This also allowed for core functionality to work more reliably (ex. Basic wallet connections). During this process much of my time was spent developing hooks into Rocketpools core protocol smart contracts along with Rocket Split. As a result we did not spend as much time as we would have liked on core UX. The result is a working system but in my opinion one that can be greatly improved with improvements in design. Of course time and budget constraints play a role here. If this project does prove to be a valuable component in the RP toolset I would recommend we iterate on this a bit.
    • Ramana: The bug that meant exiting the first live validator was not a straightforward process could have been caught with more thorough testing of all pathways through Rocket Split. Our test suite did not have complete coverage of even all the typical uses of Rocket Split. I’m not sure if this is a lesson learned, though, since I know it is possible to miss issues without thorough testing: it’s more a question of us not having time/capacity/budget available for filling out the test suite (let alone an external audit). Perhaps there is a lesson to be gleaned here in what to prioritize under a very limited budget?
  • Decentralized Governance Community Roles:
    • A GMC Admin position was approved in 1H 2023 to be the primary liaison for active projects. If this role were approved prior to the Rocket Split grant approval, there could have been several pitfalls avoided.
      • Grant denial #1 (April 2023) was a result of needing to incorporate “Mentors requirements”. Those requirements however were not well understood or documented.
      • Grant denial #2 (July 2023) was a result of a misunderstanding from the GMC team of Rocket Split functionality. GMC team believed Rocket Split was redundant to the Rocket Pool protocol development already underway. It was appealed by Knoshua on the grounds that “the team is not working on things that would make Rocket Split obsolete. It is different than Nodeset”. The grant was approved after a unanimous (30-0) vote to appeal its rejection.
      • Grant denial #3 (January 2024) was a denial of the audit costs. The lesson learned here is that any project that acts as the withdrawal address of a Rocket Pool node, should be expected to have an audit. Clear expectations at the onset will have set the project for greater success.
  • Team Dynamics:
    • Conventional github development operations. Discussions of when to merge or critical needs took place in Discord channels.
    • Asynchronous coordination across multiple time zones. Nick’s late night development cycles flowed smoothly into updates for Ramana as he woke up the following day to continue iterating forward.
    • An additional front-end developer for future projects would be ideal. Nick and Ramana share similar skillsets. Ramana is brilliant at identifying custom paths to deliver intended functionality. Nick is fantastic at identifying the unique code and proposing structure and optimizations. Taking more time up front designing and prototyping front end workflows would have benefited the UX.

6. Conclusion

  • Summary of Findings:
    • Although not audited, there are production users clearly showing a demand for Splitter / “Marriage” functionality
    • Rocket Pool Houston upgrade added a new primitive with the RPL withdrawal address separate from the ETH withdrawal address. This does not have any configuration management for the “Marriage”. ETH will go to ETH withdrawal address, RPL will go to RPL withdrawal address. Rocket Split application is designed to operate with RPL withdrawal NOT SET.
    • Rocket Split is limited to only 2 partners in a contract. An improved version of Rocket Split that enabled multiple parties in an agreement, each with a custom configuration of rewards, may find better product market fit.
4 Likes