Bittensor Miner Setup: From Wallet to Registered UID

What a Bittensor miner actually runs

A Bittensor miner is not a single binary you install and forget. It is a role inside a subnet: you register a hotkey on a subnet, run the subnet's miner code, and respond to the validation traffic that subnet uses to score miners. The chain itself (Finney mainnet) handles identity, stake, and registration; the subnet handles the actual work.

That split matters for setup. You need two things working at the same time:

• A wallet and registration on the Bittensor chain, which requires reliable RPC access to Finney.
• A running miner process for the specific subnet you joined, which requires the subnet's own dependencies, GPU or CPU resources, and often a public IP or reachable endpoint.

Most setup failures come from one of those two halves being under-prepared: either the wallet/registration step is done against an unreliable endpoint, or the miner process is started before the subnet's requirements are understood.

Quick recommendation: public endpoint or dedicated node?

Before you install anything, decide how your miner will talk to the chain. This is the decision that most affects whether your setup stays stable after registration.

If you are still exploring, start with a public endpoint and move up when you notice rate limiting, timeouts, or slow metagraph reads. If you already know you will run miners continuously, plan for a managed or dedicated endpoint from the beginning. OnFinality provides Bittensor Finney RPC over HTTP and WebSocket, and dedicated node options when you need isolated capacity. See Bittensor Finney RPC for endpoint details and RPC pricing for plan options.

Step 1: Install the Bittensor CLI and create wallets

The Bittensor CLI (btcli) is the standard tool for wallet and registration operations. Install it in a Python environment you control, then create a coldkey and a hotkey.

• The coldkey holds your TAO and controls your identity. Keep it offline or on a machine you do not expose.
• The hotkey is used by the miner process to sign. It can live on the miner host.

A typical flow looks like this:

# Install the CLI (version may change; check current docs)
pip install bittensor

# Create a coldkey (secure this machine)
btcli wallet new_coldkey --wallet.name miner_cold

# Create a hotkey for the miner host
btcli wallet new_hotkey --wallet.name miner_cold --wallet.hotkey miner_hot

Record the mnemonic for the coldkey offline. Losing it means losing access to the wallet and any stake attached to it.

Step 2: Point the CLI at a Finney RPC endpoint

The CLI needs to reach Finney mainnet. You can pass a network flag or configure an endpoint. Using a stable, documented endpoint avoids the guesswork of random public nodes.

OnFinality exposes a public Bittensor Finney endpoint over HTTP and WebSocket:

# HTTP endpoint
https://bittensor-finney.api.onfinality.io/public

# WebSocket endpoint
wss://bittensor-finney.api.onfinality.io/public-ws

You can verify connectivity with a simple JSON-RPC call before doing anything that costs TAO:

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

If that returns a block header, your endpoint is reachable. If it times out or returns an error, fix connectivity before continuing. Registration transactions are not something you want to retry blindly.

For production miners, configure the endpoint in your miner's config rather than hardcoding it in scripts, so you can switch endpoints without editing code.

Step 3: Fund the wallet and check balances

Send TAO to your coldkey address. You will need enough for:

• The registration fee (burn cost) on the subnet you are joining.
• A small buffer for transaction fees and any stake you want to add.

Registration cost varies by subnet and changes with demand. Check the current cost before you register rather than assuming a fixed number. You can query balances through the CLI or directly via RPC calls that read account state.

A practical habit: confirm the coldkey balance and the hotkey registration status in one pass before submitting a registration transaction.

Step 4: Choose a subnet and register a UID

Subnets differ enormously in hardware requirements, scoring logic, and competition. Before registering:

• Read the subnet's repository and documentation for hardware and software requirements.
• Check how many UIDs are available and how competitive the subnet is.
• Understand how the subnet scores miners, since that determines whether your setup can earn anything.

Registration itself is a chain transaction that assigns your hotkey a UID on the subnet. Once registered, your miner process can start.

