> For the complete documentation index, see [llms.txt](https://docs.soniclabs.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.soniclabs.com/sonic/node-deployment/validator-node.md).

# Validator Node

Validator nodes are critical to the Sonic chain, responsible for validating transactions and creating new blocks in accordance with the [consensus protocol](/technology/consensus.md). These nodes ensure the integrity and security of the network by verifying data, participating in block creation, and maintaining the chain’s state.

Unlike [archive nodes](/sonic/node-deployment/archive-node.md), validator nodes focus on real-time operations rather than storing extensive historical data or responding to general API requests.

To run a validator node on the Sonic mainnet or testnet, follow the steps below.

## Steps to Run a Validator

1. [Launch a Server Instance](#id-1.-launch-a-server-instance)
2. [Install Required Development Tools](#id-2.-install-required-development-tools)
3. [Build the Sonic Node Software](#id-3.-build-the-sonic-node-software)
4. [Prime the Sonic Database](#id-4.-prime-the-sonic-database)
5. [Synchronize With the Network](#id-5.-synchronize-with-the-network)
6. [Create a Validator Wallet](#id-6.-create-a-validator-wallet)
7. [Create a Validator Signing Key](#id-7.-create-a-validator-signing-key)
8. [Register Your Validator](#id-8.-register-your-validator)
9. [Run Your Validator Node](#id-9.-run-your-validator-node)
10. [Validator Name and Logo](#id-10.-validator-name-and-logo)
11. [Next Steps](#id-11.-next-steps)

{% tabs %}
{% tab title="Validator Parameters" %}

* Minimum self-stake amount: 500,000 S
* Maximum validator size: 16x self-stake
* Rewards: \~3.5% APR target (at 50% network staking rate), plus 15% of delegators' rewards and network fees

{% hint style="info" %}
The minimum self-stake on Sonic is set at 500,000 S to ensure security during the network's early months, with plans to gradually reduce it.
{% endhint %}
{% endtab %}

{% tab title="Network Resources" %}

* Mainnet RPC: [https://rpc.soniclabs.com](https://rpc.soniclabs.com/)
* Testnet RPC: [https://rpc.testnet.soniclabs.com](https://rpc.testnet.soniclabs.com/)
* WebSocket Endpoint: wss\://rpc.soniclabs.com
* Mainnet Explorer: [https://sonicscan.org](https://sonicscan.org/)
* Testnet Explorer: [https://testnet.sonicscan.org](https://testnet.sonicscan.org/)
* SFC Contract Address: [0xFC00FACE00000000000000000000000000000000](https://sonicscan.org/address/0xFC00FACE00000000000000000000000000000000)
* STI Contract (Validators' Information): [0xFf4cD89f549432c312c497628748d4d76AC180f6](https://sonicscan.org/address/0xFf4cD89f549432c312c497628748d4d76AC180f6)
* Genesis Files: [https://genesis.soniclabs.com](https://genesis.soniclabs.com/)
  {% endtab %}
  {% endtabs %}

## 1. Launch a Server Instance

You can run your validator node on dedicated hardware (bare metal) or use a cloud provider. We recommend choosing one of the established providers, such as Google GCP or Amazon AWS.

### Node Hardware Specifications

* At least 4 vCPUs
* We recommend 32 GB of RAM for the best performance and stability
* At least 1 Gbps redundant backbone connectivity for stable and uninterrupted network traffic
* At least 1 TB of local SSD/NVMe storage. Remote block devices (e.g., AWS EBS) typically do not provide the required latency and random access performance. Google GCP N2D instances with local SSD or AWS i3en.xlarge with instance storage are good options.
* Ubuntu 24.04 LTS Server (64-bit) is recommended. Other current LTS releases also work; see [supported systems](/sonic/node-deployment/node-hardening/before-you-start.md).

### Required Storage Capacity

* ≈1 TB of local SSD/NVMe is sufficient for a validator state database.

### Network Settings

A Sonic node requires both **TCP** and **UDP** network traffic allowed on port 5050 by default. You can use `--port <port>` to customize this if needed.

{% hint style="warning" %}
Don't enable RPC (`--http`, `--ws`) on a validator. If you need RPC, run it on a separate [archive node](/sonic/node-deployment/archive-node.md). Secure the validator with [Node Hardening](/sonic/node-deployment/node-hardening.md), starting with its [Tier 1](/sonic/node-deployment/node-hardening/tier-1-essentials.md) basics before the server holds any keys.
{% endhint %}

## 2. Install Required Development Tools

You need the essential build tools and the latest Go compiler, version [1.26 or newer](https://go.dev/dl/), to build the Sonic client and its bundled tools. Example (Ubuntu/Debian):

```bash
sudo apt-get update
sudo apt-get install -y build-essential git
```

Install Go language compiler (Ubuntu/Debian):

```bash
sudo rm -rf /usr/local/go
wget https://go.dev/dl/go1.26.4.linux-amd64.tar.gz
sudo tar -xzf go1.26.4.linux-amd64.tar.gz -C /usr/local/
rm -f go1.26.4.linux-amd64.tar.gz

sudo tee /etc/profile.d/golang.sh > /dev/null <<EOT
export GOROOT=/usr/local/go
export GOPATH=\$HOME/go
export PATH=\$PATH:\$GOROOT/bin:\$GOPATH/bin
EOT

source /etc/profile.d/golang.sh
```

## 3. Build the Sonic Node Software

Check the [latest Sonic release](https://github.com/0xsoniclabs/sonic/releases) and adjust commands if necessary:

```bash
git clone https://github.com/0xsoniclabs/sonic.git
cd sonic
git fetch --tags && git checkout -b v2.2.5 tags/v2.2.5
make all
```

You can confirm the Sonic release by running:

```bash
build/sonicd version
```

Optionally, install the binaries to a system-wide location. `install` makes them belong to `root`, so the node itself can't modify them:

```bash
sudo install -o root -g root -m 0755 build/sonic* /usr/local/bin/
```

## 4. Prime the Sonic Database

To participate in the Sonic network, you need a valid state database. The fastest way is to use a genesis file from the official repository. Download the [appropriate genesis file](https://genesis.soniclabs.com). For the mainnet, for example:

```bash
curl -JLO https://genesis.soniclabs.com/latest-sonic-pruned.g
```

Use `sonictool` to prime the state database. Adjust `GOMEMLIMIT` and `--cache` according to your available RAM size. For the most common cases, use 12GiB as `--cache` and \~90% of RAM as `GOMEMLIMIT`.

```bash
GOMEMLIMIT=54GiB sonictool --datadir ~/.sonic \
    --cache 12000 genesis \
    --mode validator latest-sonic-pruned.g
```

After processing, you should see a confirmation of a successfully imported state.

## 5. Synchronize With the Network

Now that your database is primed, start the node to synchronize it with the network. Ensure your firewall is configured correctly (see [Tier 1.5](/sonic/node-deployment/node-hardening/tier-1-essentials.md) of Node Hardening).

```bash
GOMEMLIMIT=54GiB sonicd --datadir ~/.sonic --cache 12000 --mode validator
```

The Sonic node will connect to the network and advance its state by processing new blocks. Once fully synchronized, the "age" of new blocks should be only a few seconds.

## 6. Create a Validator Wallet

Your Sonic node is now synchronizing. Next, create a wallet to identify and control your validator account. This wallet must hold the minimum amount you are going to use as the self-stake (500,000 S).

{% hint style="danger" %}
**Keep your wallet and keys secure. Never share them.**&#x20;

This wallet holds your self-stake. We strongly recommend a hardware wallet over a key file: anyone who gets into the machine that stores a key file can copy it and try to guess its password offline, while a hardware wallet never reveals the key and asks you to confirm every transaction on the device.
{% endhint %}

If you create it as a key file instead, do it on a separate, protected machine, not on the validator server ([Node Hardening, Tier 1.7](/sonic/node-deployment/node-hardening/tier-1-essentials.md)). Use `sonictool`:

```bash
sonictool --datadir ~/.sonic account new
```

## 7. Create a Validator Signing Key

A Sonic validator node signs consensus messages. Your node needs a validator signing key to participate. Create it on the server:

```bash
sonictool --datadir ~/.sonic validator new
```

Follow the prompts and set a secure password. Note the public key (starts with 0xc00). This key will be used during registration.

<figure><img src="https://1451584663-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFigzFE2ScpiZHSkLRCev%2Fuploads%2FTgczsxM1oPFp6sejW0Ln%2Fvalidator-pk.png?alt=media&#x26;token=ad907a18-f14e-417a-ad79-a06e551bd11c" alt=""><figcaption></figcaption></figure>

{% hint style="danger" %}
**Back up your signing key.** Although it cannot move funds, misuse could lead to penalties. Keep the backup offline and encrypted.
{% endhint %}

## 8. Register Your Validator

The network must recognize your validator key. Register by invoking the SFC (Staking and Consensus) contract:

* SFC Contract Address: [0xFC00FACE00000000000000000000000000000000](https://sonicscan.org/address/0xFC00FACE00000000000000000000000000000000)

Call `createValidator` with your validator public key and at least the minimum required stake (500,000 S). Sign this transaction with your validator wallet. After confirmation, query your validator ID using the getValidatorID function. The easiest way would be to open the [Sonic explorer](https://sonicscan.org) and navigate to the SFC address.

The contract is validated and you can interact with it using SonicScan and a connected Web3 wallet. The control validator account can be imported into your Web3 wallet either using the generated JSON key store or as your hardware wallet. With the account open, you can sign the `createValidator` transaction call specifying the amount of stake and the public key obtained in the previous step.

<figure><img src="https://1451584663-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFigzFE2ScpiZHSkLRCev%2Fuploads%2F65RxGVz2pK6ygOODyfel%2Fsonicscan-registration.png?alt=media&#x26;token=8de43338-b81c-46ed-9122-e30e1dc19813" alt=""><figcaption></figcaption></figure>

## 9. Run Your Validator Node

Stop the currently running node:

```bash
pkill sonicd
```

Wait for it to gracefully shut down. Never force-terminate it, as it could corrupt the database. Restart your node in validator mode, providing the validator ID, public key, and password file. For example:

```bash
GOMEMLIMIT=50GiB sonicd \
    --datadir ~/.sonic \
    --cache 12000 \
    --mode validator \
    --validator.id <your_validator_ID> \
    --validator.pubkey <your_public_key> \
    --validator.password <path_to_password_file>
```

{% hint style="warning" %}
**This command is only an example.**&#x20;

A node started from a shell runs with the permissions of whoever started it, often `root`, and stops when the session ends. Run your validator as a systemd service under its own user instead.
{% endhint %}

Use the [starter service file](/sonic/node-deployment/node-hardening/appendix-a-starter-service-file.md): its step 2 moves the data folder to `/var/lib/sonic`. Remove the `--http` and `--ws` lines (a validator runs no RPC) and add the validator flags, so that `ExecStart=` looks like this:

```ini
# Replace 203.0.113.10 with the server's public IP address.
ExecStart=/usr/local/bin/sonicd \
    --datadir=/var/lib/sonic \
    --cache=12000 \
    --nat=extip:203.0.113.10 \
    --mode=validator \
    --validator.id=<your_validator_ID> \
    --validator.pubkey=<your_public_key> \
    --validator.password=/etc/sonic/validator-password
```

Also add `LimitCORE=0` to the `[Service]` section: a core dump of a validator would contain its unlocked signing key.

### Validator Key Password

The node needs the password of the validator signing key every time it starts. It reads the first line of the file given in `--validator.password`. Choose how the password gets there:

{% tabs %}
{% tab title="Plain file" %}
The simplest option, and the node restarts on its own. But the password is stored on the same disk as the encrypted key: anyone with a copy of the disk (a snapshot or a backup) or with the node user's access to files has both.

Create the file so that only `root` can change it and only the node can read it, and type the password without it showing on screen or in your shell history:

```bash
sudo install -D -m 0440 -o root -g sonic /dev/null /etc/sonic/validator-password
sudo sh -c 'systemd-ask-password "Validator key password:" > /etc/sonic/validator-password'
```

In the service file: `--validator.password=/etc/sonic/validator-password`.
{% endtab %}

{% tab title="Named pipe (FIFO)" %}
The password is never stored on the server. At every start, the node waits until an operator sends the password through a named pipe. The tradeoff is availability: after a reboot, a crash or an upgrade, the validator stays offline until someone sends the password, so make sure [alerts](/sonic/node-deployment/node-hardening/tier-3-get-alerted.md) about the node reach a person.

Have systemd create the pipe at every boot, in `/run`, which lives in memory:

```bash
echo 'p /run/sonic-validator-password 0600 sonic sonic -' | sudo tee /etc/tmpfiles.d/sonic-validator-password.conf
sudo systemd-tmpfiles --create /etc/tmpfiles.d/sonic-validator-password.conf
```

In the service file: `--validator.password=/run/sonic-validator-password`.

Install a small helper that sends the password into the pipe:

```bash
sudo tee /usr/local/sbin/sonic-unlock > /dev/null <<'EOF'
#!/bin/bash
# Sends the validator key password to a waiting sonicd. Nothing is written to disk.
PIPE=/run/sonic-validator-password
[ -p "$PIPE" ] || { echo "$PIPE is missing or isn't a named pipe: nothing sent." >&2; exit 1; }
read -rsp "Validator key password: " PASSWORD || exit 1; echo
echo "Waiting for the node to read it (up to 2 minutes)..."
printf '%s\n' "$PASSWORD" | timeout 120 tee "$PIPE" > /dev/null \
  || { echo "The node didn't read the password: nothing sent. Is the service running?" >&2; exit 1; }
echo "Password sent."
EOF
sudo chmod 0700 /usr/local/sbin/sonic-unlock
```

After every start of the service, run `sudo sonic-unlock`. While the node waits, its log shows `Reading validator password from file...`, and `systemctl status sonic` still reports it as running.
{% endtab %}

{% tab title="Encrypted credential" %}
Needs systemd 250 or newer (e.g. Ubuntu 24.04; Ubuntu 22.04 is too old). systemd stores the password encrypted and decrypts it for the node when it starts, so the node still restarts on its own. Root on the server can still decrypt it, so this protects copies of the disk, not the running server. If the server has a TPM2 chip (many cloud providers offer a virtual one), the encryption is bound to it, and a copy of the disk is useless on any other machine. Without a TPM2 chip, the decryption key is stored on the same disk, so this protects little more than a plain file.

```bash
sudo install -d -m 0700 /etc/credstore.encrypted
sudo sh -c 'systemd-ask-password "Validator key password:" | systemd-creds encrypt --name=validator-password - /etc/credstore.encrypted/validator-password'
```

In the service file, add this line to the `[Service]` section:

```ini
LoadCredentialEncrypted=validator-password:/etc/credstore.encrypted/validator-password
```

and use `--validator.password=${CREDENTIALS_DIRECTORY}/validator-password`.
{% endtab %}
{% endtabs %}

Once the node has read the password, check that it unlocked the key:

```bash
sudo journalctl -u sonic -g 'Unlocked validator key'
```

If the line is missing, the password was wrong: correct it, restart the service (`sudo systemctl restart sonic`), and with a named pipe, send it again.

Your validator node will now participate in consensus and produce blocks.

{% hint style="info" %}
**Harden the server, too.** Work through [Node Hardening](/sonic/node-deployment/node-hardening.md): for a validator.&#x20;

Tiers 1, 2 and 3 are required, and Tier 5 and the network rules in Tier 4.3 are strongly recommended. Each tier has notes for validators. The validator signing key is the only key that belongs on the server.&#x20;

Try each change on a node that isn't validating first, never on a second node with the same signing key.
{% endhint %}

## 10. Validator Name and Logo

Create a config file in `JSON` format that contains the following parameters (you can also leave parameters empty):

```json
{
  "name": "VALIDATOR_NAME", /* Name of the validator */
  "logoUrl": "LOGO_URL", /* Validator logo (PNG|JPEG|SVG 100x100) starting https:// */
  "website": "WEBSITE_URL", /* Website icon on the right */
  "contact": "CONTACT_URL" /* Contact icon on the right */
}

/* It could look something like this 👇 */

{
  "name": "SonicLabs",
  "logoUrl": "https://repository.sonic.soniclabs.com/validator/sonic.svg",
  "website": "https://www.soniclabs.com",
  "contact": "https://www.soniclabs.com/contact"
}
```

Host it somewhere so it is publicly accessible, such as in [this example](https://repository.sonic.soniclabs.com/validator/soniclabs.json). Make sure anybody can download the JSON file using a browser and that the hosting site supports HTTPS. A 100x100 logo size is sufficient.

Now you need to insert the JSON URL into the STI contract.

1. Go to [SonicScan](https://sonicscan.org/) and open the [STI contract](https://sonicscan.org/address/0xFf4cD89f549432c312c497628748d4d76AC180f6#writeContract).
2. Hit *Contract* -> *Write Contract*.
3. Find the function *updateInfo* and paste the JSON URL.
4. Connect using your validator account Web3 wallet (the one you used to register).
5. Sign and execute the update.

<figure><img src="https://1451584663-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFigzFE2ScpiZHSkLRCev%2Fuploads%2F5MiuOlZcvU4HZaDTiyQb%2FSTI.png?alt=media&#x26;token=6d3d23b0-5fe7-4ea1-a4a6-3c861b24e209" alt=""><figcaption></figcaption></figure>

## 11. Next Steps

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th></tr></thead><tbody><tr><td><strong>Validator Name/Logo</strong></td><td><p>You can set a validator name and logo on the explorer. Check <a href="https://github.com/block42-blockchain-company/fantom-staker-info">official repositories</a> for instructions.</p><p>The STI contract on Sonic: <a href="https://sonicscan.org/address/0xFf4cD89f549432c312c497628748d4d76AC180f6">0xFf4cD89f549432c312c497628748d4d76AC180f6</a></p></td><td></td></tr><tr><td><strong>Community and Help</strong></td><td>Join <a href="https://linktr.ee/soniclabs">Sonic community channels</a>, follow updates, and use your stake to participate in network governance. If you have issues, the community can provide guidance.</td><td></td></tr><tr><td><strong>Monitoring and Health</strong></td><td>If your node goes offline, you stop earning rewards. Extended downtime (e.g. more than 5 days) may result in suspension, requiring you to withdraw and start over. Regular monitoring, maintenance, and backups are essential.</td><td></td></tr></tbody></table>

Congratulations! You are now running a Sonic validator node.