- oDAO health transparency - as per RPIP-19 (https://rpips.rocketpool.net/RPIPs/RPIP-19).
- EL reward penalty system - roll out a penalty system for EL reward theft. Our currently planned system has some downsides and it could be improved.
- Wallet integrations - Exodus, Argent, Frame etc
- EIP4788 Beacon state root design - this could be delivered as early as Cancun. We need to be on the front foot on what it means for improving Rocket Pool
- oDAO duty reduction research/design - augment research from the community and start designing ways that we could reduce the role of the oDAO
- Zero knowledge technology - can we use ZK to reduce oDAO duties?
- Forced exits - 0x01 initiated exits are being defined by the EF, what changes do we want to make to Rocket Pool to leverage this new feature? Potentially improving security and efficiency.
- pDAO snapshot voting for treasury spends - remove the reliance and trust on the core team to initiate treasury spends from the pDAO.
- pDAO guardian review - multisig, timelocks?, setting changes/removal
- One minipool/node contract - can we move to a single node/minipool contract? Saving node operators a lot of gas and simplifying Rocket Pool
- Eigenlayer - what and how do we want to integrate with Eigenlayer? what are the stages of integration?
- Watchtower protocol specification - develop a written specification for the watchtower to make it part of the protocol and give the opportunity for multiple implementations.
- Deposit ETH on behalf of node - this is to support collaborative staking or SaaS providers.
- DVT - can we use DVT for collaborative staking? or for reducing the collateral requirement safety?
- Self-limiting - we are growing well, optimistically what do we do to self-limit?
- Rethink when deposit assignments are done - currently node operators pay for queue assignments when they distribute balance / close, this can be expensive. Plus the UX for rETH depositors is problematic because they can pay variable amounts of gas for transactions.
- Separate ETH and RPL withdrawal addresses - to support collaborative staking and SaaS providers.
- Passphrase support for node account generation - using BIP39 you can provide a passphrase to generate accounts based on the same seed. This means that a node operator can store their mnemonic more safety because you need both mnemonic and passphrase to access accounts.
- Ossification of Rocket Pool research/design - are there ways we can ossify Rocket Pool responsibly?
- RPL use cases / lending - can we build a protocol on top of Rocket Pool where people can lend their RPL for staking within the protocol?