Step 1: Hardware and platform

To get started, all you need is your own staking rig or a hardware solution or a cloud/VPS service. Before getting started, it is crucial to select the platform for running your node. If you are unsure about which platform to choose, you can continue reading to explore different options and gain insights. However, if you have already made a decision, feel free to skip this section and proceed to the next steps.

Step 2: Download Stader node

To manage your node, you will need Stader CLI (command-line interface). Download stader CLI using the commands provided in the below.

wget https://staderlabs.com/eth/releases/stader-node-build/permissionless/v1.4.6/stader-cli-linux-amd64 -O $HOME/stader-cli

Unique checksums for verification and added security a49650d1c6ff312ba0fb50a0d04fd148ac6c090ce3750249103711798114d1a3

Step 2.1 Give permission to run the downloaded application

Run this command

sudo chmod +x $HOME/stader-clisudo mv $HOME/stader-cli /usr/local/bin/

to give permission to run the downloaded application

Step 2.2 Restart the terminal and check the CLI version

After a successful restart of the terminal run the command

stader-cli --version

to verify if the application was downloaded and running perfectly. A perfect download will display the latest CLI version.

Latest CLI version: v1.4.6

After successfully downloading your Stader node, proceed to Step 3 to install the node.

Step 3: Install Stader node

In this step, we will install Stader node on your system. However, before proceeding to install the Stader Node Stack, ensure that Docker is installed on your system.

stader-cli service install

PLEASE CLOSE YOUR TERMINAL AND START AGAIN BEFORE PROCEEDING TO STEP 4: CONFIGURE STADER SERVICES.

Since this is your first time installing Stader, please start a new shell session by logging out and back in or restarting the machine. This is necessary for your user account to have permissions to use Docker.

Step 4: Configure Stader services

Note: Please close your terminal and start again before proceeding to the service config step. Please run the

stader-cli service config

command to launch the configuration manager and proceed with the given configuration steps in the specified order.

Step 4.1 Network selection

Start by selecting the network where you want to set up your node

• Ethereum Mainnet: Ethereum Mainnet is the primary production network of Ethereum. Running a Stader Node takes some know-how and resources, but it also offers significant rewards and benefits for those who contribute to the network’s security and scalability. You will be using real ETH and SD to run a node on Ethereum mainnet. If you’re ready to take on this challenge, Ethereum Mainnet welcomes you!
• Goerli Testnet: Goerli is a test network that provides a secure and zero-cost environment for executing Stader Node operations. By choosing this network, you can create Demo node and validators using testnet ETH and testnet SD. Learn more

Step 4.2 ETH client configuration

Select your preferred method for managing your Execution and Consensus clients.

• Locally Managed: Choose this option If you currently do not manage an ETH client pair, The locally managed option lets the Stader Node take care of your execution and consensus client. Stader node will generate, set up, and manage a pair of Execution and Consensus Clients within Docker containers. Rest assured, you will have the opportunity to select your preferred execution and consensus client.
• Externally managed: Choose this option if you prefer to utilize an existing client that you are already running and managing outside of the Stader node. By choosing this option, the Stader node will establish connections with your pre-existing clients, without deploying its own execution and consensus clients.

Step 4.3 ETH1 – Execution client selection

If you have chosen the “Locally Managed” option during the ETH client configuration step, you can now select an Execution client from the provided options.

• System-recommended: Let Stader node arbitrarily choose from a wide range of network clients. This will enhance the network diversity and resilience of the Ethereum ecosystem.
• Geth: One of the most popular software clients maintained by the Ethereum Foundation, Geth is an open-source CLI developed in the Go Programming Language. It is designed to be flexible and customizable, and it supports a wide range of functionalities such as secure key management, consensus mechanisms, etc. Learn more
• Nethermind: Nethermind is a high-performance Ethereum client built on .NET that offers fast sync speeds and advanced features for developers and end-users. While requiring over 8GB of RAM, it remains a reliable choice for running Ethereum nodes. Learn more
• Besu: Besu, developed by ConsenSys and written in Java, is a comprehensive Ethereum protocol client. It utilizes an innovative storage system called “Bonsai Trees” to store its chain data effectively, enabling it to retrieve historical block states without the need for pruning. Learn more

