Migrating Manually

If for any reason you cannot leverage the Smartnode's automatic migration process, you can do it manually in a few simple steps:
Docker ModeNative ModeWhile you still have the testnet configured, exit your validators on Prater:rocketpool minipool exitSelect 1: All available minipools from the list of choices and wait for it to complete. This will help clean up the network by removing your validators instead of leaving them to constantly fail attestations and weaken Prater's health (since they're no longer online).Shut down the testnet:rocketpool service stopDelete your testnet chain data and Docker containers:rocketpool service terminateDelete your Rocket Pool configuration folder:sudo rm -rf ~/.rocketpool(Optional) Delete your Rocket Pool CLI:rm ~/bin/rocketpoolYou will overwrite this with the latest version of the CLI anyway, but if you want to be thorough, you can remove the old one first.At this point your testnet installation has been purged, and you can safely migrate to a new mainnet installation. Follow the Creating Node with Docker guide carefully to set it up.


The Rocket Pool Oracle DAO

NOTEThis documentation only applies to members of Rocket Pool's Oracle DAO. If you have not been explicitly invited to the Oracle DAO and just intend to run a regular Rocket Pool node, this section of the guide does not apply to you. You can safely ignore it, but are welcome to read it if you are interested.
The Oracle DAO is the group of special Rocket Pool nodes that are responsible for the administrative duties required by the protocol that cannot be achieved by Smart Contracts due to technical limitations. They are essentially the same as normal Rocket Pool nodes; they use the same tools, can be configured with the same methods, and can even run regular minipools, but they come with supplemental tasks that they perform. This includes things such as:
Shuttling information from the Beacon Chain to the Execution Layer, including validator status and balancesEnsuring minipools are creating using validator public keys that aren't already in use, and have the proper withdrawal credentials so the protocol can safely fund themConstructing the rewards Merkle tree at the end of each rewards period and uploading it to IPFS for other node operators to accessMonitoring proposals for compliance with Rocket Pool's fee recipient requirementsProposing and voting on modifications to the core protocol, including changing parameters and approving contract upgradesProposing and voting on the Oracle DAO roster, including inviting and removing other Oracle DAO members
As a reward for fulfilling these duties, the Oracle DAO is collectively given 15% of the total RPL inflation produced at each rewards period, divided evenly among its members.
Unlike normal Rocket Pool nodes, which can be created and run permissionlessly by anyone, membership in the Oracle DAO is invite only by existing members. If you have recently been invited to join the Oracle DAO, this section of the guide will help you understand your role, get your node set up, and ensure that it stays healthy.


Requirements

To run an Oracle DAO node, you will require the following:
Access to an Execution Client's RPC endpoint. This can be a locally-run client, as is the case with most Rocket Pool nodes, or it can link to external clients that you or your organization maintain independently.Access to an Archive-Mode Execution Client, which can either act as your primary client or a supplementary (fallback) client. It will only be used in rare circumstances where duties require your node to recall an Execution Layer state that has been pruned from your Execution Client. Nevertheless, it is critical that you have access to an Archive Node during these periods to ensure your duties are able to be fulfilled successfully. We strongly recommend you use an on-premises archive node for this, as services such as Infura or Alchemy have shown some difficulty in keeping up with demand during critical periods such as constructing the rewards tree.Access to an Archive-Mode Beacon Node's REST API endpoint (via HTTP). This can be a locally-run client, as is the case with most Rocket Pool nodes, or it can link to external clients that you or your organization maintain independently.The standard Smartnode CLI.The Smartnode daemon configured and running in watchtower mode (this is included with the standard Smartnode bundle for all users, but only actively performs duties for Oracle DAO nodes). This can be run in a Docker container (standard setup) or as a simple systemd service ("Native" mode).Enough ETH to pay for the gas costs of your duties (discussed later).A web3.storage account, used for submitting the generated rewards tree artifacts to their IPFS pinning service.
NOTEIf you simply cannot run an on-premises archive node and must rely on a third-party service, consider the following:If you plan to use Infura for your Archive Mode fallback, you must have at least the Team plan. The free tier and the Developer tier are not sufficient.If you plan to use Alchemy, you must have at least the Growth plan. The free tier is not sufficient.


Activities

Oracle DAO duties are split into two parts.
Read the next section to learn how to set up your Oracle DAO node.


Setting up an Oracle DAO Node

At a bare minimum, a standard Rocket Pool node runs the following:
The Smartnode CLIThe Smartnode API daemonThe Smartnode node daemonThe Smartnode watchtower daemon
Optionally, the node can also run the following components:
An Execution ClientA Beacon NodeA Validator ClientMEV-BoostPrometheusThe Prometheus Node ExporterGrafana
Each of these components can be run as Docker containers in the standard setup, as systemd services in the "Native Mode" setup, or run as externally-managed entities that the Smartnode can connect to via their respective API routes.
Conveniently, Oracle DAO nodes are the same as normal Rocket Pool nodes, but the watchtower daemon performs the supplemental Oracle DAO duties and there are more Prometheus metrics collected for performance monitoring purposes.


Initial Node Setup

The best way to start is by following the standard setup instructions for a normal Rocket Pool node. That process will help you determine how you'd like to configure and run your node.
If you would like to run minipools (validators) on your node, please follow the normal node documentation from start to finish and return here when you're done.
If you do not intend to run minipools and instead will use it purely for Oracle DAO duties, you can skip all of the steps relating to staking RPL and minipool creation. The other steps such as node registration, establishing a good security posture, monitoring the node's health and performance, and updating the Smartnode after an update all still apply to you and you should review them carefully before proceeding. Return here when you've finished.


Additional Oracle DAO Configuration

There are two additional settings you need to provision in order to satisfy your Oracle DAO responsibilities. Please select the mode you use to configure your node below from the tabs below.
[service config] Interactive UI[service config] HeadlesslyDirect Config File


Oracle DAO Smartnode Commands

The Smartnode CLI's odao command group is used to interact with the Oracle DAO contracts and duties on-chain:
NAME:
   rocketpool odao - Manage the Rocket Pool oracle DAO

USAGE:
   rocketpool odao command [command options] [arguments...]

COMMANDS:
   status, s             Get oracle DAO status
   members, m            Get the oracle DAO members
   member-settings, b    Get the oracle DAO settings related to oracle DAO members
   proposal-settings, a  Get the oracle DAO settings related to oracle DAO proposals
   minipool-settings, i  Get the oracle DAO settings related to minipools
   propose, p            Make an oracle DAO proposal
   proposals, o          Manage oracle DAO proposals
   join, j               Join the oracle DAO (requires an executed invite proposal)
   leave, l              Leave the oracle DAO (requires an executed leave proposal)

OPTIONS:
   --help, -h  show help


status

The status command simply summarizes a few details about the Oracle DAO such as member count and proposal count:
The node is a member of the oracle DAO - it can create unbonded minipools, vote on DAO proposals and perform watchtower duties.

There are currently 8 member(s) in the oracle DAO.

There are 29 oracle DAO proposal(s) in total:
- 22 proposal(s) have passed and been executed
- 7 proposal(s) were cancelled, defeated, or have expired


members

The members command prints detailed information about each member of the Oracle DAO, including their handle, their contact information, their node address, their RPL bond, and the last time they submitted a proposal for voting:
The oracle DAO has 8 members:

--------------------

Member ID:            kermit-2
URL:                  https://www.rocketpool.net
Node address:         0x04ddB06D1429578691F630B67A53916445DA38bE
Joined at:            31 Jul 21 23:32 EDT
Last proposal:        27 Sep 22 21:18 EDT
RPL bond amount:      5000.000000
Unbonded minipools:   0
...


member-settings

member-settings shows the current values for each of the configurable parameters related to Oracle DAO membership:
ODAO Voting Quorum Threshold: 51.000000%
Required Member RPL Bond: 1750.000000 RPL
Max Number of Unbonded Minipools: 250
Consecutive Challenge Cooldown: 300 Blocks
Challenge Meeting Window: 900 Blocks
Cost for Non-members to Challenge Members: 1.000000 ETH
This command is described in more detail in the Oracle DAO Proposals section.


proposal-settings

proposal-settings shows the current values for each of the configurable parameters related to proposals that the Oracle DAO can vote on:
Cooldown Between Proposals: 1h0m0s
Proposal Voting Window: 168h0m0s
Delay Before Voting on a Proposal is Allowed: 15m0s
Window to Execute an Accepted Proposal: 168h0m0s
Window to Act on an Executed Proposal: 168h0m0s
This command is described in more detail in the Oracle DAO Proposals section.


minipool-settings

minipool-settings shows the current values for each of the configurable parameters related to minipools on the Rocket Pool network:
Scrub Period: 1h0m0s


propose

The propose command is used to submit governance proposals that the rest of the Oracle DAO can vote on. These can involve changing a setting or modifying the Oracle DAO members (i.e., inviting or kicking other members).
This command is described in more detail in the Oracle DAO Proposals section.


proposals

The proposals command is used to interact with existing Oracle DAO governance proposals. It can view them, rescind proposals that you made, vote on them, and execute them (if applicable) causing them to take effect after they have been approved by the other members:
NAME:
   rocketpool odao proposals - Manage oracle DAO proposals

USAGE:
   rocketpool odao proposals command [command options] [arguments...]

COMMANDS:
   list, l     List the oracle DAO proposals
   details, d  View proposal details
   cancel, c   Cancel a proposal made by the node
   vote, v     Vote on a proposal
   execute, x  Execute a proposal

OPTIONS:
   --help, -h  show help
This command is described in more detail in the Oracle DAO Proposals section.


join / leave

The join and leave commands are used to join the Oracle DAO once you've been invited, or leave the Oracle DAO once the other members have approved your resignation request.


Joining the Oracle DAO


The RPL Bond

In order to join the Oracle DAO, your node wallet will need enough RPL in it to cover the required membership bond. This will be locked in Rocket Pool's vault as part of the joining process. The exact amount of RPL required for the bond will be determined at the time of your invitation, and will be communicated to you by the other Oracle DAO members prior to onboarding you.
NOTEUnlike all other ETH and RPL rewards, the RPL bond is not sent to your node's withdrawal address upon exiting the Oracle DAO. It is sent back to your node wallet itself. Consider this as extra incentive to protect your node wallet from compromise.


Accepting an Invitation