Step 5: Run the miner process

Each subnet ships its own miner. The general pattern is:

1. Clone the subnet repository and install its dependencies.
2. Configure the miner with your wallet name, hotkey name, network endpoint, and any subnet-specific settings.
3. Start the miner and confirm it is producing responses the subnet expects.
4. Monitor logs for errors, missed requests, or scoring drops.

The miner host needs to stay reachable and stable. If your miner goes offline, the subnet may stop scoring it, and recovery is not always instant.

Keeping a miner healthy after registration

Registration is the beginning, not the end. Ongoing operation is where most of the practical work sits:

• Endpoint reliability. If your miner or monitoring scripts poll the chain frequently, a shared public endpoint can become a bottleneck. A managed RPC endpoint or dedicated node gives you a stable URL and isolated capacity. See dedicated nodes if you are running multiple miners or a validator.
• Metagraph and stake reads. Tools that read metagraph data or stake state on a schedule benefit from consistent throughput. Batch reads where possible and avoid tight polling loops.
• Wallet hygiene. Keep the coldkey off the miner host. Use the hotkey for signing only.
• Version tracking. Subnets update their miner code. Pin a known-good version and test upgrades before rolling them out.
• Alerting. Watch for registration loss, repeated RPC errors, and miner process exits. A simple health probe against your RPC endpoint can catch connectivity problems early.

A minimal monitoring probe might look like this:

#!/usr/bin/env bash
# Basic endpoint health check for a Bittensor miner host
ENDPOINT="https://bittensor-finney.api.onfinality.io/public"
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X POST "$ENDPOINT" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"chain_getHeader","params":[]}')
if [ "$RESPONSE" != "200" ]; then
  echo "RPC endpoint unhealthy: $RESPONSE"
fi

Run this on a schedule and alert when it fails. It will not catch every subnet-level problem, but it catches the most common one: losing chain connectivity.

Common failure modes and how to read them

When to move off a public endpoint

Public endpoints are fine for learning and light use. Move to a managed RPC endpoint or dedicated node when:

• You run miners continuously and need predictable access.
• You operate multiple subnets or a validator alongside miners.
• You build tooling that reads chain state on a schedule.
• You have been hitting rate limits or intermittent timeouts.

OnFinality offers Bittensor Finney RPC over HTTP and WebSocket, plus dedicated node options for teams that need isolated capacity. Start with the Bittensor Finney network page, compare RPC pricing, and browse other supported RPC networks if you run infrastructure across chains.

Key Takeaways

• A Bittensor miner setup has two halves: chain-side registration (wallet, TAO, UID) and the subnet's miner process.
• Use a documented Finney RPC endpoint and verify it with a read call before spending TAO on registration.
• Keep the coldkey offline; use the hotkey on the miner host.
• Check current registration cost and subnet requirements before registering.
• Move from a shared public endpoint to a managed RPC endpoint or dedicated node when you run miners continuously or hit rate limits.
• Monitor endpoint health and miner logs; most failures are connectivity or configuration issues.

Frequently Asked Questions

Do I need a dedicated node to run a Bittensor miner?

No. You can start with a shared public RPC endpoint. A dedicated node or managed RPC endpoint becomes worthwhile when you run miners continuously, operate multiple subnets, or need predictable throughput.

How much TAO do I need to register a miner?

Registration cost varies by subnet and changes with demand. Check the current burn cost before registering and keep a small buffer for fees.

Can I run a miner and a validator on the same host?

It is possible, but resource contention is a real risk. If you do, plan for isolated capacity and monitor both processes closely.

What happens if my miner goes offline?

The subnet may stop scoring your miner, and recovery is not always immediate. Keep the host stable and monitor for process exits and connectivity loss.

Which RPC endpoint should I use for Bittensor?

Use a documented Finney endpoint. OnFinality provides HTTP and WebSocket access to Bittensor Finney; see the Bittensor Finney network page for details.