If you have chosen the “Externally Managed” option during the ETH client configuration step, then just enter the HTTP-based RPC API URL and Websocket-based RPC API URL for your current Execution client.

Step 4.4 ETH2 – Consensus client selection

If you have chosen the “Locally Managed” option during the ETH client configuration step, you can now select a Consensus client from the provided options.

• System-recommended: Let Stader node arbitrarily choose from a wide range of network clients. This will enhance the network diversity and resilience of the Ethereum ecosystem.
• Lighthouse: Lighthouse is a software client for the Ethereum 2.0 blockchain that is developed by Sigma Prime, a blockchain engineering firm based in Australia. It is written in the Rust programming language and is designed to be fast, efficient, and secure. Learn more
• Nimbus: Nimbus is an Ethereum consensus client that prioritizes minimal resource usage, and is written in Nim – a language with Python-like syntax that compiles to C. Its efficiency enables it to perform well on any system. Learn more
• Prysm: Prysm, an Ethereum proof-of-stake client written in Go, is developed by Prysmatic Labs. It prioritizes usability, security, and reliability in the implementation of its consensus protocol. Learn more
• Teku: Teku is an Ethereum consensus client developed by PegaSys, a branch of ConsenSys that focuses on building high-quality clients for Ethereum. Written in Java, Teku offers impressive security and scalability features, although it requires substantial RAM and CPU resources to operate efficiently. Learn more

If you have chosen the “Externally Managed” option during the ETH client configuration step, you can now select a Consensus client from the provided options.

Since each consensus client has its own unique behavior, Stader Node must be informed of the specific client you are using externally. This way, it can adjust its behavior accordingly. Select the consensus client that you are managing externally. If your preferred client is not listed here, it may not be compatible with the Hybrid mode of Stader node.

After choosing the externally managed Consensus client, input the appropriate HTTP URL or JSON RPC URL according to your client selection. Keep in mind that if you are running this client on the same machine as the Stader Node, utilize your machine’s LAN IP address instead of using “localhost” or “127.0.0.1”.

Step 4.5 Add a graffiti

Note: This feature is non-mandatory and is intended purely for fun! If you do not wish to add any graffiti, simply leave it blank.

Step 4.6 Add checkpoint URL

How can I get a checkpoint URL?

To quickly synchronize your node, click on the link below to access the checkpoint URLs. Please make sure to copy the suitable checkpoint URL based on your selected network. If you have chosen Mainnet, copy the URL from the Mainnet section; if you have opted for Goerli, copy the URL from the Goerli section. https://eth-clients.github.io/checkpoint-sync-endpoints/

Adding a checkpoint URL is optional

• Adding a checkpoint URL is not mandatory. If it’s not something you’re interested in, feel free to leave it blank.
• Checkpoint URL is only to sync faster. You can continue even without a checkpoint URL, however, it may take more days to completely sync without a checkpoint

Step 4.7 Enable Doppelganger protection

Doppelganger protection is optional. You can choose Yes or No based on your preference

Step 4.8 Add fallback clients

How to enable fallback client?

• First, click on the “Yes” button

• Then then just enter the Execution client URL or Beacon node HTTP URL or Beacon node JSON RPC URL based on your consensus client preference.

Step 4.9 Enable monitoring

Monitoring feature is optional. You can choose Yes or No based on your preference.

Step 4.10 MEV Boost

Please note that it is mandatory for node operators to choose an MEV option during ETH client configuration. Node operators can select an MEV option provided under locally or externally managed:

• Locally managed: Choose this option if you would like Stader Node to take care of the MEV Boost client for you
• Externally managed: Choose this option if you would like to use an externally managed MEV Boost client.

If you prefer a locally managed MEV Boost:

You can select regulated or unregulated or both types of MEV. Below is the description of regulated and unregulated:

• Regulated: Choose this option to activate relays that adhere to government regulations such as OFAC sanctions. “Regulated (All MEV Types)” permits all forms of MEV, including sandwich attacks. Relays for regulated type MEV: Blocknative, BloXroute regulated, Flashbots and Eden Network.
• Unregulated: Choose this option to activate relays that don’t adhere to any sanctions lists and won’t censor transactions. Unregulated (All MEV Types) permits for all forms of MEV, including sandwich attacks. (except BloXroute ethhical) Relays for unregulated type MEV: BloXroute ethical, Ultra Sound, and bloXroute Max Profit.

If you prefer an externally managed MEV Boost:

Please enter the externally managed MEV Boost client URL, e.g. http://192.168.1.46:18550/

Confirmation and configuration settings

Congratulations! If you’ve finished configuring your node using Stader node configuration manager, you can now click the “Save and exit” button to proceed with the next steps.

Stader node also offers configuration settings TUI, allowing you to review the settings and detailed information for each component you configured in the configuration manager. It even provides additional options that weren’t covered in the configuration manager. If you’d like to go over all the settings and explore these additional options, simply click on the “Review settings” button.

Step 5: Execution and Consensus client sync

Once your Stader node configuration is done, your ETH clients will start syncing. It will take some time to sync the ETH1.0 and ETH2.0 chains. Please wait for the sync completion. You can check the sync status using the command

stader-cli node sync

The screen will display the percentage of sync for ETH1.0 and ETH2.0 nodes. Once the sync is completed, you will get the below output:

Note: Estimated time for Sync is around 3-4 days without a checkpoint URL and around 1-2 day with a checkpoint URL on the Mainnet

Step 6: Wallet setup

Create a wallet

To register your node with the Stader network, you will need to setup a wallet to hold your node account and validator keys. Follow the below steps to setup a wallet.

Start the wallet setup using

stader-cli wallet init

command

Once the wallet setup is initialized it will ask you to setup a password. Please enter the password you wish to use to encrypt your mnemonic phrase.

Please confirm your password you used to encrypt your mnemonic phrase

After this, please enter 24 when the CLI prompts for the number of words in the mnemonic.

Please enter the 24 mnemonic words one-by-one in a sequence for validation

Save your password and mnemonic

“We request that you take note of your password and mnemonic key phrase and store them in a secure location. Please be advised that due to security reasons, the recovery of either the password or the mnemonic phrase is not possible if you lose control of this device or if the node crashes. It is therefore imperative that you safeguard these credentials to avoid any potential loss of access to your node or validator.”

How to know my Operator address?

Once the wallet is setup, you will receive an operator address or you can also check your operator address using

stader-cli wallet status

command.

How to export my private key?

Use the below mentioned command to get the private key of your operator address

stader-cli wallet export

Refer this guide for detailed instructions on how to export the private key and import it to MetaMask – https://staderlabs.notion.site/Stader-ETHx-Export-the-private-key-from-the-stader-node-and-import-it-into-MetaMask-eadc95b6df074480bd06f9dda668ac2f?pvs=4

Note for Testnet users: After setting up the wallet, please share your operator address with our moderators on ETHx Discord to get the testnet SD in your node wallet.

Step 7: Register your node on the Stader network

Check the sync status

Please ensure that you are running the register command only after the Execution and Consensus clients are fully synced. You can check the sync status using

stader-cli node sync

Register your node

To register your node on the Stader network run this command:

stader-cli node register --on <operator name>

Please ensure to replace <operator name> with a name for your node in the command. It will be a variable, you can give any name to your node. e.g. mynode123

NOTE

If you wish to have a separate operator reward address

By default, your operator address and operator reward address will be the same. However, if you wish to specify a different operator reward address, you can utilize the following registration command instead of the one mentioned above:

stader-cli node register --on <operator name> --ora <any valid Ethereum address accessible to you>

This command allows you to set a distinct Ethereum address as your operator reward address during registration.

(You can update your reward address anytime after node registration by following the instructions provided on this page: Click here)

Step 8: Deposit SD collateral

Run the below mentioned command to deposit SD as collateral.

stader-cli node deposit-sd --amount <0.4ETH worth of SD>

Please ensure to replace the placeholder “<0.4ETH worth of SD>” with the specific amount of SD tokens you intend to deposit. The minimum deposit requirement is 0.4ETH worth of SD, while the maximum allowed deposit is 8ETH worth of SD. The exact value will vary dynamically based on the current price of ETH and SD.