Once your node is set up and you have been invited to join the Oracle DAO by the existing members, you can use the rocketpool odao join command to accept the invitation. This will involve two transactions:
One to lock the RPL required for your bondOne to join the Oracle DAO when the bond has been received
Once you've joined, your watchtower daemon will automatically begin performing its required duties. You can verify this by looking at its logs (e.g. rocketpool service logs watchtower for standard Docker-based installations); the watchtower performs its loop of duties every 4 to 6 minutes, and you will notice a distinct change in its output once you've joined the Oracle DAO.


Next Steps

Now that you've joined the Oracle DAO, take a look at the next section to learn how to test your node in this role.


Testing your Oracle DAO Node

Once your node is set up and you've joined the Oracle DAO, you should test it to ensure it's able to perform its duties properly. The best way to do this is to have it build the Redstone rewards Merkle tree using Rocket Pool's treegen utility.


treegen

treegen is a tool that can reproduce the entire rewards Merkle tree and accompanying artifacts for a previous rewards interval via your archive Execution and Consensus clients. It can also "dry run" the current interval by pretending that it ended at the latest finalized epoch (at the time of running it) and producing a partial tree from the start of the interval up to that point.
TIPFor more information on the rewards tree itself and accompanying files, please visit the formal specification.
treegen can be used as a standalone binary (currently only built for Linux systems, x64 and arm64) or as a Docker container.
If you would like to download the standalone binary, you can find it in the releases here: https://github.com/rocket-pool/treegen. Usage instructions are included in the README there, but we'll cover some examples below as well.
The Docker container tag for it is rocketpool/treegen:latest.


Building a Dry-Run Tree

For a first test, run treegen to generate a dry-run tree that calculates the tree from the start of the rewards interval to the latest (finalized) slot. We'll use the script included in the repository that leverages the Docker container to run it on the node machine itself for simplicity:
./treegen.sh -e http://localhost:8545 -b http://localhost:5052
NOTENote that this particular configuration requires you to expose the Execution Client and Beacon Node APIs through the Docker configuration - ensure you have both options enabled in the rocketpool service config TUI.
This will test your clients' abilities to respond to queries in a timely fashion (e.g., if you are using a third-party service, this will be helpful to assess whether or not its query rate-limit is insufficient), but will not test their Archive Mode capabilities. It will produce output like the following:
2022/11/06 12:11:37 Beacon node is configured for Mainnet.
2022/11/06 12:11:37 Generating a dry-run tree for the current interval (3)
2022/11/06 12:11:37 Snapshot Beacon block = 5077503, EL block = 15912334, running from 2022-10-27 01:35:39 -0400 EDT to 2022-11-06 12:11:37.672755513 -0500 EST m=+0.049901525

2022/11/06 12:11:38  Creating tree for 1684 nodes
2022/11/06 12:11:38  Pending RPL rewards: 27807066876373932561121 (27807.067)
2022/11/06 12:11:38  Total collateral RPL rewards: 19464946813461752792784 (19464.947)
2022/11/06 12:11:47  Calculated rewards:           19464946813461752792026 (error = 758 wei)
2022/11/06 12:11:47  Total Oracle DAO RPL rewards: 4171060031456089884168 (4171.060)
2022/11/06 12:11:47  Calculated rewards:           4171060031456089884168 (error = 0 wei)
2022/11/06 12:11:47  Expected Protocol DAO rewards: 4171060031456089884168 (4171.060)
2022/11/06 12:11:47  Actual Protocol DAO rewards:   4171060031456089884927 to account for truncation
2022/11/06 12:11:47  Smoothing Pool Balance: 62781809204406327225 (62.782)
2022/11/06 12:11:55  1229 / 1684 nodes were eligible for Smoothing Pool rewards
2022/11/06 12:12:03  Checking participation of 4364 minipools for epochs 156315 to 158671
2022/11/06 12:12:03  NOTE: this will take a long time, progress is reported every 100 epochs
2022/11/06 12:13:48  On Epoch 156415 of 158671 (4.24%)... (1m44.577189073s so far)

...

2022/11/06 12:49:55  On Epoch 158615 of 158671 (97.62%)... (37m51.785456663s so far)
2022/11/06 12:50:51  Finished participation check (total time = 38m47.979633935s)
2022/11/06 12:50:51  Pool staker ETH:    26638263090669169632 (26.638)
2022/11/06 12:50:51  Node Op ETH:        36143546113737157593 (36.144)
2022/11/06 12:50:51  Calculated NO ETH:  36143546113737155125 (error = 2468 wei)
2022/11/06 12:50:51  Adjusting pool staker ETH to 26638263090669172100 to account for truncation
2022/11/06 12:50:52 Saved minipool performance file to rp-minipool-performance-mainnet-3.json
2022/11/06 12:50:52 Generation complete! Saving tree...
2022/11/06 12:50:52 Saved rewards snapshot file to rp-rewards-mainnet-3.json
2022/11/06 12:50:52 Successfully generated rewards snapshot for interval 3.
If this runs without error, it will generate the rewards tree artifacts and save them as JSON files in your working directory. You are free to explore them and ensure their contents are sane, but as they are dry-run files, they aren't canonically stored anywhere for comparison.


Building a Canonical Tree from a Past Interval

This next test is to replicate one of the complete trees from a past interval. This will require archival access on both the Execution Layer and the Consensus Layer, so it will serve as a good test of both capabilities.
As of this writing, Interval 2 is an ideal choice as it is far in the past () and involved the Smoothing Pool (which accounts for the largest computational load when calculating the rewards for the period).
Run treegen using the following command:
./treegen.sh -e http://<your archive EC url> -b http://localhost:5052 -i 2
Note that the Execution Client URL is different here: it must be an Archive EC as the snapshot block for Interval 2 was far in the past.
NOTEDepending on your client configuration, building this tree can take hours. The Smartnode will give you status indicators about its progress along the way, as you can see in the example below.
The output will look like this (truncated for previty):
2022/11/07 23:44:34 Beacon node is configured for Mainnet.
2022/11/07 23:44:36 Found rewards submission event: Beacon block 5002079, execution block 15837359
2022/11/07 23:46:25  Creating tree for 1659 nodes
2022/11/07 23:46:26  Pending RPL rewards: 70597400644162994104151 (70597.401)
2022/11/07 23:46:26  Approx. total collateral RPL rewards: 49418180450914095872905 (49418.180)
2022/11/07 23:46:26  Calculating true total collateral rewards (progress is reported every 100 nodes)
2022/11/07 23:47:06  On Node 100 of 1659 (6.03%)... (40.134456319s so far)
...
2022/11/07 23:57:41  On Node 1600 of 1659 (96.44%)... (11m14.880994468s so far)
2022/11/07 23:58:03  Calculating individual collateral rewards (progress is reported every 100 nodes)
2022/11/07 23:58:14  On Node 100 of 1659 (6.03%)... (11.421791885s so far)
...
2022/11/08 00:01:20  On Node 1600 of 1659 (96.44%)... (3m16.598462676s so far)
2022/11/08 00:01:26  Calculated rewards:           49418180450914095872087 (error = 818 wei)
2022/11/08 00:01:26  Total Oracle DAO RPL rewards: 10589610096624449115622 (10589.610)
2022/11/08 00:01:30  Calculated rewards:           10589610096624449115610 (error = 12 wei)
2022/11/08 00:01:30  Expected Protocol DAO rewards: 10589610096624449115622 (10589.610)
2022/11/08 00:01:30  Actual Protocol DAO rewards:   10589610096624449116454 to account for truncation
2022/11/08 00:01:30  Smoothing Pool Balance: 209598268075128756591 (209.598)
2022/11/08 00:04:20  On Node 104 of 1659 (6.27%)... (2m49.443336528s so far)
...
2022/11/08 00:27:33  On Node 1664 of 1659 (99.70%)... (27m28.373343345s so far)
2022/11/07 16:40:36  1197 / 1659 nodes were eligible for Smoothing Pool rewards
2022/11/07 16:45:45  Checking participation of 4308 minipools for epochs 150015 to 156314
2022/11/07 16:45:45  NOTE: this will take a long time, progress is reported every 100 epochs
2022/11/07 16:47:24  On Epoch 150115 of 156314 (1.59%)... (1m38.552513232s so far)
...
2022/11/07 18:24:31  On Epoch 156215 of 156314 (98.43%)... (1h38m46.325518238s so far)
2022/11/07 18:26:10  Finished participation check (total time = 1h40m24.47206731s)
2022/11/07 18:26:10  Pool staker ETH:    88931841842952006598 (88.932)
2022/11/07 18:26:10  Node Op ETH:        120666426232176749993 (120.666)
2022/11/07 18:26:10  Calculated NO ETH:  120666426232176747457 (error = 2536 wei)
2022/11/07 18:26:10  Adjusting pool staker ETH to 88931841842952009134 to account for truncation
2022/11/07 18:26:10 Finished in 2h36m3.709234237s
2022/11/07 18:26:10 Your Merkle tree's root of 0x278fd75797e2a9eddc128c0199b448877e30d1196c12306bdc95fb731647c18f matches the canonical root! You will be able to use this file for claiming rewards.
2022/11/07 18:26:10 Saving JSON files...
2022/11/07 18:26:10 Saved minipool performance file to rp-minipool-performance-mainnet-2.json
2022/11/07 18:26:10 Saved rewards snapshot file to rp-rewards-mainnet-2.json
2022/11/07 18:26:10 Successfully generated rewards snapshot for interval 2.
The key thing to look for here is this message at the end:
Your Merkle tree's root of 0x278fd75797e2a9eddc128c0199b448877e30d1196c12306bdc95fb731647c18f matches the canonical root! You will be able to use this file for claiming rewards.
If you receive this, then your watchtower can build the tree correctly.
NOTEWhile this proves you can build the tree, you must ensure your Web3.Storage API token has been entered into the Smartnode's configuration so it can upload the resulting tree to IPFS.


Next Steps

Next up, we'll cover how to monitor your node's performance.


Monitoring your Oracle DAO Node

Once your node is up and running, it's important that you regularly monitor its health to ensure that it's correctly performing its automated duties. Doing so involves the following:
Monitoring the health of your physical (or virtual) system at the OS levelMonitoring the health of your Execution and/or Consensus clients (if you run local clients)Ensuring your node is regularly submitting the required transactions to the chain for status updatesEnsuring you have a sufficient ETH balance in your node wallet to execute those transactionsRoutinely applying updates to the Smartnode, your clients (if applicable), and your Operating SystemMonitoring the health of the other Oracle DAO members, and communicating with them if you believe their node(s) are not functioning properlyS
In this section, we'll describe a few examples of how to do these via the Smartnode's built-in Grafana support.


