Run Validator

Hardware Requirements

Mainnet

Component	Specification
CPU	High-performance server-grade processor (HyperThreading disabled recommended for 10%+ performance gain)
Memory	128 GB RAM
Disk	7 TB NVMe SSD — 40k IOPS, 500 MB/s throughput, read latency < 1ms
Network	≥ 512 Mbps bandwidth

Disk performance is critical. Do not substitute NVMe with standard SSD or HDD — it will negatively impact sync performance and block production.

Testnet

Component	Specification
CPU	AMD Gen 3 or newer / Intel Ice Lake or newer
Memory	16 GB RAM
Disk	1.5 TB SSD — 8k IOPS, 250 MB/s throughput
Network	≥ 128 Mbps bandwidth

---

Setup Validator Node

Step 1 — Install dotOne Full Node

Before running a validator, you must have a dotOne full node installed and synced. Follow the full node installation guide in the Developer section to complete this step first.

---

Step 2 — Prepare Accounts

Two accounts are required before starting a validator:

• Consensus Account — used for block signing and mining

• BLS Vote Account — used for Fast Finality voting

Make sure these accounts match exactly when you register your validator on-chain.

Generate a Consensus Address

Run the following command to create a new consensus account and set a password:

geth account new --datadir ${DATA_DIR}

DATA_DIR is the path where your keystore files will be stored.

If you already have a consensus account, skip this step. Save your password to a file:

echo {your-consensus-account-password} > password.txt

Generate a BLS Vote Address

Run the following to create a new BLS account:

geth bls account new --datadir ${DATA_DIR}

If you already have a BLS key, import it using:

geth bls account import ${KEY_FILE} --datadir ${DATA_DIR}

To verify your BLS address:

geth bls account list --datadir ${DATA_DIR}

Save your BLS password to a file:

echo {your-bls-wallet-password} > blspassword.txt

---

Step 3 — Start the Validator Node

⚠️ Warning: Never expose your RPC endpoints to the public network.

Start your validator with the following command:

geth --config ./config.toml \
  --datadir ./node \
  -unlock {your-consensus-account-address} \
  --miner.etherbase {your-consensus-account-address} \
  --password password.txt \
  --blspassword blspassword.txt \
  --mine \
  --vote \
  --allow-insecure-unlock \
  --cache 18000 \
  --history.transactions 0 \
  --history.logs.disable

---

Post-Launch Operations

Monitor Node Status

It is strongly recommended to monitor your node from the moment it goes live. You can run a metrics exporter via Docker:

docker run -it -d -p 9090:9090 \
  -e "GETH=http://your-node-address:8545" \
  hunterlong/gethexporter

Reference dashboard: Grafana Dashboard #6976

---

Stop and Resume Validating

To stop producing blocks, connect to your node's console and run:

geth attach ipc:path/to/geth.ipc

Then:

miner.stop()

To resume:

miner.start()

---

Tips & Best Practices

Run a Backup Node

Operating a backup node is strongly recommended. If your primary validator encounters issues — hardware failure, connectivity loss, or software errors — a backup node ensures continuity of participation and minimises the risk of downtime slashing.

---

Check Node Stability

Monitor your validator's slash count regularly. Use the slash status utility from the node repository:

cd <dotone>/cmd/jsutils

# Check slashes at the latest block:
node getslashcount.js --Rpc https://rpc.dotone.network

# Check slashes at a specific block number:
node getslashcount.js --Rpc https://rpc.dotone.network --Num {block_number}

A well-operating validator should have zero or near-zero daily slashes. More than three slashes in a single day is a signal to investigate immediately.

---

Maintenance Mode

If your validator accumulates 50 slashes, it will automatically enter maintenance mode. At this point:

1. Diagnose and resolve the underlying issue promptly

2. Exit maintenance mode as soon as your node is stable

3. Failure to exit in time may result in your node being jailed

To exit maintenance mode, send the following transaction from your validator's consensus address:

geth attach geth.ipc

web3.eth.sendTransaction({
  from: "0x{your-consensus-address}",
  to: "0x0000000000000000000000000000000000001000",
  data: "0x04c4fec6"
})

---

Filter Peers by Pattern

In situations where a specific node version has known critical bugs and an immediate network-wide upgrade is not possible, you can disconnect peers running that version by updating your config.toml:

[Node.P2P]
PeerFilterPatterns = ["Geth/v{problematic-version}.*"]

Restart your node after applying the change. This is a temporary measure and should be removed once the network has been upgraded.