How to run a blockchain validator node: complete guide

Running a Sanect validator means participating in block production for a privacy-first EVM chain, earning staking rewards from both delegation and proposer bonuses, and contributing to the security of the network. This guide covers everything from hardware selection through daily monitoring.

Hardware Requirements

Sanect targets 400ms block times with EVM execution. The hardware floor is meaningfully higher than many Cosmos chains because every block includes EVM state transitions, not just simple token transfers.

• CPU: 8 cores minimum, 16 recommended. Modern x86-64 architecture (AMD EPYC or Intel Xeon). Clock speed matters more than core count for EVM execution — aim for 3.0 GHz+ base clock. ARM is supported but not yet optimized.
• RAM: 32 GB minimum. 64 GB recommended for comfortable operation with a full mempool under load. The EVM state cache benefits significantly from additional memory.
• Storage: 1 TB NVMe SSD minimum. SATA SSDs will work but will become a bottleneck under heavy state access. Plan for growth — a heavily-used EVM chain can accumulate 1 TB+ of state within 12-18 months. RAID-1 recommended for data redundancy.
• Bandwidth: 100 Mbps dedicated, unmetered preferred. Validators exchange consensus messages with the entire active set every 400ms. Burst requirements are modest, but consistent low-latency connectivity is critical. Residential connections with traffic shaping are not suitable.

Software Requirements

• Operating System: Ubuntu 22.04 LTS or 24.04 LTS recommended. Debian 12 also works well. CentOS/RHEL should work but is less tested.
• Go: Version 1.25 or later, with GOTOOLCHAIN=auto set. Required to build sanectd from source.
• sanectd binary: The Sanect chain binary. Built via scripts/fork-cosmos-evm.sh from the cosmos/evm v0.4.1 fork. Pre-built binaries will be provided closer to mainnet.
• Prometheus + Grafana: Strongly recommended for monitoring. Sanect exposes standard CometBFT and Cosmos SDK metrics at port 26660.

Network Configuration

The following ports must be open for validator operation:

• 26656 (TCP): CometBFT P2P. Required for peer discovery and consensus message exchange. Must be reachable from the public internet.
• 8545 (TCP): EVM JSON-RPC. Required if you are serving RPC to users. Can be restricted to trusted IPs if you are a pure validator.
• 1317 (TCP): Cosmos REST API. Required for Cosmos SDK queries. Can be restricted to trusted IPs.
• 26657 (TCP): CometBFT RPC. Used internally and for monitoring tools. Should be restricted to localhost or monitoring infrastructure.

Step-by-Step Setup

Step 1: Initialize the Node

After building and installing sanectd, initialize the node with your chosen moniker. This generates your consensus key — a unique identity for your validator in the CometBFT protocol.

sanectd init YOUR-MONIKER --chain-id sanect_7628-1 --home /data/.sanectd

Important: the generated priv_validator_key.json at /data/.sanectd/config/ is your consensus key. Back it up securely. If you lose it, your validator cannot sign blocks. If it is stolen, an attacker can double-sign and cause your validator to be slashed.

Step 2: Add a Key

Add a wallet key to the node's keyring. This is the Cosmos-side address that will hold your validator's self-delegation and receive commission rewards.

sanectd keys add validator-key --home /data/.sanectd

Step 3: Fund the Validator Address

You need at least 1000 SNCT for the minimum self-delegation on mainnet (100 SNCT on testnet). Convert the bech32 snct... address output by sanectd keys show to the EVM 0x... format using the bech32 precompile, or simply note both formats. On testnet, use the faucet in the staking dApp to fund your address.

Step 4: Register via the Staking dApp

Registration is done through the Sanect staking dApp at app.sanect.com, not via CLI. Connect MetaMask with the wallet that will serve as your operator key, navigate to "Register as validator," fill in your moniker, commission rate, and consensus public key (from sanectd cometbft show-validator), and submit. This calls the staking precompile's createValidator function with ~1.5M gas.

Step 5: Monitor Your Validator

After registration, verify your validator appears in the active set (if you have sufficient stake for the top 50) using the staking dApp's validator table. Monitor for missed blocks — each missed block in the 10,000-block window counts against your uptime record.

Commission Rates and Economics

Commission is the percentage of delegator rewards you retain as the validator operator. Typical ranges run from 1% (highly competitive, low margin) to 10% (standard for professional operators). When you register, you also set a maximum commission (cannot be raised above this later) and a max daily change rate (how much you can adjust commission per day).

Validator economics come from two sources: commission on delegator rewards (proportional to your total delegated stake) and proposer bonuses (~5% of block rewards) when your validator is chosen as proposer. At target load and typical inflation parameters, well-staked validators with 10% commission can expect meaningful yield — detailed numbers depend on total network stake.

Uptime Requirements and Jailing

Sanect's slashing parameters are designed to be operator-friendly while still enforcing meaningful participation. The signed blocks window is 10,000 blocks — at 400ms block time, this is approximately one hour. You must sign at least 50% of blocks in any 10,000-block window. Missing more than 5,000 consecutive blocks will get your validator jailed.

The 50% floor means a normal planned maintenance window (stopping the node for 15-20 minutes for an upgrade) will consume roughly 2,250-3,000 of your 5,000-miss budget — leaving meaningful headroom. An emergency restart after a crash should similarly be safe within the window.

When jailed, your validator stops earning rewards and your delegators receive nothing until you unjail. Use the staking dApp's Unjail button (calls the slashing precompile at 0x...0806) after the 600-second minimum wait to return to active status.

What Causes Jailing — And How to Avoid It

• Extended outage. The most common cause. Set up monitoring (see below) and alerts that page you if the node stops signing for more than 5 minutes.
• Running duplicate validators. If you accidentally run two nodes with the same consensus key, CometBFT will detect the double-sign and apply a 5% slash — a much more severe penalty than downtime. Never copy a node's data directory to create a second node. Always sanectd init from scratch.
• Disk full. A disk full node will stop writing state and halt. Monitor disk usage and set alerts at 80% capacity.
• Clock drift. CometBFT is sensitive to time accuracy. Use NTP (chrony or ntpd) and monitor that your system clock stays within a few hundred milliseconds of UTC.

Monitoring Setup

Enable Prometheus metrics in your CometBFT config (prometheus = true under [instrumentation]). Key metrics to track:

• cometbft_consensus_height: should increase every 400ms. A stall here means your node has stopped participating in consensus.
• cometbft_consensus_rounds: normally 0 or 1. Elevated values indicate network issues or a slow validator causing timeout escalation.
• cometbft_p2p_peers: should stay above 5-10. A sudden drop to 0 means your P2P port is unreachable.
• process_resident_memory_bytes: watch for memory leaks — a slow upward trend that never plateaus can indicate a problem needing a restart.

Set up log watching with journald or your preferred log system to alert on ERR and panic strings in the sanectd output. Most serious issues log at error level before the process crashes.