The Standard Rocket Pool Dashboard

The Smartnode provides a convenient dashboard that allows you to monitor many of the metrics listed above. There is one dashboard for each Consensus Client. Below is an example of the dashboard for Nimbus:

Your machine's hardware health is captured in the upper-left quadrant.Your Execution client is functioning properly if the Network Stats in the lower-left quadrant are being populated.Your Consensus client is functioning properly if the peer count in the upper-right quadrant is updating with a non-zero number; the exact number depends on your choice of client and your network configuration.Your node's ETH balance is displayed in the table at the bottom right.Any Operating System updates or Smartnode updates are presented in the Available Updates box in the top-middle panel.
NOTEOperating System and Smartnode updates require the update tracker, which you can install via rocketpool service install-update-tracker.
For information on how to prepare the metrics system and the Smartnode dashboard, please visit the Monitoring your Node's Performance and the Setting up the Grafana Dashboard pages of the Smartnode documentation.


The Oracle DAO Dashboard

We have also constructed a simple dashboard specifically tailored towards Oracle DAO members:

This dashboard that tracks the following:
The status of the Oracle DAO proposals that need to be voted on or executed (more details on these in the next section)The history of submissions for price and balance updates*The ETH balances of each Oracle DAO node
*Note that price and balance submission currently requires a quorum of 51% of nodes to agree on each one, at which point the submission is canonized. Submissions from other members will revert as they are no longer required, so if your node does not submit for a given interval, it doesn't mean that it's offline. You should be concerned if you miss more than 5 consecutive intervals in a row, and should check your watchtower daemon logs to verify there aren't any issues.
Enabling this dashboard is a two-step process.
First, enable Oracle DAO metrics in the Metrics section of the rocketpool service config editor:

If you are running in Docker or Hybrid mode, this will restart your node daemon to apply the changes. If you are running in Native mode, please restart the node service manually.
Second, import the Oracle DAO dashboard from Grafana Labs (ID 15003) into your node's local Grafana server.


Checking the Logs

If you or one of the other Oracle DAO members has expressed concern with your node, the first line of defense is to look at the watchtower daemon logs using (for Docker and Hybrid mode) the following command:
rocketpool service logs watchtower
This will show the docker logs for the watchtower container, truncating to the last hundred lines or so.
To go further back, you can use the -t flag to indicate the number of lines. For example:
rocketpool service logs watchtower -t 2000
will show the last 2000 lines. As this will get cluttered very fast, you may want to pipe this into a utility like less so it is scrollable.


Next Steps

In the next section, we'll cover the duties that you must perform manually as an Oracle DAO member.


Oracle DAO Proposals

As a reminder, there are two types of Oracle DAO duties:
Proposals form the core of your responsibities outside of the automated watchtower duties. Essentially, they work as follows:
The collective Oracle DAO should discuss an upcoming proposal extensively ahead of time, so each member is aware of it and understands what that proposal will entail.An Oracle DAO member then creates the proposal via an on-chain transaction.The proposal will then enter a wait period before voting can begin to have further discussion and form their opinion on it. This is currently 7 days on Mainnet.After the wait period is over, members can vote on the proposal via a simple yes-or-no vote.When a quorum of 51% of the Oracle DAO members has voted the same way, the vote is concluded. If 51% agreed to the proposal, it will be able to be executed. Any member can execute the proposal once it is approved.Execution refers to formally triggering the change on-chain, thus modifying the state of the core Rocket Pool contracts.


Making a Proposal

Once you make a proposal, it will enter a review period where the other members can see it and discuss it, but will not be able to vote on it. At the time of writing, this is currently 7 days.
After the review period, there will be a voting period where members can vote either for the proposal, or against it. At the time of writing, this is currently 14 days.
If the proposal reaches quorum before it expires (that is, if enough members vote in favor of it to reach consensus), it will be passed. Quorum is a configurable parameter by the Oracle DAO; it is currently set to at least 51% of the total member pool.
Once a vote is passed, it can be executed which causes its changes to go into effect. At the time of writing, the execution is 14 days after the proposal was passed.
The process for making a new proposal depends on the type of proposal you want to make. Select a type from the tabs below.
Oracle DAO Member ListOracle DAO ParametersContract UpgradesTo propose modifying the list of Oracle DAO members, use the rocketpool odao propose member command which provides the following options:NAME:
   rocketpool odao propose member - Make an oracle DAO member proposal

USAGE:
   rocketpool odao propose member command [command options] [arguments...]

COMMANDS:
   invite, i  Propose inviting a new member
   leave, l   Propose leaving the oracle DAO
   kick, k    Propose kicking a member

OPTIONS:
   --help, -h  show helpinvite Inviting a member is done via rocketpool odao propose member invite which will take 3 additional arguments:The node address to invite (must be a registered Rocket Pool node)The name / label for this nodeThe URL or contact info for the user or organization running the nodeFor example: to invite a new member, run rocketpool odao propose member invite 0xabcd1234abcd1234abcd1234abcd1234abcd1234 some-user [email protected].kick Kicking a member out of the Oracle DAO is done via the rocketpool odao propose member kick command. It will ask you to select which member you want to kick, and issue an optional fine (from 0 RPL up to the bonded RPL amount, currently 1750 RPL). This fine, if provided, will burn part of (or all of) the member's RPL bond if the Oracle DAO votes to kick that member.leave If you would like to voluntarily resign from the Oracle DAO, use the rocketpool odao propose member leave command. This will create a new proposal so the other members can vote on whether or not to approve your resignation.:::::


invite

Inviting a member is done via rocketpool odao propose member invite which will take 3 additional arguments:
The node address to invite (must be a registered Rocket Pool node)The name / label for this nodeThe URL or contact info for the user or organization running the node
For example: to invite a new member, run rocketpool odao propose member invite 0xabcd1234abcd1234abcd1234abcd1234abcd1234 some-user [email protected].


kick

Kicking a member out of the Oracle DAO is done via the rocketpool odao propose member kick command. It will ask you to select which member you want to kick, and issue an optional fine (from 0 RPL up to the bonded RPL amount, currently 1750 RPL). This fine, if provided, will burn part of (or all of) the member's RPL bond if the Oracle DAO votes to kick that member.


leave

If you would like to voluntarily resign from the Oracle DAO, use the rocketpool odao propose member leave command. This will create a new proposal so the other members can vote on whether or not to approve your resignation.
:::::


Viewing Proposals

To view a brief summary of all of the proposals in the protocol's history, use rocketpool odao proposals list. This will sort the proposals by their status and show who proposed it and what it does.
To view the details of a specific proposal, use rocketpool odao proposals details <value> where <value> is the ID of the proposal you would like to view. This will show a comprehensive breakdown of the proposal's information including who created it, when it was created, the payload body, how many members voted in favor of it, how many members voted against it, and whether or not your node has voted on it yet.


Voting on Proposals

To vote on a proposal, use the following command:
rocketpool odao proposals vote
This will provide you with an interactive dialog asking which proposal you would like to vote on, and whether you would like to vote in favor of it or against it. Follow the prompts carefully to complete the vote.


Executing Proposals

When a proposal has received enough votes in favor of it to reach quorum, any member of the Oracle DAO can then execute the proposal (apply its changes) using the following command:
rocketpool odao proposals execute
This will provide you with an interactive dialog asking which proposal you would like to execute. Follow the prompts carefully to complete the execution.


Upgrading to Smartnode v1.3.x

Version 1.3.0 of the Smartnode stack brings some important changes that users should be aware of. They are designed to significantly improve your node operator experience and address many of the features that our users have requested since Rocket Pool's launch.
In this guide, we'll walk you through the process of migrating from an older version of the Smartnode from an older version to v1.3.x and beyond.


Configuration File Changes

v1.3.0 introduces some significant changes in the way the Smartnode's configuration is managed. If you've manually modified the Smartnode configuration before, you should be aware of the following changes:
The config.yml file has been removed. All of its information is now baked directly into the Smartnode stack, so users can no longer accidentally modify the file in a way that prevented the Smartnode from working properly.All of the user-configurable parameters that were previously part of it are now settings in the new service config Terminal UI.The settings.yml file has been replaced with a new file called user-settings.yml. This contains all of your settings for every user-configurable portion of the Smartnode.This file is not meant to be modified directly. Modification should be done through the new service config Terminal UI instead.The chains folder has been removed. The scripts for launching the Execution Client (ETH1), the Beacon Node, and the Validator Client now reside in the scripts folder.The docker-compose YAML files have been removed. Each container now gets its own file in the templates folder. Upon rocketpool service start, these templates are filled out with your settings and put into the runtime folder automatically.Modifying the templates or runtime files is not recommended. Instead, fill in your container customizations using the override files for each container in the override folder. These files will overwrite the Docker files in runtime, so you are free to customize them as you see fit.The files in override will persist upon Smartnode upgrades and reinstallation so you only need to create them once.If you are interested in modifying the docker-compose files via this override mechanic, please see this section


Installing the New Version

Installing the new version should feel very familiar.
Start by stopping the services and downloading the new CLI as usual:
Docker or Hybrid ModeNative ModeStop the Rocket Pool services:rocketpool service stopDownload the new Smartnode CLI for your system (choose from the tabs below):Linux x64Linux arm64macOS x64macOS arm64For x64 systems (most normal machines):shellwget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-cli-linux-amd64 -O ~/bin/rocketpoolNow run the install command:rocketpool service install -dThe -d flag tells it to ignore system dependencies like Docker, since you already have them.NOTEAs of v1.3.0, you no longer have to specify which network you want to install for! The new Smartnode will know which network you're already using, and it will let you change your network dynamically using the new Terminal UI.
After the installation, all of your old configuration files will be moved to a folder named old_config_backup in your Smartnode directory (by default ~/.rocketpool/old_config_backup). You can find them there if you ever need to refer to them for any reason.
If you are looking for instructions on reverting to v1.2.4 from this backup, please scroll to the Reverting to Your Previous Configuration section at the end of this page.


Configuring the Smartnode with the Terminal UI

Now that you have the new CLI and package installed, all of your previous settings have been preserved and migrated to the new system. In the next step, you should run rocketpool service config. This will look quite different compared to previous versions of this function; v1.3.0 introduces the Terminal UI: a terminal-based dynamic user interface for configuring your Smartnode.
You must run it before starting the Docker containers after the migration process to view the configuration, verify that all of your changes were migrated successfully, and update any other settings that you desire.
When you first run it, you will be prompted with this greeting screen (if you were using Docker or Hybrid mode):

