Bittensor Mining Tutorial: How Do You Keep a Miner Registered and Online?

Bittensor mining does not work like Bitcoin or Ethereum mining. There is no hash puzzle to solve. Instead, you register a hotkey on the Subtensor chain, run a miner inside a subnet, and compete on the quality of the responses your model produces. Validators score those responses, and emissions flow to the miners that score well.

That reframes the whole tutorial. The hard part is rarely the model code. The hard part is staying registered, staying synced with the chain, and keeping your miner reachable while validators query it. This page focuses on that operational path and on the RPC layer that holds it together.

Quick recommendation: what to set up first

Before you touch a GPU or clone a subnet repo, decide how you will talk to the chain. Almost every step below depends on a working Subtensor RPC connection.

If you are still deciding whether to self-host, the tradeoffs are similar to other chains. See dedicated nodes for the operational model and RPC pricing for how managed access is billed.

What mining actually means on Bittensor

A subnet defines an incentive mechanism. Miners submit answers, validators rank them, and the chain converts those rankings into emissions. Your job as a miner is to produce the best answers you can, fast enough to be scored.

Three components matter:

• Wallets. You need a coldkey (holds stake and controls the hotkey) and a hotkey (signs miner activity). Keep the coldkey offline.
• Registration. You register the hotkey on a subnet's UID slot. Registration costs TAO and the price rises as slots fill.
• The miner process. This is your model or service, usually started from a subnet repository, pointed at an RPC endpoint and your wallet files.

None of this is hash mining. Emissions depend on subnet scoring, not on compute spent guessing nonces.

Chain settings at a glance

Use these values when configuring a wallet, a Subtensor client, or a monitoring probe.

For a managed endpoint, replace the host with your own keyed URL. The Bittensor Finney network page lists the current endpoint details, and supported RPC networks shows what else OnFinality serves.

Step-by-step: from empty machine to registered miner

1. Install the tooling

Most subnet workflows use the Bittensor Python SDK and a subnet-specific repository. Install the SDK in a virtual environment so subnet dependencies do not collide.

python3 -m venv ~/.bt
source ~/.bt/bin/activate
pip install bittensor
btcli --version

2. Create wallets

Create a coldkey and a hotkey. Store the coldkey mnemonic offline. The hotkey is the identity your miner uses on-chain.

btcli wallet new_coldkey --wallet.name miner
btcli wallet new_hotkey --wallet.name miner --wallet.hotkey default

3. Point the client at an RPC endpoint

This is where most tutorials get vague. Set the endpoint explicitly so every command uses the same chain connection.

export BT_NO_PROMPT=true
btcli subnet list --subtensor.network finney --subtensor.chain_endpoint https://bittensor-finney.api.onfinality.io/public

If you are using a managed endpoint, substitute your keyed URL. Keeping the endpoint in an environment variable avoids drift between registration, metagraph reads, and miner startup.

4. Verify the connection before spending TAO

Do not register blind. Confirm the endpoint responds and returns a current block before you commit funds.

curl -s -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"chain_getHeader","params":[]}' \
  https://bittensor-finney.api.onfinality.io/public

A valid response includes a block header with a recent block number. If it does not, fix connectivity before registering.

5. Register on a subnet

Pick a subnet whose incentive mechanism matches hardware you actually have. Registration cost varies with demand, so check the current price first.

btcli subnet register --netuid <NETUID> \
  --wallet.name miner --wallet.hotkey default \
  --subtensor.chain_endpoint https://bittensor-finney.api.onfinality.io/public

6. Run the miner

Each subnet ships its own miner entrypoint. The pattern is consistent: pass the network, netuid, wallet, and often an axon port so validators can reach you.

python neurons/miner.py \
  --netuid <NETUID> \
  --wallet.name miner \
  --wallet.hotkey default \
  --subtensor.chain_endpoint wss://bittensor-finney.api.onfinality.io/public-ws \
  --axon.port 8091

Use the WebSocket endpoint for long-running miners. It keeps a persistent subscription to new blocks instead of polling, which reduces reconnect churn.

Keeping a miner online without babysitting it

Registration is a one-time cost. Staying registered and responsive is the ongoing job. The failure modes are predictable:

A simple monitoring loop catches most of these early. Probe the endpoint and your miner's health endpoint on a schedule.

while true; do
  curl -sf -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"chain_getHeader","params":[]}' \
    https://bittensor-finney.api.onfinality.io/public \
    > /dev/null && echo "rpc ok $(date -u +%FT%TZ)" || echo "rpc fail $(date -u +%FT%TZ)"
  sleep 60
done

Run the miner itself under systemd or a container restart policy so a crash does not silently cost you emissions.

When to move off the public endpoint

A public endpoint is fine for learning, registration, and occasional reads. It becomes a liability when you run a miner that validators depend on.

Move to a managed or dedicated setup when any of these apply:

• You run more than one miner or subnet and need isolated throughput.
• You need WebSocket subscriptions that stay open for days.
• You need historical or archive queries for tooling.
• You want endpoint health handled for you instead of debugging it at 3am.

OnFinality provides RPC API access and dedicated node infrastructure for Bittensor and other networks. The API service page covers managed endpoints, and dedicated nodes covers isolated deployments. For a broader comparison framework, read how to choose an RPC provider.

Common pitfalls that waste TAO

• Registering before testing the endpoint. A dropped connection during registration wastes the fee.
• Using the coldkey on the miner host. The miner only needs the hotkey. Keep the coldkey offline.
• Ignoring axon reachability. If validators cannot reach your port, your answers never get scored.
• Polling instead of subscribing. Polling a metagraph in a tight loop invites rate pressure and stale reads.
• No restart policy. A crashed miner stops earning until someone notices.
• Choosing a subnet you cannot serve. Match the subnet's task to your actual hardware and skills.

Key Takeaways

• Bittensor mining is subnet scoring, not hash mining. You register a hotkey and compete on response quality.
• Registration, metagraph reads, and weight syncing all depend on a stable Subtensor RPC connection.
• Use the Bittensor Finney HTTP endpoint for setup and the WebSocket endpoint for long-running miners.
• Verify the endpoint returns a current block before spending TAO on registration.
• Run miners under a supervisor and monitor both the RPC endpoint and the axon port.
• Move to a managed or dedicated endpoint when you run production miners that validators depend on.

Frequently Asked Questions

Do I need a GPU to mine Bittensor?

It depends on the subnet. Some subnets are compute-heavy and expect GPUs; others reward data, APIs, or specialized services. Check the subnet's incentive mechanism before buying hardware.

How much TAO does registration cost?

Registration cost is dynamic and rises as subnet slots fill. Check the current price with the CLI before registering rather than assuming a fixed number.

Can I mine Bittensor with a public RPC endpoint?

Yes for learning and registration. For a miner that must stay online and respond to validators continuously, a managed or dedicated endpoint is the more reliable operational choice.

Why does my miner keep getting deregistered?

Usually because it missed blocks while offline or could not be reached. Use a process supervisor, keep the endpoint stable, and confirm your axon port is externally reachable.

Should I use HTTP or WebSocket for the miner?

Use WebSocket for long-running miners so block updates stream in. HTTP is fine for one-off commands like registration and balance checks.

Where do I find the current Bittensor endpoint details?

See the Bittensor Finney network page for endpoint and transport details, and supported RPC networks for other chains.