To get the amount of SD bond you can:

• Manually calculate 0.4ETH worth of SD amount OR
• Install Grafana dashboard and get the 10% SD bond number. You can install the dashboard by following the steps provided in the Node Monitoring section.

Set spend approval limit for SD deposit

SD Spend approval Limit allows users to set the allowance value in the ETHx Smart Contract for SD token spending, ensuring your control over your assets. It enables users to define a maximum amount of tokens that can be deposited without requiring re-authorization. If you don’t set the SD approval limit, you will have to provide approval every time you deposit SD tokens. To set the SD approval limit, please execute the following command:

stader-cli node approve-sd --amount <SD Amount>

Note: Please ensure to replace <SD Amount> with the desired amount of SD for spending approval.

• SD collateral snapshots are taken daily at a random block. Therefore, if the SD collateral value falls below the 10% limit, the node operator will not earn SD rewards for that day.
• We recommend maintaining an SD collateral buffer (above the 0.4 ETH worth of SD limit) to avoid any reward loss due to price fluctuations.
• You can deposit more than 8ETH worth of SD as collateral, but any SD collateral exceeding the 8ETH limit will not earn SD rewards.
• For SD collateral withdrawal, the node operators can withdraw any collateral exceeding the 200% SD collateral limit (8 ETH worth of SD). To withdraw the entire SD collateral, the node operator will need to exit the validators.
• Before depositing SD collateral, you will first need to give approval to the collateral contract to access your SD token. This approval step will only be done once.

SD token address (Mainnet): 0x30D20208d987713f46DFD34EF128Bb16C404D10f

SD token address (Testnet): 0x0406f539f24Be69baa8b88ED6eABEdb7b3cfdc60

Testnet SD tokens: To receive the Testnet SD tokens for deposit, please visit our Discord ETHx channel and share your Operator Address with our moderators.

Step 9: Deposit ETH bond

Run the below mentioned command to deposit ETH bond and add validators to your node:

stader-cli validator deposit --num-validators <number of validators you wish to add>

Please ensure to replace the placeholder <number of validators you wish to add> with the number of validators you want to add to your node by depositing the ETH bond.

What next?

• We will first deposit 1 ETH and wait for the deposit to be successful. Only 1 ETH is deposited first instead of 4 ETH to avoid front-running of withdraw credentials. It takes 16-24 hours for the 1 ETH to be successfully deposited on the beacon chain
• Once the 1 ETH deposit is successful we will wait for the pre-sign message to be received. This can take a maximum of 24 hours.
• Once the pre-sign message is received and verified we will deposit remaining 31ETH bond for your validator to become active on the beacon chain. After this, Your validator will be in the activation queue on the Beacon chain. Activation time on the beacon chain depends on the the size of the activation queue.
• To check the ETHx validator queue to receive the 28ETH deposit, click here

Validator States

Here are the various validator states throughout the entire validator lifecycle:

1. Initialized – Validator undergoing pre-sign and deposit signature verification. Once approved, Stader completes the remaining ETH deposit and adds the validator to the activation queue.
2. Validator Queued for 28ETH – Approved validator placed in the queue for 28 ETH.
3. Pending Initialized – Validator received 28 ETH and awaiting deposit processing on the beacon chain.
4. Pending Queued – All deposits approved, and the validator is pushed to the beacon chain activation queue.
5. Active and Ongoing – Validator actively attesting.
6. Active and Exiting – Validator broadcasted exit message.
7. Exiting and Unslashed – Unslashed validator pushed to the exit queue.
8. Active and Slashed – Validator remains active but has been slashed.
9. Exiting and Slashed – Slashed validator pushed to the exit queue.
10. Withdraw Possible – Exit withdraw epoch reached, validator awaiting transfer of 32 ETH to the withdraw vault.
11. Withdraw Done – 32 ETH sent to the withdraw vault following validator’s exit.
12. Funds Settled – Validator’s share of 4 ETH sent to the claims vault for withdrawal to their Operator reward address.