NOTENative Mode users will see this screen with slightly different wording, which states the Smartnode is operating in Native mode.
The TUI will begin with the Wizard, which allows you to quickly and easily change the most important parameters of the Smartnode (such as client mode and selection).
All of your previous settings should already be highlighted as you traverse through each page of the wizard so you don't have to remember what your previous configuration was off the top of your head.
NOTEFor a detailed walkthrough of this Wizard, please visit the following pages:For Docker Mode, please visit the new Docker configuration guide.Hybrid Mode users: Hybrid Mode is now a first-class feature of the Smartnode and configuring it is much easier than it used to be. Please visit the new Docker configuration guide and follow it. When you are prompted to choose an Execution client mode and Consensus client mode, choose Externally Managed for them accordingly.For Native Mode, please visit the new Native configuration guide.
Navigate through this wizard and confirm that all of your settings are correct.
Once you are done, you will have the option of reviewing all of the settings before saving if you desire. This includes settings that the Wizard didn't cover, such as the RPL claim gas threshold or your max number of Geth peers as examples.
The main settings screen, which you should also look at to confirm your previous settings, will look like this (for Docker and Hybrid mode users):

NOTENative Mode users will see a slightly different screen that is unique to Native mode and only presents the settings that are relevant for it.
Feel free to explore this new UI and adjust any settings you see fit. Use the Arrow Keys to navigate, and press Enter to enter a category or confirm any changes to a setting that you make.
Press Esc when you're finished editing a category to return to this home screen.
When you're ready to save your changes and start the Smartnode stack, simply press Tab to move down to the buttons at the bottom of the screen, select Review Changes and Save (by making it green via the arrow keys). Press Enter to be brought to the Review Page, where you can see everything you've changed since the last time you ran rocketpool service config.
Confirm all of your change are present, and then press Enter again to save them. The screen will show you which containers need to be restarted for the changes to apply, though since you're migrating, you've already turned the containers off and they will all be restarted anyway.


Starting the Smartnode Stack

Once you've saved your configuration, the terminal will ask if you want to restart the containers automatically (unless you're using Native mode). If you do not / cannot allow them to start automatically, you can start them up manually with the following commands:
Docker or Hybrid ModeNative Moderocketpool service start
Once they're up, you can verify that everything is working as intended.
Use the rocketpool service version command to check that you have the correct version of the Smartnode and client containers:
$ rocketpool service version

Your Smartnode is currently using the Prater Test Network.

Rocket Pool client version: 1.3.0-rc1
Rocket Pool service version: 1.3.0-rc1
Selected Eth 1.0 client: Geth (Locally managed)
	Image: ethereum/client-go:v1.10.16
Selected Eth 2.0 client: Nimbus (Locally managed)
	Image: statusim/nimbus-eth2:multiarch-v22.3.0
Use the rocketpool service logs eth1 and rocketpool service logs eth2 commands to watch the logs for your Execution client (formerly ETH1 client) and your Consensus client (formerly ETH2 client). Look out for any errors and please visit our Discord server for help if you encounter them.


Reverting to your Previous Configuration

