'With great power comes great responsibility.'
Operating a Rocket Pool node ain't no joke. It's a serious undertaking that demands commitment and responsibility. But here's the exciting part – while you shoulder the weight of managing a node, you also open the doors to lucrative rewards.
So how can you get started? Today's guide will cover everything you need to deploy a Rocket Rool node on Linux.
What is a Rocket Pool Node?
A Rocket Pool node refers to a computer system with an Ethereum wallet registered with Rocket Pool's smart contracts. It creates and manages minipools to facilitate the staking process in Ethereum's Proof of Stake consensus.
Running a node makes one a node operator. A Rocket Pool node operator is in charge of setting up, configuring, and maintaining computer systems and creating and managing minipools to allow staking.
Node operators secure the system, ensure validators perform their duties, and earn staking rewards. They may also gain interest on staked RPL tokens and participate in Rocket Pool's DAO.
What is a Rocket Pool validator?
Participants in Ethereum's Proof of Stake consensus. Validators deposit 32 ETH on the Execution layer and validate new blocks on the Beacon Chain, ensuring network security and consistency. They receive rewards for participation and may face penalties for missed duties or violations.
Being a node operator within the Rocket Pool protocol not only grants you the power to contribute to a decentralized network but also offers an opportunity to earn substantial rewards in return for your efforts.
As a Rocket Pool node operator, you earn beacon chain rewards on your staked ETH, a commission on pool staked ETH, and RPL rewards for providing collateral.
Rocket Pool Node Requirements
- Minipool with 16 ETH upfront cost: 16 ETH (staked for the minipool) + 1.6 ETH worth of RPL tokens (as supplemental collateral).
- Minipool with 8 ETH upfront cost: 8 ETH (staked for the minipool) + 2.4 ETH worth of RPL tokens (as supplemental collateral).
- Operating System: Linux or macOS
- CPU: Quad-core (or dual-core hyperthreaded) with x64 and arm64 support
- RAM: 16 GB (preferably DDR4); 32 GB is preferable for some clients
- Disk Space: 2 TB of free SSD (750 GB for Prater testnet)
- Storage Type: Solid State Drive (SSD); spinning platter hard drives are not suitable
- Internet Bandwidth: At least 10 Mbps both up and down
- Internet Data Cap: No data cap imposed by your ISP
- Power: Stable electricity with a backup battery (UPS) for short blackouts
It is important to note that Rocket Pool nodes are required to run both an Execution (ETH1) Client and a Consensus (ETH2) Client along with the Rocket Pool stack after the Merge has occurred. Remote clients like Infura, Pocket, or Alchemy are no longer supported for validation duties after the Merge.
If you choose to run a local node, ensure you have reliable electricity, uncapped Internet access, and the ability to maintain the node and computer.
Get the latest updates on Rocket Pool node requirements here.
How to Deploy a Rocket Pool Node on Linux
Running a Rocket Pool local node on Linux will be the main focus of this guide, but it is important to mention that there is an alternative option available – running a Cloud-powered VPS. For more information on setting up a VPS on the Cloud, please consult the Rocket Pool documentation.
Step 1: Install the operation system
If you're starting fresh with a Linux installation, the distributions mentioned above provide comprehensive tutorials to guide you through the process.
Opting for Debian is ideal for node operation due to its emphasis on utmost stability and reliability, crucial qualities for machines that need to run continuously.
Get ready to install Debian on your node machine! This detailed guide comes complete with screenshots and easy-to-follow instructions to help you through every step of the process. We recommand that you navigate Rocket Pool Docs for additional tips to install Debian.
To install Rocket Pool's installer, make sure you have the
sudo program and all its dependencies. If you didn't set a password for the root user in the previous step, you should already have it. Otherwise, run the following commands:
apt install sudo
usermod -aG sudo $USER
Next, proceed to restart the machine. Once it's rebooted, you can execute commands using
sudo, such as
sudo apt update.
Once you've got the server up and running and are able to log in, the next step is to snag its IP address. Luckily, there's a handy little tool
ifconfig that comes bundled with the 'net-tools' package which makes this process a breeze.
sudo apt update
sudo apt install net-tools
You will come across various entries, but the one you should focus on finding will have a similar appearance to this:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.8 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::96f2:bf29:e269:1097 prefixlen 64 scopeid 0x20<link> ether <mac address> txqueuelen 1000 (Ethernet) ...
Make sure the flags are set to
UP,BROADCAST,RUNNING,MULTICAST – these will show if your connection is active and functional. Your machine's local IP address can be found under the
inet value (specifically
The next step is to install SSH:
sudo apt install openssh-server
If you selected the SSH server option during Debian's installation, you should already have this feature installed. Therefore, executing this command will not have any effect. After completing this step, you will be able to remotely access the machine's terminal from your laptop or desktop using
If you are not familiar with
ssh, refer to the Intro to Secure Shell guide.
It is strongly recommended that you configure your router to assign a static IP address to your node. By doing so, your node will have a consistent IP address, allowing you to always SSH into it using that specific IP address.
Failure to do so may result in the possibility of your node's IP changing, rendering the above SSH command ineffective. In such cases, you will need to access your router's configuration to determine the new IP address assigned to your node. Keep in mind that each router has its own unique process for assigning static IPs, therefore referring to your router's documentation is essential.
Step 2: Set up swap space
To ensure smooth operation of the Rocket Pool software, it is essential to allocate a specific amount of swap space. This space comes into play when your computer's RAM reaches its maximum capacity.
To set up swap space on your Linux computer, simply follow these instructions:
- Open a terminal window.
- Run the following command:
sudo dd if=/dev/zero of=/swapfile bs=1G count=16 status=progress
3. Run the following command grant access to the root user:
sudo chmod 600 /swapfile
4. Run the following command to enable the swap file:
sudo mkswap /swapfile
5. Run the following command to activate the swap file:
sudo swapon /swapfile
Step 3: Access your node machine using SSH (Secure Shell)
After successfully installing the operating system and configuring swap space, the next step is to establish access to your node machine. This can be achieved by remotely connecting to it via SSH.
If you are utilizing a local node, connect to it using your local IP address. Alternatively, if you are operating a VPS, connect using its public IP address. To initiate an SSH connection with your node, adhere to the following steps:
- Open your terminal on your device.
- Execute the following command, replacing 'username' with your node's username and 'node-ip-address' with its IP address:
For example, if your node's username is 'blockmeadow' and its IP address is '172.16.254.1,' the command would be:
When you first connect, a message will appear showing the public key used by your node. If you trust the node's IP address, confirm it by typing 'yes' when asked. This step only needs to be done once.
Enter your user password when prompted and you will be remotely logged into your node machine. To make things easier, create an alias on your client machine (laptop desktop) to shorten the SSH command. This example (which follows strictly Rocket Pool Docs) assumes you are using Linux OSX or Windows Subsystem for Linux (WSL):
echo "alias ethnode='ssh stake[email protected]'" >> ~/.bash_aliases source ~/.bash_aliases
You can easily connect to your node using the
What is Secure Shell?
Secure Shell (SSH) is a network protocol that allows you to securely access a remote computer. Rocket Pool uses it to allow you to connect to your node machine remotely and manage it.
Step 4: Install Rocket Pool Node
4.1 Set up the Execution and Consensus Clients
Native Mode effectively extends a standard solo-staking setup, and simply allows the Smartnode software to attach to the clients that it already runs (with a few small modifications).
To that end, we recommend you start by following some of the conventional solo staking guides provided by the community:
- Somer Esat's set of guides per-client: https://github.com/SomerEsat/ethereum-staking-guides
- CoinCashew guides: https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet
Note that you won't actually create a validator as defined in those guides - Rocket Pool will do that for you. You can ignore the portions involving the Staking Deposit CLI tool.
You simply need to follow the guides to the point where you have an Execution Client service, a Consensus Client / Beacon Node service, and a Validator Client service all installed and syncing the chain. Skip the steps that involve funding a validator and recording its mnemonic.
Also, there is a special case for the fee recipient - when you get to the portion of the guide where you specify the fee recipient in your Validator Client configuration, leave it blank for now. We will describe how to set it up for Rocket Pool validators below.
Once your clients are installed and you can see in their logs that they are syncing the chains properly, you can follow the next steps to set up the Rocket Pool Smartnode and connect it to your clients.
4.2. Install Rocket Pool
Creating the Service Account:
The first step is to create a new system account for the Rocket Pool services and disable login and shell access for it:
sudo useradd -r -s /sbin/nologin rp
Now, add yourself to the
rp group. You'll need to do this in order to use the Rocket Pool CLI, because it and the Rocket Pool daemon both need to access the Execution layer wallet file.
sudo usermod -aG rp $USER
Finally, add the user account for your Validator Client to the
rp group as well. The name of that user account depends on which guide you followed to set up your VC service.
For example, if your VC runs as user
lighthousevalidator, you would do the following:
sudo usermod -aG rp lighthousevalidator
After this, logout and back in for the changes to take effect.
Setting up the Binaries:
Start by making a folder for Rocket Pool and a data subfolder. You can put this wherever you want; for this guide, I'll put it into
sudo mkdir -p /srv/rocketpool sudo chown $USER:$USER /srv/rocketpool
Now, download the CLI and daemon binaries (or ignore this and build them from source if you prefer). Choose the platform that your system uses from the tabs below.
Linux x64Linux arm64macOS x64macOS arm64shell
sudo wget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-cli-linux-amd64 -O /usr/local/bin/rocketpool sudo wget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-daemon-linux-amd64 -O /usr/local/bin/rocketpoold sudo chmod +x /usr/local/bin/rocketpool
Now, set the owner and group of the daemon to
sudo chown rp:rp /usr/local/bin/rocketpoold
Finally, set the
suid bit and other permissions bits on the daemon binary:
sudo chmod u+sx,g+sx,o-rwx /usr/local/bin/rocketpoold
This will ensure that the daemon always runs as the
rp user, so it always has the proper permissions set.
Setting up the Installation Folder:
With the CLI and Daemon installed, you'll need to next set up the folder structure and accompanying files that the Smartnode expects to exist. Start by creating the following folders:
mkdir -p /srv/rocketpool/data/validators && sudo chmod 775 /srv/rocketpool/data/validators mkdir /srv/rocketpool/data/rewards-trees mkdir /srv/rocketpool/data/custom-keys sudo chown -R rp:rp /srv/rocketpool/data
Next, download the following scripts - Rocket Pool will use them when it needs to stop or restart your Validator Client to change its fee recipient (discussed later) or load new keys after you create a new minipool:
wget https://github.com/rocket-pool/smartnode-install/raw/release/install/scripts/restart-vc.sh -O /srv/rocketpool/restart-vc.sh wget https://github.com/rocket-pool/smartnode-install/raw/release/install/scripts/stop-validator.sh -O /srv/rocketpool/stop-validator.sh chmod +x /srv/rocketpool/restart-vc.sh chmod +x /srv/rocketpool/stop-validator.sh
~/.profile with your editor of choice and add this line to the end:
alias rp="rocketpool -d /usr/local/bin/rocketpoold -c /srv/rocketpool"
Save it, then reload your profile:
This will let you interact with Rocket Pool's CLI with the
rp command, which is a nice shortcut.
Creating the Services:
Next up, we'll create a
systemd service for the Rocket Pool node daemon. This is the service that will automatically check for and claim RPL rewards after each checkpoint, and stake minipools once you've created them via
We'll also create a
watchtower service as well. This will be used if you're an Oracle DAO member, or if you ever want to generate your own rewards interval trees (discussed in the Claiming Rewards section later on).
sudo nano /etc/systemd/system/rp-node.service
[Unit] Description=rp-node After=network.target [Service] Type=simple User=rp Restart=always RestartSec=5 ExecStart=/usr/local/bin/rocketpoold --settings /srv/rocketpool/user-settings.yml node [Install] WantedBy=multi-user.target
Create a log file for the service, so you can watch its output - this will replace the behavior of
rocketpool service logs node:
#!/bin/bash journalctl -u rp-node -b -f
Save it, then make it executable:
chmod +x /srv/rocketpool/node-log.sh
Now you can watch the node's logs by simply running:
The services are now installed.
Setting up Passwordless Script Access:
The next step is to give the
rp user the ability to restart the Validator Client when new validator keys are created, and stop the Validator Client if an emergency condition is detected.
Create a new
sudoers file using
sudo visudo -f /etc/sudoers.d/rocketpool
Add the following lines to it:
Cmnd_Alias RP_RESTART = /usr/bin/systemctl restart <validator service name> Cmnd_Alias RP_STOP = /usr/bin/systemctl stop <validator service name> rp ALL=(ALL) NOPASSWD: RP_RESTART, RP_STOP
<validator service name> is the name of your VC service (e.g.
- Uncomment the line at the end and change it to
sudo systemctl restart <validator service name>
- Uncomment the line at the end and change it to
sudo systemctl stop <validator service name>
All set! The
node process can now restart or stop your VC as required automatically.
4.3. Configure the Smartnode
Now that your services are all created, it's time to configure the Smartnode stack.
Please visit the Configuring the Smartnode Stack (Native Mode) guide, and return here when you are finished.
Enabling and Running the Services:
With all of the services installed, it's time to:
- Enable them so they'll automatically restart if they break, and automatically start on a reboot
- Start them all
sudo systemctl daemon-reload sudo systemctl enable rp-node rp-watchtower sudo systemctl start rp-node rp-watchtower
Setting Up a Wallet:
Next, create a new node wallet or recover an existing wallet. Please carefully follow the instructions in the Setting up a Wallet portion of the guide, then return here when you're done.
Once that's done, use the service log file scripts to verify that they successfully loaded your new wallet. You should also verify this using the following command:
rp wallet status
If working properly it should produce the following output:
Your Smartnode is currently using the Prater Test Network. The node wallet is initialized. Node account: <address>
4.4. Update the VC Service Definition
Unlike a solo staking setup, Rocket Pool generates and manages its validator keys automatically. There are a few adjustments you'll need to make to the VC service definition file you just created in order for it to work with Rocket Pool correctly, including:
- The Fee Recipient
- The VC's data or wallet directory
- The VC's keys and secrets directories
We'll cover these step-by-step for each client.
Setting Up the Fee Recipient File:
It is crucial that you follow these steps - failing to do so and using the wrong fee recipient will result in penalties being applied to your validators and deductions taken from your Beacon Chain balance!
The fee recipient is the argument you provide to your Validator Client that specifies the address on the Execution layer that you want your priority fees and MEV rewards to be sent to. Rocket Pool has two different addresses for the fee recipient:
- If you are opted into the Smoothing Pool, it must be the Smoothing Pool's address
- If you are opted out of the Smoothing Pool, it must be your node's Fee Distributor address
To learn more about the Smoothing Pool and your Fee Distributor, please see the Fee Distributors and the Smoothing Pool section of the guide.
node service will set this for you automatically by detecting which one it needs to be and setting it in a configuration file and restarting your Validator Client service to pick up the change. Your Validator Client service can use that configuration file automatically so you don't need to hard-code the fee recipient.
systemd service definition file that you just created for your Validator Client. Before the
ExecStart line, add this line:
Then modify your fee recipient argument as follows; select your client of choice from the tabs below:
--suggested-fee-recipient <address> to
If you start your Validator Client before Rocket Pool's services, it may error out because this file does not exist yet. Don't worry, this file will be created by Rocket Pool once you've initialized and started its services.
Setting the Data and Keys Directories:
Next, you must tell the VC where to store its data and load the validator keys that Rocket Pool generates. Click on the client you use in the tabs below:
Create the following directories and set their owner to
sudo mkdir -p /srv/rocketpool/data/validators/lighthouse/validators sudo mkdir -p /srv/rocketpool/data/validators/lighthouse/secrets sudo chown -R rp:rp /srv/rocketpool/data/validators/lighthouse sudo chmod -R 775 /srv/rocketpool/data/validators/lighthouse
Now, add or change the following parameters in the Lighthouse VC's service definition file to these new values:
By default, your system will typically come with a
umask configuration that will strip the
+w bit from the group permissions whenever the
node daemon creates a new folder. This is problematic for several consensus clients, because they will actually write things such as lock files or other metadata into the directories that the Smartnode creates when it generates new validator keys during a minipool deposit.
To combat this and ensure your VC works correctly, please relax your
umask settings. For example, instead of
0022, you should consider setting it to
0002 for the
Every system is different, so please consult a guide that covers your Operating System to learn how to do this.
Reloading the VC Service:
With these changes made, you can now reload and restart the VC service using the following:
sudo systemctl daemon-reload sudo systemctl restart <vc-service>
If not using Prysm, please watch the VC's logs carefully to ensure that it successfully started properly and the following are defined correctly:
- The fee recipient
- The data path
- The wallet / keys / secrets path
You can verify this with, for example,
ps aux | grep fee to filter the running processes to look at the fee recipient that your VC has used. It should be the same one defined in
If they are all using the correct values, then congratulations! You've successfully set up your Rocket Pool node and can follow the next sections of the guide to learn how to use it.
After successfully connecting to your node, you can move to the next step: secure your node.