Some Thoughts about RPIP-13


After the Rocke Pool deposit pool limit was increased once, it is currently frequently at full capacity. In such instances, users are unable to mint rETH by staking ETH, they can only obtain ETH through swaps on a DEX. This has, to a certain extent, impacted the supply of rETH. If one desires to utilize the ETH in the deposit pool, one option is for users to perform unstake operations. However, this is undesirable as it not only fails to increase the rETH supply but also diminishes it. Another alternative is to boost the supply from node operators(NOs), which not only augments the rETH supply but also enhances ETH efficiency. RPIP-13 is precisely aimed at addressing how to increase the supply from node operators. Therefore, the ensuing discussion primarily focuses on strategies to amplify the supply from node operators and reduce the entry barrier for them.


Thoughts 1

Introducing a staking operator into the current NOs infrastructure, with the primary responsibility of providing 8ETH and RPL (2.4ETH). The staking operator has the flexibility to choose NOs to operate the validator. The fee for NOs is covered by the staking operator using RPL, and NOs can dynamically adjust its fee based on costs. The earnings for the validator continue to be distributed according to the existing model, involving the staking operator and staker, with NOs remaining uninvolved. Upon withdrawing earnings, the staking operator is required to utilize RPL to pay the fee to NOs.

In order to better assist staking operators in selecting suitable NOs, it is necessary to list the performance and fees of NOs. This way, staking operators can make more informed decisions by balancing performance and costs when choosing an operator.

Ideally, staking operators should be able to dynamically switch operators to ensure optimal prices and performance. However, due to issues with the validator key, this may not be achievable in the current context. If we aim to address the problem of NOs holding validator keys, it might be necessary to introduce a solution similar to DVT.

deposit pool (24ETH)                  |
--------------------------------------   ------>  Deposit Contract
staking operator (8ETH + RPL)         |
        ^       |
        |       | select node operator
rewards |       |
        |       | pay fee (RPL)
        |       v
node operator1 | node operator2 | ...  | ------->  Validator

Thoughts 2

To operate as a node operator, one needs to stake a certain amount of RPL. When a node operator is not selected as a validator, running a node allows participation in RPL staking to earn rewards. Additionally, RPL holders can delegate their RPL to a node operator to earn staking rewards.

Staking operators only need 8 ETH without the need for additional RPL to choose a node operator for operation. Staking operators still need to provide RPL to the node operator to pay fees. The choice of operator is based on the fee and performance of the node operator. Validator earnings are distributed between the staking operator and the staker.

Due to the RPL staking by the node operator, which serves as a constraint for slashing and ensures the proper operation of the node, there is less need for staking operators to switch frequently.

deposit pool (24ETH)                             |
------------------------------------------------   ------>  Deposit Contract
staking operator (8ETH)                          |
        ^       |
        |       | select node operator
rewards |       |
        |       | pay fee (RPL)
        |       v
node operator1 (RPL) | node operator2 (RPL) | ... | ------->  Validator
                | delegate
RPL holder                                        |


The aforementioned thoughts consider separating the roles of the node operator and capital provider, introducing the role of a staking operator to operate and manage minipools. The primary aim is to enhance the supply from node operators, thereby increasing the overall supply of rETH.

Additionally, the evaluation of the performance of node operators mentioned in the thoughts can be integrated with existing discussions. This can be achieved through market and economic mechanisms to improve the overall node performance.

Finally, your feedback is welcome. If there are feasible suggestions, I will continue to refine and submit a pull request on GitHub.

1 Like

This is how stakewise works, essentially. I think what you’ll end up seeing is that the entities that can get delegates are essentially professional Node Operators rather than looking more like small Solo operators. Are you familiar with Nodeset? They are building something like this on top of RP, with a permissioned set of smaller NOs under the hood.


Hey, @Valdorff based on your feedback, I have supplemented some additional information. By the way, if I plan to continue my research on this topic and propose viable solutions, could I inquire about the possibility of applying for a research grant and the application process? Currently, I operate a minipool, possess an in-depth understanding of LST, and engage in LST-related work. Whether it’s technical implementation or research, I have a strong interest in Rocket Pool and would like to contribute to the growth of the entire protocol.

Prior Art


Stakewise offers Vault functionality to assist solo validators. The Vault is primarily managed by the node operator, and users can stake ETH in the vault. The node operator can utilize the ETH staked by users in the vault to run the validator. The vault will have a rating, which will affect the user’s LST minting ratio.

Node operators do not require additional bonding and staking. However, each vault and the official staking pool of Stakewise are isolated, meaning nodes cannot obtain ETH from Stakewise’s official staking pool to run validators.


Puffer introduces the concept of validator tickets. To run a validator with 32 ETH from the pool, a node operator needs to purchase a ticket. Each ticket grants one day of permission to operate a validator, with an initial threshold set at 28 tickets. Additionally, validators require a staking of 1-2 ETH.

Validator tickets essentially pre-advance the earnings for node operators running validators, which may disadvantage solo node operators and favor professional entities.

Validator tickets support secondary trading, potentially creating arbitrage opportunities. The pricing of tickets is determined based on the historical earnings of the market over a specific period, leading to potential price differentials.

The introduction of validator tickets has the benefit of enhancing the liquidity of ETH. For instance, while RocketPool currently requires a staking of 8 ETH, which doesn’t convert to LST, using validator tickets pre-advances the staking, reducing bonding and increasing liquidity.


Built on top of Rocket Pool is a matching pool that can match RPL, ETH, and node operators. However, it currently relies mainly on admin for reviewing and managing node operators.

Building something similar would require a contract audit and users trusting it. Also, users don’t receive rETH directly and need to establish liquidity on a DEX, introducing significant uncertainty. Can Rocket Pool create a more native model directly?

Related Technology


Currently, triggering the withdrawal of a validator poses several challenges. Firstly, one needs the validator key, and secondly, it cannot be directly triggered from the execution layer contract. It requires an off-chain service to monitor execution layer logs and then trigger the validator’s withdrawal off-chain. EIP-7002, on the other hand, allows the direct triggering of validator withdrawal from the execution layer. This way, when oDAO indexes the validator’s balance, it can simultaneously index the validator’s operational status. If the validator remains offline for an extended period, it can be reported to the execution layer, triggering the validator’s withdrawal and thereby safeguarding assets.

Secure-Signer TEE

Secure-Signer is a remote-signing tool that manages validator keys on behalf of the consensus client. It can run locally with the consensus client or on a remote server. From the point of view of a node operator, there is little difference in setting up their validator. If they have SGX-enabled hardware, they can install and run Secure-Signer and instruct their consensus client of choice to use Secure-Signer as the remote-signer.


A standard format for transferring a key’s signing history allows validators to easily switch between clients without the risk of signing conflicting messages. While a common keystore format provides part of the solution, it does not contain any information about a key’s signing history. For a validator moving their keys from client A to client B, this could lead to scenarios in which client B inadvertently signs a message that conflicts with an earlier message signed with client A. The interchange format described here provides a solution to this problem.

I will further refine the proposal based on these inputs.

github backup:research/rocketpool/ at main · signalxu/research · GitHub