How to Run a Bittensor Validator

Running your first validator

To run a Bittensor validator, prepare wallet keys and software, register and stake on your chosen subnet, and start its scoring process. Verify that weight submissions reach the chain and monitor uptime, scoring, and transaction errors.

Prerequisites

Before starting, confirm you have: a server meeting the hardware requirements for your chosen subnet (covered in the previous step), a stable high-bandwidth internet connection with reliable uptime, sufficient TAO to meet the subnet’s minimum validator stake, and a clear understanding of the subnet’s scoring criteria. Validators are held to a higher reliability standard than miners — do not begin without confidence in your infrastructure.

Start on testnet first

Bittensor’s test network lets you run through the entire validator setup — key creation, registration, staking, and weight submission — at zero cost and zero risk. Use --subtensor.network test in all btcli commands to work on testnet. This is especially valuable for validators because the consequences of a misconfigured weight-submission pipeline on mainnet include deregistration, not just lost revenue.

Step-by-step setup

Follow these steps in order to go from a fresh machine to a running validator:

Check the SDK version required by your subnet against the official Bittensor CLI reference. For commands from an earlier SDK, use the migration reference to confirm their current names and options.

Create a coldkey and hotkey
Run btcli wallet new_coldkey --wallet.name validator to create your coldkey (the account that holds your staked TAO). Then run btcli wallet new_hotkey --wallet.name validator --wallet.hotkey default to create your hotkey (the identity your validator uses on-chain). Store both mnemonic phrases offline in at least two separate physical locations.
Fund your coldkey with TAO
Validators require significant staked TAO to hold a slot on competitive subnets. Transfer the TAO you intend to self-stake to your coldkey address. View your coldkey address with btcli wallet overview --wallet.name validator. Ensure you hold enough to meet the subnet’s minimum stake requirement plus a buffer for transaction fees.
Install btcli and the Bittensor SDK
Create a Python virtual environment and install the SDK: pip install bittensor. Verify with btcli --version. Also clone the target subnet’s repository and install its dependencies. The subnet README will specify any additional requirements for running the validator process.
Register your hotkey as a validator
Run btcli subnets register --wallet.name validator --wallet.hotkey default --netuid <SUBNET_UID>. This assigns your hotkey a UID on the subnet. For validators, registration is the first step — you then stake TAO to your registered hotkey using btcli stake add --wallet.name validator --wallet.hotkey default --amount <AMOUNT>.
Configure your validation logic
Follow the subnet’s validator README to configure the scoring pipeline. Most subnets provide a default validator implementation. Configure the query frequency, scoring model path (if using a local judge model), and any subnet-specific parameters. Review the scoring criteria carefully — understanding exactly what the subnet rewards is essential for honest, competitive scoring.
Start the validator process
Launch the validator: python neurons/validator.py --wallet.name validator --wallet.hotkey default --netuid <SUBNET_UID> --subtensor.network finney. The validator will begin querying miners and accumulating scores. Use a process manager like pm2 or systemd to ensure the process restarts automatically if it crashes.
Verify weight submission on-chain
After the first epoch completes, verify your validator is submitting weights correctly. Run btcli subnets metagraph --netuid <SUBNET_UID> and find your UID. Check that your validator trust and consensus values are rising. You can also use the chain explorer to inspect the set_weights extrinsics from your hotkey address.

Monitoring your validator

Once live, monitor four key metrics: validator trust (how much the network agrees with your weight submissions), consensus (your alignment with the stake-weighted consensus), dividends (your share of subnet emissions), and uptime (the proportion of epochs in which you successfully submitted weights).

Set up process-level monitoring (systemd service or pm2 with an alerting integration) to catch crashes within minutes. Add network-level monitoring to detect connectivity issues before they accumulate into missed epochs. For validators operating custom scoring models, also monitor GPU utilization and model inference latency to ensure your scoring pipeline keeps pace with the subnet’s epoch timing.

Review your set_weights transaction history in the chain explorer’s extrinsic listing to confirm submissions are landing on-chain at the expected frequency. A gap in weight submissions is often the first visible sign of a problem and catching it early can prevent a deregistration cascade.

Troubleshooting

The most common validator issue is a stalled weight submission: the validator process is running but not successfully submitting to the chain. Check the validator logs for transaction errors — common causes include insufficient TAO for transaction fees, a nonce conflict from another process using the same hotkey, or an RPC connectivity issue to the Finney endpoint.

If your validator trust score is declining despite submitting weights, your scores may be diverging from the network consensus. Review your scoring pipeline for logic errors, stale model weights, or configuration drift. Compare your submitted weights against those of other validators by inspecting the subnet metagraph — a significant divergence from the majority pattern is a signal to investigate your evaluation logic.

The subnet’s Discord or forum is usually the fastest path to subnet-specific troubleshooting help. Most active subnets have a dedicated channel for validator operators, and the subnet developers are typically responsive to configuration questions.