If, for any reason, you need to revert back to v1.2.4 of the Smartnode stack, don't worry! All of your old configuration files have been preserved in a backup directory and can easily be retrieved to restore your previous setup.
Select which mode you use from the tabs below and follow the instructions.
Docker or Hybrid ModeNative ModeStart by replacing the CLI with the v1.2.4 CLI for your system:Linux x64Linux arm64macOS x64macOS arm64For x64 systems (most normal machines):shellwget https://github.com/rocket-pool/smartnode-install/releases/download/v1.2.4/rocketpool-cli-linux-amd64 -O ~/bin/rocketpoolNext, copy all of your old configuration files from the old_config_backup folder back into the Smartnode's folder:shellcd ~/.rocketpool
cp -r old_config_backup/*Now, all you need to do is restart the Docker containers:rocketpool service startDone! Your old configuration is back.


Migrating the Smartnode from Previous Beta Tests

If you've been a Rocket Pool node operator during our previous beta tests on Medalla or Pyrmont, thank you for helping us improve the protocol and welcome back! This brief guide will walk you through the process of purging your own beta build and setting up the newest build for either the Prater testnet, or for real staking on mainnet.
Prater NetworkMainnet NetworkNOTEYou will need to create a new node wallet to interact with the Prater test network. Re-using a wallet from a previous beta build may result in failures while creating new validators!There are three major steps towards upgrading from a beta build to the Prater test network.First, migrate any goerli ETH you have to a separate wallet. You can then migrate it back to the new node wallet you create after you reinstall Rocket Pool, so you don't need to rely as much on a faucet for goerli ETH.The easiest way to do this is via Metamask - see the rETH staking guide for a walkthrough of how to set up a new wallet. You can do this using the following command:shellrocketpool node send XXX eth 0xabcd1234...where XXX is the amount of goerli ETH to send, and 0xabcd1234... is the address of the new wallet you created. Note that you'll need to leave a little bit of ETH behind to pay for the gas used in the transaction!Next, remove all the old Docker images and chain data with the following command:shellrocketpool service terminateOnce this is done, remove the old Rocket Pool data and settings folder. This will delete your old wallet and your old validators, so make sure you no longer need to save them for anything!shellsudo rm -rf ~/.rocketpoolOnce this is done, your old beta setup will be cleaned. You can follow the Rocket Pool installation guide for a walkthrough on installing and configuring Rocket Pool for the Prater testnet.


8-ETH Bonded Minipools

When Rocket Pool was first launched, it supported two types of minipools:
The latter was removed by a community vote several months into the protocol's life due to it no longer being necessary and resulting in long refund delays.
The former represented the protocol's lowest bond amount because it guaranteed that if a node operator used Rocket Pool to attack the Ethereum protocol and had their entire bond slashed, they would stand to lose just as much as the rETH stakers and would not come out ahead.
Since Rocket Pool's launch, the community has done significant research on the security provided by this bond and found that it was very conservative. For all intents and purposes, a slashing of 16 ETH was deemed unrealistic and a 16-ETH bond effectively provided the same security benefits as a bond of only 8 ETH (plus the supplemental RPL requirement). Thus, backed by this research, the Atlas upgrade introduces a new type of minipool to the list: the 8-ETH bond, colloquially referred to by the Rocket Pool community as an "LEB8" (Lower ETH Bond - 8 ETH).
To create an 8-ETH minipool, the node operator only needs to provide 8 of their own ETH (plus enough RPL to cover the collateral requirement - more on this in RPL Collateral). It will then pull 24 ETH from the deposit pool in order to complete the validator and get to work on the Beacon Chain.
This opens the door to new prospective node operators that want to run a node but don't quite have 16 ETH. Further, it lets larger node operators put more pool staker ETH to work on the Beacon Chain earning rewards. As this works without meaningfully compromising security, everybody wins!
In this guide, we'll cover three topics:
How 8-ETH bonded minipools actually work, and the reward numbers behind themHow to create a new 8-ETH minipoolHow to migrate an existing 16-ETH minipool down to an 8-ETH minipool without exiting
Read on to learn more about each topic.


How 8-ETH Bonded Minipools Work

Mechanically, 8-ETH bonded minipools behave identically to every other minipool in the protocol. They still "own" a validator on the Beacon Chain (they represent that validator's withdrawal credentials), they still come with a commission (though the commission with Atlas will be fixed at 14% for all new minipools), and they provide all the same functionality that a 16-ETH bonded minipool does. The difference lies entirely in the numbers.


Rewards

From a profitability perspective (looking purely at ETH rewards and ignoring RPL), 8-ETH bonded minipools with a 14% commission provide more rewards to the node operator than even 16-ETH bonded minipools at 20% commission (which, as of Redstone, is the highest possible reward configuration). At the same time, they also provide more rewards to the rETH holders as well due to the fact that the node operators are more efficiently putting the capital of the rETH holders to work.
Let's walk through a simple example to illustrate. Say we are a node operator with 16 ETH available to stake (plus the required RPL bond). Say we've earned 1 ETH of rewards on the Beacon Chain per validator. Here's how the math works out for a single 16-ETH minipool with a 20% commission, versus two 8-ETH minipools at 14% commission:
1x 16 ETH Minipool @ 20%:
Rewards: 1 ETH
Node Share = (16/32) + (16/32 * 0.2)
           = 0.5 + (0.5 * 0.2)
           = 0.5 + 0.1
           = 0.6 ETH

rETH Share = 1 - 0.6
           = 0.4 ETH

2x 8 ETH Minipools @ 14%:
Rewards: 2 ETH
Node Share = ((8/32) + (24/32 * 0.14)) * 2
           = (0.25 + (0.75 * 0.14)) * 2
           = (0.25 + 0.105) * 2
           = 0.71 ETH

rETH Share = 2 - 0.71
           = 1.29 ETH
In other words, a node operator will earn 18% more ETH via two 8-ETH minipools than they would with a single 16-ETH minipool at 20% commission.


RPL Collateral

In order to create an 8-ETH minipool, node operators still need to stake enough RPL to cover the minimum collateral requirements for their node (accounting for all of its minipools of all bond sizes).
These rules have been clarified with Atlas:
The minimum RPL per minipool is 10% of the borrowed amountThe maximum RPL per minipool is 150% of the bonded amount
For a 16-ETH minipool, this remains unchanged; the minimum is 1.6 ETH worth of RPL, and the maximum is 24 ETH worth of RPL.
For an 8-ETH minipool, this becomes a minimum of 2.4 ETH worth of RPL (10% of the borrowed amount, which is 24 ETH) and a maximum of 12 ETH worth of RPL (150% of the bonded amount).
These numbers were selected by the Rocket Pool community as part of a governance vote.


Creating a New 8-ETH Minipool

The process to create a new minipool with an 8-ETH bond is identical to the process for creating a 16-ETH minipool.
Simply run the following command:
rocketpool node deposit
When prompted for your bond amount, select 8 ETH:
Your eth2 client is on the correct network.

NOTE: by creating a new minipool, your node will automatically claim and distribute any balance you have in your fee distributor contract. If you don't want to claim your balance at this time, you should not create a new minipool.
Would you like to continue? [y/n]
y

Please choose an amount of ETH to deposit:
1: 8 ETH
2: 16 ETH
1

Your minipool will use the current fixed commission rate of 14.00%.
You currently have 8.00 ETH in your credit balance.
This deposit will use 8.000000 ETH from your credit balance and will not require any ETH from your node.
...
NOTEThis example also shows usage of the new Deposit Credit System. Since the node operator has 8 ETH in credit, creating this 8-ETH minipool is free!
That's all there is to it! The rest of the process is the same as the usual minipool creation instructions.


The Rocket Pool Redstone Update

Rocket Pool's next major update, titled Redstone, has been released for beta testing on the Ropsten and Prater test networks. This page describes the major changes that Redstone brings, including updates to both the Smartnode stack and to the Rocket Pool protocol in general.
Please read through this page thoroughly to understand all of the differences between the previous version of Rocket Pool and Redstone.
ATTENTIONFor detailed information on how to prepare your node for the upgrade and what to do after the upgrade, please look at the following guides:Guide for Docker ModeGuide for Hybrid ModeGuide for Native Mode


Client Changes and The Merge

Ropsten (and shortly, Prater) have successfully undergone The Merge of the Execution and Consensus Layers. It no longer uses Proof-of-Work; instead, validators on Ropsten are now responsible for creating and proposing blocks on both chains. While this comes with some exciting financial benefits (which will be discussed later), it also comes with some important changes to the way validators operate.
Below is a brief summary of the changes to client behavior as part of The Merge:
Your Execution client now uses three API ports:One for HTTP access to its API (default 8545)One for Websocket access to its API (default 8546)One for the new Engine API used by Consensus clients after The Merge (default 8551)Execution clients now require a Consensus client to function, and Consensus clients now require an Execution client to function.Neither one can operate in isolation any longer.One Execution client must be linked to one, and only one, Consensus client (and vice versa).You will not be able to link multiple Execution clients to a single Consensus client, or multiple Consensus clients to a single Execution client.Because of this, fallback execution clients are no longer available for Rocket Pool node operators.Full execution clients are required.Remote providers (like Infura and Pocket) can no longer be used by any validators, Rocket Pool or otherwise.


Fee Recipients and Your Distributor

As validators are now responsible for creating blocks, that means they receive the priority fees (also known as tips) attached to each transaction. These fees are paid in ETH, and they are provided directly to you every time one of your minipool validators proposes a block. Unlike the ETH locked on the Beacon Chain, you don't have to wait for withdrawals to access your priority fees! They are simply awarded to you as part of the block proposal process.
In order to know where to send the fees to, your Validator Client requires an extra parameter known as the fee recipient. This is the address on the Execution Layer (ETH1) that all of the priority fees earned by your node during block proposals will be sent to.
Rocket Pool is designed to fairly distribute these rewards, the same way it fairly distributes your Beacon chain rewards: half of any priority fees your minipool validators earn will go to you (plus the average commission of all of your minipools), and the other half will go to the pool stakers (minus your average commission).
To that end, the Smartnode will automatically set your Validator Client's fee recipient to a special address known as your node's fee distributor. Your fee distributor is a unique contract on the Execution Layer that's specific to your node. It will hold all of the priority fees you've earned over time, and it contains the logic required to fairly split and distribute them. This distribution process is controlled by you (the node operator), and can be done whenever you please. It does not have a time limit.
The address for your node's fee distributor is deterministically based on your node address. That means it is known ahead of time, before the fee distributor is even created. The Smartnode will use this address as your fee recipient.
NOTEBy default, your fee recipient will be set to the rETH address when you install Smartnode v1.5.0 (if the Redstone contract updates haven't been deployed yet). The Smartnode will automatically update this to your node's fee distributor address once the Redstone update has been deployed.One exception to this rule is if you are opted into the Smoothing Pool - see the section at the end of this page for more information on it.
New Rocket Pool nodes will automatically initialize their node's distributor contract upon registration. Existing nodes will need to do this process manually. This only needs to be run once.
One interesting ramification of this is that your distributor's address may start accruing a balance before you've initialized your node distributor contract. This is okay, because your distributor will gain access to all of this existing balance as soon as you initialize it.
You can view your fee distributor's balance as part of:
rocketpool node status
The output will look like this:

To initialize your node's distributor, simply run this new command:
rocketpool node initialize-fee-distributor
NOTEAfter the Redstone update, you must call this function before you can create any new minipools with rocketpool node deposit.
When your distributor has been initialized, you can claim and distribute its entire balance using the following command:
rocketpool node distribute-fees
This will send your share of the rewards to your withdrawal address.


Rocket Pool Protocol Changes

In addition to the Execution and Consensus client changes and the new priority fees, the Rocket Pool protocol itself has undergone some important changes you should be aware of.


New Rewards System

One of the most significant changes introduced with the Redstone update is the new rewards system. This is a complete overhaul of the way node operators receive their RPL rewards (and ETH from the Smoothing Pool - discussed later).
The old rewards system had the following drawbacks:
Claiming cost approximately 400k gas, which is quite expensive.Node operators had to claim the rewards at each interval (every 28 days), or would forfeit them. This meant the gas costs could become prohibitively expensive for node operators with small amounts of RPL.Rewards were determined at the time of the claim, not at the time of the checkpoint. If a user staked a significant amount of RPL between the checkpoint and your claim, your rewards could be diluted and you'd receive less RPL than you were expecting.
The new claims system solves all of these problems.
At every interval, the Oracle DAO will collectively create a true snapshot of the state of the node operators in the Rocket Pool network, including all of their effective stake amounts. This information is compiled into a Merkle Tree - an extremely efficient way to make all of the details available to smart contracts. The Merkle Tree is built into a JSON file and hosted on the InterPlanetary File System (IPFS), and the root of the Merkle Tree is submitted to the contracts.
This new system has the following features:
You can now let rewards accumulate for as long as you want. No more time limit on when you need to claim.You can claim multiple intervals all at once.Your first claim transaction uses about 85k gas. Each subsequent claim transaction costs about 55k gas. If you're claiming multiple intervals at once, each supplemental interval costs 6k gas so it's most cost-effective to claim as many of them at once as possible.Your RPL rewards no longer get diluted - your RPL rewards are fixed at the time of the snapshot, and you are always eligible for that amount.You can restake some (or all) of your RPL rewards as part of the claiming transaction, which further trims down gas requirements compared to today.Currently, all of your claims must be on Mainnet but we have the infrastructure in place to build the ability to claim on Layer 2 networks at a later date.
When your node detects a new rewards checkpoint, it will automatically download the JSON file for that interval. You can then review your rewards using the following command:
rocketpool node claim-rewards
As intervals go by and you accumulate rewards, the output will look like this:

Here you can quickly see how many rewards you've earned at each interval, and can decide which ones you want to claim. Note that Ropsten's interval time is set to 1 day to facilitate testing.
You can also specify an amount you want to restake during this claim:

This will let you compound your RPL rewards in one transaction, using substantially less gas than you currently need to use today.
NOTEIf you prefer to build the rewards checkpoint manually instead of downloading the one created by the Oracle DAO, you can change this setting from Download to Generate in the TUI:As the tip implies, you will need access to an archive node to do this. If your local Execution client is not an archive node, you can specify a separate one (such as Infura or Alchemy) in the Archive-Mode EC URL box below it. This URL will only be used when generating Merkle trees; it will not be used for validation duties.
WARNINGIf you are below 10% RPL collateral at the time of the snapshot, you will not be eligible for rewards for that snapshot. Unlike the current system, where you can simply "top off" before you claim in order to become eligible again, this will be locked in that snapshot forever and you will never receive rewards for that period. You must be above 10% collateral at the time of a snapshot in order to receive rewards for that period.


Smoothing Pool

One final exciting new feature of the Redstone update is the Smoothing Pool. The Smoothing Pool is an opt-in feature that will collectively pool the priority fees of every member opted into it. During a rewards checkpoint, the total ETH balance of the pool is divided into a pool staker portion and a node operator portion. All of the rewards in the node operator portion are distributed fairly to every member of the pool.
In essence, the Smoothing Pool is a way to effectively eliminate the randomness associated with block proposals on the Beacon Chain. If you've ever had a streak of bad luck and gone months without a proposal, you may find the Smoothing Pool quite exciting.
NOTEThe Smoothing Pool rewards are built into the Merkle Tree used for RPL rewards, so you claim them at the same time you claim RPL using rocketpool node claim-rewards.
To help clarify the details, the Smoothing Pool uses the following rules:
Opting into the Smoothing Pool is done on a node level. If you opt in, all of your minipools are opted in.The node operator's total share is determined by the average commission of every minipool in every node opted into the Smoothing Pool.Anyone can opt in at any time. They must wait a full rewards interval (1 day on Ropsten, 28 days on Mainnet) before opting out to prevent gaming the system.Once opted out, you must wait another full interval to opt back in.The Smoothing Pool calculates the "share" of each minipool (portion of the pool's ETH for the interval) owned by each node opted in.The share is a function of your minipool's performance during the interval (calculated by looking at how many attestations you sent on the Beacon Chain, and how many you missed), and your minipool's commission rate.Your node's total share is the sum of your minipool shares.Your node's total share is scaled by the amount of time you were opted in.If you were opted in for the full interval, you receive your full share.If you were opted in for 30% of an interval, you receive 30% of your full share.
To opt into the Smoothing Pool, run the following command:
rocketpool node join-smoothing-pool
This will record you as opted-in in the Rocket Pool contracts and automatically change your Validator Client's fee recipient from your node's distributor contract to the Smoothing Pool contract.
To leave the pool, run this command:
rocketpool node leave-smoothing-pool


The Penalty System

To ensure that node operators don't "cheat" by manually modifying the fee recipient used in their Validator Client, Rocket Pool employs a penalty system.
The Oracle DAO constantly monitors each block produced by Rocket Pool node operators. Any block that has a fee recipient other than one of the following addresses is considered to be invalid:
The rETH addressThe Smoothing Pool addressThe node's fee distributor contract (if opted out of the Smoothing Pool)
A minipool that proposed a block with an invalid fee recipient will be issued a strike. On the third strike, the minipool will begin receiving infractions - each infraction will dock 10% of its total Beacon Chain balance, including ETH earnings and send them to the rETH pool stakers upon withdrawing funds from the minipool.
Infractions are at a minipool level, not a node level.
The Smartnode software is designed to ensure honest users will never get penalized, even if it must take the Validator Client offline to do so. If this happens, you will stop attesting and will see error messages in your log files about why the Smartnode can't correctly set your fee recipient.


Guides for Pre- and Post-Upgrade

For detailed information on how to prepare your node for the upgrade and what to do after the upgrade, please look at the following guides:
Guide for Docker ModeGuide for Hybrid ModeGuide for Native Mode


[Docker Mode] Guide to the Redstone Update and the Merge

This guide will cover everything you need to know in order to prepare your node for the Redstone Update and The Merge if you are using Docker Mode.


Things to Do Before Upgrading to v1.5.0

Before upgrading to v1.5.0 and higher of the Smartnode, please go through the following checklist to make sure you're prepared:


Switch to a Full Execution Client

The Merge requires you to run your own Execution client, so you won't be able to use remote providers like Infura or Pocket anymore. v1.5.0 won't have them anymore, and won't let you start the stack until you select a full Execution client.
Because of this change, you should switch to a full client while you're still on v1.4, let it sync to completion, and then upgrade to v1.5.
Docker Mode makes switching clients very easy. This guide provides a walkthrough of the process.


Upgrading to v1.5.0

Upgrading the Smartnode stack to v1.5.0 is no different than any other upgrade. Simply follow the normal directions here.


Things the Smartnode Handles Automatically

In Docker mode, the Smartnode will take care of most of the changes needed to support Redstone and The Merge automatically once you update to v1.5.0. Here's a brief list of what it will do for you without any manual intervention:


The Engine API

The Merge changes the way your Execution client talks to your Consensus client. Instead of using the old HTTP or Websocket based RPC system, The Merge requires a new system exposed by your Execution client called the Engine API.
This is a special connection that lets the Consensus client replace the old Proof-of-Work mining system with Proof-of-Stake; it's the heart of The Merge. It's also authenticated with a secret token, so only your Consensus client can connect to your Execution client - nothing else can.
The Smartnode will handle the set up of the authentication token and the Engine API on both your Execution and Consensus clients automatically.


Your Fee Recipient

The fee recipient is the address on the Execution layer (eth1) chain that will receive all of the priority fees for blocks you propose. It is a setting provided to your Validator client when it first starts.
The Smartnode will handle setting it up to the correct address when you upgrade to v1.5, and will constantly check to make sure you're using the correct one so you don't get penalized accidentally.
If you opted into the Smoothing Pool, it will make that your fee recipient. If you didn't, it will make your fee distributor contract the fee recipient.


MEV-Boost

MEV-boost is the system Flashbots provides to give MEV rewards to Proof-of-Stake validators after The Merge. Rocket Pool has MEV-Boost built into the Smartnode and automatically configures your node to use it, so your proposals get the maximum amount of rewards.


Things You Should Do After Upgrading

While the Smartnode handles most of the changes for you, there are a few additional things you should do manually:


Ensure a Successful Upgrade

The first thing to do is ensure that your node is working correctly. Consider taking the following steps:
Check the logs for errors with rocketpool service logs eth1, rocketpool service logs eth2, rocketpool service logs validator, and rocketpool service logs node.Confirm with a Block Explorer (such as your Grafana dashboard and https://beaconcha.in) that you are still attesting properly Remember that if you have Doppelganger protection enabled, you will miss a few attestations after the restart. This is normal!


Set Up a Fallback Node

Because The Merge is not compatible with remote providers like Infura and Pocket, you'll lose the ability to use them as fallback Execution clients when your primary goes offline.
The Smartnode still has the ability to provide a fallback Execution client (and now a fallback Consensus client as well), but you will now need to use Execution and Consensus clients that you control.
For more information on setting up a fallback node, see the Fallback node guide.


Initialize your Fee Distributor

If you aren't planning to opt into the Smoothing Pool and claim all of your priority fees and MEV rewards to your fee distributor contract, you will eventually have to initialize it (create the contract instance on the chain) in order to claim rewards from it to your withdrawal address.
This is a fairly cheap operation and only needs to be done once.
TIPInitializing your fee distributor can be done at any time. You can let rewards accumulate in its address long before you initialize it, and your balance will remain after initialization.We recommend you do so when gas prices are low to minimize the overhead cost.Note that it must be initialized in order to claim your rewards.


Opt Into the Smoothing Pool

If you plan on taking advantage of the Smoothing Pool right away, you should opt in before the end of the first Redstone rewards period to maximize your "eligibility" amount.
Opting in can be done via running the following command:
rocketpool node join-smoothing-pool


Claim Rewards

The Redstone upgrade replaces the expensive, problematic old rewards system with a brand new one that's much cheaper, supports automatic restaking of RPL (both partial and full amounts), and - most importantly - lets you claim your rewards whenever you want.
Because there is no longer a time limit on claiming rewards, and because it's cheaper to claim many rewards intervals at once, the automatic rewards claiming feature of the Smartnode has been removed. You will now be able to claim rewards via the following command:
rocketpool node claim-rewards
This will show you all of the rewards you've accumulated across all of the rewards intervals starting with the Redstone upgrade.


Reverting to v1.4.3

If, for any reason, something isn't to your liking and you want to revert to the previous Smartnode release, you can do so easily. The Smartnode automatically backs up your settings from the previous version when you upgrade it, so simply get the previous version (here we're demonstrating v1.4.3) and replace the settings with the backup:
rocketpool service stop
rocketpool service install -d
cp ~/.rocketpool/user-settings-backup.yml ~/.rocketpool/user-settings.yml
rocketpool service config
rocketpool service start
All set! You're now back on the old version and should begin attesting shortly after starting the service.
WARNINGv1.4.3 is deprecated and will no longer be usable after the Redstone update is deployed. If you do need to revert to it, please make plans to upgrade back to v1.5.0 before the contracts are updated!


[Hybrid Mode] Guide to the Redstone Update and the Merge

This guide will cover everything you need to know in order to prepare your node for the Redstone Update and The Merge if you are using Hybrid Mode.


Things to Do Before Upgrading to v1.5.0


Switch to a Full Execution Client

The Merge requires you to run your own Execution client, so you won't be able to use remote providers like Infura or Pocket anymore.
Because of this change, if you're currently using a light Execution client, you should switch to a full client while you're still on v1.4, let it sync to completion, and then upgrade to v1.5.


Ensure the EC and CC are Both Externally Managed

Previous versions of the Smartnode stack allowed you to have one client locally managed, and the other externally managed. For example, you could have an Execution client that the Smartnode manages and connect it to a Consensus client that you manage externaly.
Starting with v1.5, this configuration is no longer supported. You'll have to switch to either a locally managed Execution and Consensus client (also known as Docker Mode), or set up both an Execution and a Consensus client that you manage on your own.
TIPIf you are interested in letting the Smartnode maintain its own Execution and Consensus client but want to keep control over your own Validator client (e.g., if you have your own solo staking validator keys attached to it), you may want to consider Reverse Hybrid Mode which does exactly this!


Set Up the Engine API

The Merge changes the way your Execution client talks to your Consensus client. Instead of using the old HTTP or Websocket based RPC system, The Merge requires a new system exposed by your Execution client called the Engine API.
This is a special connection that lets the Consensus client replace the old Proof-of-Work mining system with Proof-of-Stake; it's the heart of The Merge. It's also authenticated with a secret token, so only your Consensus client can connect to your Execution client - nothing else can.
As you manage your own Execution and Consensus clients, you'll need to set up the Engine API manually. How to do it depends entirely on which clients you're running.
CoinCashew has a great and concise guide on how to set up the Engine API on your Execution and Consensus clients. Give that a look, and test the new configuration out by making sure it still attests properly before upgrading.
As always, Rocket Pool will manage its own Validator client so you don't need to worry about manually modifying it.


Upgrading to v1.5.0


In Hybrid mode, the Smartnode will take care of some of the changes needed to support Redstone automatically once you update to v1.5.0, but you will need to handle others manually in Hybrid Mode.
Here's a brief list of what it will do for you without any manual intervention:


Your Fee Recipient

The fee recipient is the address on the Execution layer (eth1) chain that will receive all of the priority fees for blocks you propose. It is a setting provided to your Validator client when it first starts.
The Smartnode will handle setting it up to the correct address on the Validator client it manages when you upgrade to v1.5, and will constantly check to make sure you're using the correct one so you don't get penalized accidentally.
If you opted into the Smoothing Pool, it will make that your fee recipient. If you didn't, it will make your fee distributor contract the fee recipient.


Things You Should Do After Upgrading


Ensure a Successful Upgrade

The first thing to do is ensure that your node is working correctly. Consider taking the following steps:
Check the logs for errors with rocketpool service logs validator and rocketpool service logs node.Confirm with a Block Explorer (such as your Grafana dashboard and https://beaconcha.in) that you are still attesting properly Remember that if you have Doppelganger protection enabled, you will miss a few attestations after the restart. This is normal!


Set Up MEV-Boost

MEV-boost is the system Flashbots provides to give MEV rewards to Proof-of-Stake validators after The Merge.
Rocket Pool requires all nodes to use it to maximize their returns and thus keep the protocol competitive with other staking services.
You will need to make some adjustments to your Beacon Node / Consensus client to connect it to MEV-boost.
MEV-boost is currently not available on Prater or Mainnet, so you do not need to set it up at this time. Of course, you will not be penalized for not using it during this transition period.
Once it becomes available, we will announce a date at which it must be installed and connected to your node. Flashbots will provide instructions you can follow at that time, and we will link to them here.
NOTEOnce we make the announcement that MEV-boost must be enabled by all node operators, you must ensure you have it properly installed and configured with your Beacon Node!Not doing so will result in your minipool being penalized.


Set Up a Fallback Node


Initialize your Fee Distributor


Opt Into the Smoothing Pool


Claim Rewards


Reverting to v1.4.3


[Native Mode] Guide to the Redstone Update and the Merge

This guide will cover everything you need to know in order to prepare your node for the Redstone Update and The Merge if you are using Native Mode.


Things to Do Before Upgrading to v1.5.0

Before upgrading to v1.5.0 and higher of the Smartnode, please go through the following checklist to make sure you're prepared:


Switch to a Full Execution Client


Set Up the Engine API

The Merge changes the way your Execution client talks to your Consensus client. Instead of using the old HTTP or Websocket based RPC system, The Merge requires a new system exposed by your Execution client called the Engine API.
This is a special connection that lets the Consensus client replace the old Proof-of-Work mining system with Proof-of-Stake; it's the heart of The Merge. It's also authenticated with a secret token, so only your Consensus client can connect to your Execution client - nothing else can.
As you manage your own Execution and Consensus clients, you'll need to set up the Engine API manually. How to do it depends entirely on which clients you're running.
CoinCashew has a great and concise guide on how to set up the Engine API on your Execution and Consensus clients. Give that a look, and test the new configuration out by making sure it still attests properly before upgrading.
We'll show you how to set up your Validator client so that it uses the correct fee recipient required by the Smartnode software automatically below.


Upgrading to v1.5.0

Upgrading the Smartnode stack to v1.5.0 is no different than any other upgrade. Simply follow the normal directions here.


Things You Should Do After Upgrading

In Native mode, there are several things you will need to do manually after upgrading:


Ensure a Successful Upgrade

The first thing to do is ensure that your node is working correctly. Consider taking the following steps:
Check your log scripts for the Execution client, the Consensus client, the Validator client, and the Smartnode daemon (the rp-node service) to ensure they're all functioning normally without errors.Confirm with a Block Explorer (such as your Grafana dashboard and https://beaconcha.in) that you are still attesting properly Remember that if you have Doppelganger protection enabled, you will miss a few attestations after the restart. This is normal!


Set up the Fee Recipient in your Validator Client

One of the critical details to set up prior to the Merge is the fee recipient specified by your validator client. As described in the overview article, this can be one of two values:
If you are opted into the Smoothing Pool, this must be the address of the Smoothing Pool contract. You can get the address from the official contracts page.If you are not in the Smoothing Pool, this must be the address of your node's fee distributor contract. You can get the address by running rocketpool node status, under the Fee Distributor and Smoothing Pool section.
In Native mode, you have the choice of letting the Smartnode manage this for you if you use the Smartnode daemon service, rp-node, or managing it yourself if you do not use the daemon.


Automatic Management via the Daemon

The Smartnode daemon will automatically determine the appropriate fee recipient for your node and manage it in case it changes (such as opting into and out of the Smoothing Pool). This is the safest option, because the Smartnode will always ensure it's set to a value that prevents penalization.
The way it does this is by maintaining a file with the correct fee recipient in it, and regularly refreshing it to ensure its correctness. When it needs to be updated, it modifies the file and restarts your Validator client automatically so it loads the new recipient - similarly to how it restarts your Validator client after staking a new minipool.
Select your client below to learn how to set it up:
LighthouseNimbusPrysmTekuModify your Validator Client service by adding the following line before the ExecStart line:EnvironmentFile=<data dir>/validators/rp-fee-recipient-env.txtFor example:EnvironmentFile=/srv/rocketpool/data/validators/rp-fee-recipient-env.txtNext, add the following command line argument to the end of your ExecStart line:--suggested-fee-recipient ${FEE_RECIPIENT}Your VC will now use the file managed by the Smartnode daemon, and will automatically be restarted whenever the fee recipient changes. :::::


Manual Fee Recipient Management

WARNINGBy doing this, you assume full responsibility for ensuring your fee recipient is always set to the correct address.Please read the penalty specification to understand what it must be set to given your configuration, and when you can safely change it from one value to another.Failure to do so could result in your minipools being penalized!
Prior to Redstone being deployed, you can simply use the rETH address for the network you're on (which can be found in the official contracts page). The rETH address is always safe no matter what.
Once Redstone has been deployed, you can see the exact address that you should set your fee recipient to via rocketpool node status. For example, if you are opted into the Smoothing Pool, it will show the Smoothing Pool's address and note that you must use it as your fee recipient:

If you are not opted into the Smoothing Pool, it will show your fee distributor address and note that you must use it as your fee recipient:

Select your Consensus client below to learn how to configure it.
LighthouseNimbusPrysmTekuAdd the following command line argument to your Validator Client's service definition file:--suggested-fee-recipient <address>Where <address> is:The rETH address before the Redstone update is deployed (e.g., 0xae78736Cd615f374D3085123A210448E74Fc6393 on Mainnet)Your node's fee distributor after Redstone is deployed, which you can retrieve with rocketpool node status once the contract upgrade occursThe Smoothing Pool address if you opt into the Smoothing PoolAs a reminder, rocketpool node status will show you the correct fee recipient to use at any time.Please read the penalty specification carefully to understand the conditions and expectations around the fee recipient. :::::


Set Up MEV-Boost


Set Up a Fallback Node

Because The Merge is not compatible with remote providers like Infura and Pocket, you'll lose the ability to use them as fallback Execution clients when your primary goes offline.
The Smartnode still has the ability to provide a fallback Execution client (and now a fallback Consensus client as well), but you will now need to use Execution and Consensus clients that you control.
For more information on setting up a fallback node, see the Fallback node guide.


Initialize your Fee Distributor

If you aren't planning to opt into the Smoothing Pool and claim all of your priority fees and MEV rewards to your fee distributor contract, you will eventually have to initialize it (create the contract instance on the chain) in order to claim rewards from it to your withdrawal address.
This is a fairly cheap operation and only needs to be done once.
TIPInitializing your fee distributor can be done at any time. You can let rewards accumulate in its address long before you initialize it, and your balance will remain after initialization.We recommend you do so when gas prices are low to minimize the overhead cost.Note that it must be initialized in order to claim your rewards.


Opt Into the Smoothing Pool

If you plan on taking advantage of the Smoothing Pool right away, you should opt in before the end of the first Redstone rewards period to maximize your "eligibility" amount.
Opting in can be done via running the following command:
rocketpool node join-smoothing-pool


Claim Rewards

The Redstone upgrade replaces the expensive, problematic old rewards system with a brand new one that's much cheaper, supports automatic restaking of RPL (both partial and full amounts), and - most importantly - lets you claim your rewards whenever you want.
Because there is no longer a time limit on claiming rewards, and because it's cheaper to claim many rewards intervals at once, the automatic rewards claiming feature of the Smartnode has been removed. You will now be able to claim rewards via the following command:
rocketpool node claim-rewards
This will show you all of the rewards you've accumulated across all of the rewards intervals starting with the Redstone upgrade.


Preparing a Raspberry Pi

NOTEThis page has been left here for archival purposes. We no longer recommend running Rocket Pool on a Raspberry Pi due to the increased hardware and performance requirements of running an Ethereum validator.
This guide will walk you through how run a Rocket Pool node using a Raspberry Pi. While this is not typically recommended in most staking guides, we recognize that it is attractive because it is a much more affordable option than standing up an entire PC. To that end, we've worked hard to tweak and optimize a whole host of settings and have determined a configuration that seems to work well.
This setup will run a full Execution node and a full Consensus node on the Pi, making your system contribute to the health of the Ethereum network while simultaneously acting as a Rocket Pool node operator.


Preliminary Setup

To run a Rocket Pool node on a Raspberry Pi, you'll need to first have a working Raspberry Pi. If you already have one up and running - great! You can skip down to the Mounting the SSD section. Just make sure you have a fan attached before you go. If you're starting from scratch, then read on.


What You'll Need

These are the recommended components that you'll need to buy in order to run Rocket Pool on a Pi:
A Raspberry Pi 4 Model B, the 8 GB modelNote: while you can use a 4 GB with this setup, we strongly recommend you go with an 8 GB for peace of mind... it's really not much more expensive.A USB-C power supply for the Pi. You want one that provides at least 3 amps.A MicroSD card. It doesn't have to be big, 16 GB is plenty and they're pretty cheap now... but it should be at least a Class 10 (U1).A MicroSD to USB adapter for your PC. This is needed so you can install the Operating System onto the card before loading it into the Pi. If your PC already has an SD port, then you don't need to pick up a new one.Some heatsinks. You're going to be running the Pi under heavy load 24/7, and it's going to get hot. Heatsinks will help so it doesn't throttle itself. You ideally want a set of 3: one for the CPU, one for the RAM, and one for the USB controller. Here is a good example of a nice set.A case. There are two ways to go here: with a fan, and fanless. With a fan: A 40mm fan. Same as the above, the goal is to keep things cool while running your Rocket Pool node.A case with a fan mount to tie it all together. You could also get a case with integrated fans like this one so you don't have to buy the fans separately.Without a fan: A fanless case that acts as one giant heatsink, like this one. This is a nice option since it's silent, but your Pi will get quite hot - especially during the initial blockchain sync process. Credit to Discord user Ken for pointing us in this direction!As a general rule, we recommend going with a fan because we're going to be overclocking the Pi significantly.
You can get a lot of this stuff bundled together for convenience - for example, Canakit offers a kit with many components included. However, you might be able to get it all cheaper if you get the parts separately (and if you have the equipment, you can 3D print your own Pi case.)
Other components you'll need:
A USB 3.0+ Solid State Drive. The general recommendation is for a 2 TB drive. The Samsung T5 is an excellent example of one that is known to work well.⚠ Using a SATA SSD with a SATA-to-USB adapter is not recommended because of problems like this. If you go this route, we've included a performance test you can use to check if it will work or not in the Testing the SSD's Performance section.An ethernet cable for internet access. It should be at least Cat 5e rated. Running a node over Wi-Fi is not recommended, but if you have no other option, you can do it instead of using an ethernet cable.A UPS to act as a power source if you ever lose electricity. The Pi really doesn't draw much power, so even a small UPS will last for a while, but generally the bigger, the better. Go with as big of a UPS as you can afford. Also, we recommend you attach your modem, router, and other network equipment to it as well - not much point keeping your Pi alive if your router dies.
Depending on your location, sales, your choice of SSD and UPS, and how many of these things you already have, you're probably going to end up spending around $200 to $500 USD for a complete setup.


Making the Fan Run More Quietly

When you get the fan, by default you're probably going to be instructed to connect it to the 5v GPIO pin, as shown in the picture below. The fan will have a connector with two holes; the black one should go to GND (pin 6), and the red one should go to +5v (pin 4).
However, in our experience, this makes the fan run very loud and fast which isn't really necessary. If you want to make it more quiet while still running cool, try connecting it to the 3.3v pin (Pin 1, the blue one) instead of the 5v pin. This means that on your fan, the black point will go to GND (pin 6) still, but now the red point will go to +3.3v (pin 1).
If your fan has a connector where the two holes are side by side and you can't split them apart, you can put some jumpers like this in between it and the GPIO pins on the Pi.


Installing the Operating System

There are a few varieties of Linux OS that support the Raspberry Pi. For this guide, we're going to stick to Ubuntu 20.04. Ubuntu is a tried-and-true OS that's used around the world, and 20.04 is (at the time of this writing) the latest of the Long Term Support (LTS) versions, which means it will keep getting security patches for a very long time. If you'd rather stick with a different flavor of Linux like Raspbian, feel free to follow the existing installation guides for that - just keep in mind that this guide is built for Ubuntu, so not all of the instructions may match your OS.
The fine folks at Canonical have written up a wonderful guide on how to install the Ubuntu Server image onto a Pi.
Follow steps 1 through 4 of the guide above for the Server setup. For the Operating System image, you want to select Ubuntu Server 20.04.2 LTS (RPi 3/4/400) 64-bit server OS with long-term support for arm64 architectures.
If you decide that you want a desktop UI (so you can use a mouse and have windows to drag around), you'll need to follow step 5 as well. We suggest that you don't do this and just stick with the server image, because the desktop UI will add some additional overhead and processing work onto your Pi with relatively little benefit. However, if you're determined to run a desktop, then we recommend choosing the Xubuntu option. It's pretty lightweight on resources and very user friendly.
Once that's complete, you're ready to start preparing Ubuntu to run a Rocket Pool node. You can use the local terminal on it, or you can SSH in from your desktop / laptop as the installation guide suggests. The process will be the same either way, so do whatever's most convenient for you.
If you aren't familiar with ssh, take a look at the Intro to Secure Shell guide.
NOTEAt this point, you should strongly consider configuring your router to make your Pi's IP address static. This means that your Pi will have the same IP address forever, so you can always SSH into it using that IP address. Otherwise, it's possible that your Pi's IP could change at some point, and the above SSH command will no longer work. You'll have to enter your router's configuration to find out what your Pi's new IP address is.Each router is different, so you will need to consult your router's documentation to learn how to assign a static IP address.


Mounting the SSD

As you may have gathered, after following the above installation instructions, the core OS will be running off of the microSD card. That's not nearly large enough or fast enough to hold all of the Execution and Consensus blockchain data, which is where the SSD comes in. To use it, we have to set it up with a file system and mount it to the Pi.


Connecting the SSD to the USB 3.0 Ports

Start by plugging your SSD into one of the Pi's USB 3.0 ports. These are the blue ports, not the black ones:

The black ones are slow USB 2.0 ports; they're only good for accessories like mice and keyboards. If you have your keyboard plugged into the blue ports, take it out and plug it into the black ones now.


Formatting the SSD and Creating a New Partition

WARNINGThis process is going to erase everything on your SSD. If you already have a partition with stuff on it, SKIP THIS STEP because you're about to delete it all! If you've never used this SSD before and it's totally empty, then follow this step.
Run this command to find the location of your disk in the device table:
sudo lshw -C disk
  *-disk
       description: SCSI Disk
       product: Portable SSD T5
       vendor: Samsung
       physical id: 0.0.0
       bus info: [email protected]:0.0.0
       logical name: /dev/sda
       ...
The important thing you need is the logical name: /dev/sda portion, or rather, the /dev/sda part of it. We're going to call this the device location of your SSD. For this guide, we'll just use /dev/sda as the device location - yours will probably be the same, but substitute it with whatever that command shows for the rest of the instructions.
Now that we know the device location, let's format it and make a new partition on it so we can actually use it. Again, these commands will delete whatever's already on the disk!
Create a new partition table:
sudo parted -s /dev/sda mklabel gpt unit GB mkpart primary ext4 0 100%
Format the new partition with the ext4 file system:
sudo mkfs -t ext4 /dev/sda1
Add a label to it (you don't have to do this, but it's fun):
sudo e2label /dev/sda1 "Rocket Drive"
Confirm that this worked by running the command below, which should show output like what you see here:
sudo blkid
...
/dev/sda1: LABEL="Rocket Drive" UUID="1ade40fd-1ea4-4c6e-99ea-ebb804d86266" TYPE="ext4" PARTLABEL="primary" PARTUUID="288bf76b-792c-4e6a-a049-cb6a4d23abc0"
If you see all of that, then you're good. Grab the UUID="..." output and put it somewhere temporarily, because you're going to need it in a minute.


Optimizing the New Partition

Next, let's tune the new filesystem a little to optimize it for validator activity.
By default, ext4 will reserve 5% of its space for system processes. Since we don't need that on the SSD because it just stores the Execution (ETH1) and Consensus (ETH2) chain data, we can disable it:
sudo tune2fs -m 0 /dev/sda1


Mounting and Enabling Automount

In order to use the drive, you have to mount it to the file system. Create a new mount point anywhere you like (we'll use /mnt/rpdata here as an example, feel free to use that):
sudo mkdir /mnt/rpdata
Now, mount the new SSD partition to that folder:
sudo mount /dev/sda1 /mnt/rpdata
After this, the folder /mnt/rpdata will point to the SSD, so anything you write to that folder will live on the SSD. This is where we're going to store the chain data for Execution (ETH1) and Consensus (ETH2).
Now, let's add it to the mounting table so it automatically mounts on startup. Remember the UUID from the blkid command you used earlier? This is where it will come in handy.
sudo nano /etc/fstab
This will open up an interactive file editor, which will look like this to start:
LABEL=writable  /        ext4   defaults        0 0
LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
Use the arrow keys to go down to the bottom line, and add this line to the end:
LABEL=writable  /        ext4   defaults        0 0
LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
UUID=1ade40fd-1ea4-4c6e-99ea-ebb804d86266       /mnt/rpdata     ext4    defaults        0       0
Replace the value in UUID=... with the one from your disk, then press Ctrl+O and Enter to save, then Ctrl+X and Enter to exit. Now the SSD will be automatically mounted when you reboot. Nice!


Testing the SSD's Performance

Before going any further, you should test your SSD's read/write speed and how many I/O requests it can handle per second (IOPS). If your SSD is too slow, then it won't work well for a Rocket Pool node and you're going to end up losing money over time.
To test it, we're going to use a program called fio. Install it like this:
sudo apt install fio
Next, move to your SSD's mount point:
cd /mnt/rpdata
Now, run this command to test the SSD performance:
sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
The output should look like this:
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.16
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=63.9MiB/s,w=20.8MiB/s][r=16.4k,w=5329 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=205075: Mon Feb 15 04:06:35 2021
  read: IOPS=15.7k, BW=61.5MiB/s (64.5MB/s)(3070MiB/49937msec)
   bw (  KiB/s): min=53288, max=66784, per=99.94%, avg=62912.34, stdev=2254.36, samples=99
   iops        : min=13322, max=16696, avg=15728.08, stdev=563.59, samples=99
  write: IOPS=5259, BW=20.5MiB/s (21.5MB/s)(1026MiB/49937msec); 0 zone resets
...
What you care about are the lines starting with read: and write: under the test: line.
Your read should have IOPS of at least 15k and bandwidth (BW) of at least 60 MiB/s.Your write should have IOPS of at least 5000 and bandwidth of at least 20 MiB/s.
Those are the specs from the Samsung T5 that we use, which work very well. We have also tested a slower SSD with read IOPS of 5k and write IOPS of 1k, and it has a very hard time keeping up with the ETH2 chain. If you use an SSD slower than the specs above, just be prepared that you might see a lot of missed attestations. If yours meets or exceeds them, then you're all set and can move on.
NOTEIf your SSD doesn't meet the above specs but it should, you might be able to fix it with a firmware update. For example, this has been experienced by the Rocket Pool community with the Samsung T7. Two of them fresh out of the box only showed 3.5K read IOPS and 1.2K write IOPS. After applying all available firmware updates, the performance was back up to the numbers shown in the above example. Check with your manufacturer's support website for the latest firmware and make sure your drive is up to date - you may have to update the firmware multiple times until there are no more updates left.
Last but not least, remove the test file you just made:
sudo rm /mnt/rpdata/test


Setting up Swap Space

The Pi has 8 GB (or 4 GB if you went that route) of RAM. For our configuration, that will be plenty. Then again, it never hurts to add a little more. What we're going to do now is add what's called swap space. Essentially, it means we're going to use the SSD as "backup RAM" in case something goes horribly, horribly wrong and the Pi runs out of regular RAM. The SSD isn't nearly as fast as the regular RAM, so if it hits the swap space it will slow things down, but it won't completely crash and break everything. Think of this as extra insurance that you'll (most likely) never need.


Creating a Swap File

The first step is to make a new file that will act as your swap space. Decide how much you want to use - a reasonable start would be 8 GB, so you have 8 GB of normal RAM and 8 GB of "backup RAM" for a total of 16 GB. To be super safe, you can make it 24 GB so your system has 8 GB of normal RAM and 24 GB of "backup RAM" for a total of 32 GB, but this is probably overkill. Luckily, since your SSD has 1 or 2 TB of space, allocating 8 to 24 GB for a swapfile is negligible.
For the sake of this walkthrough, let's pick a nice middleground - say, 16 GB of swap space for a total RAM of 24 GB. Just substitute whatever number you want in as we go.
Enter this, which will create a new file called /mnt/rpdata/swapfile and fill it with 16 GB of zeros. To change the amount, just change the number in count=16 to whatever you want. Note that this is going to take a long time, but that's ok.
sudo dd if=/dev/zero of=/mnt/rpdata/swapfile bs=1G count=16 status=progress
Next, set the permissions so only the root user can read or write to it (for security):
sudo chmod 600 /mnt/rpdata/swapfile
Now, mark it as a swap file:
sudo mkswap /mnt/rpdata/swapfile
Next, enable it:
sudo swapon /mnt/rpdata/swapfile
Finally, add it to the mount table so it automatically loads when your Pi reboots:
sudo nano /etc/fstab
Add a new line at the end so that the file looks like this:
LABEL=writable  /        ext4   defaults        0 0
LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
UUID=1ade40fd-1ea4-4c6e-99ea-ebb804d86266       /mnt/rpdata     ext4    defaults        0       0
/mnt/rpdata/swapfile                            none            swap    sw              0       0
Press Ctrl+O and Enter to save, then Ctrl+X and Enter to exit.
To verify that it's active, run these commands:
sudo apt install htop
htop
Your output should look like this at the top:
If the second number in the last row labeled Swp (the one after the /) is non-zero, then you're all set. For example, if it shows 0K / 16.0G then your swap space was activated successfully. If it shows 0K / 0K then it did not work and you'll have to confirm that you entered the previous steps properly.
Press q or F10 to quit out of htop and get back to the terminal.