How do I mine Bittensor and keep my miner connected?

Bittensor is not mined with hash power like Bitcoin. Miners on Bittensor run machine-learning workloads — inference, compute, storage, prediction — on a subnet, and validators score their output. The chain then pays rewards in TAO. So "how to mine Bittensor" is really about registering a miner on a subnet, serving useful work at the speed and quality validators expect, and staying connected to the Subtensor chain.

Bittensor mining decision checklist

Before you buy GPUs or pay registration fees, run through this checklist:

• Choose a subnet, then buy hardware. Different subnets need different GPUs, models, and response patterns. Hardware is only useful if it fits a specific subnet's job.
• Budget for registration, stake, and ongoing costs. Registering a miner is an on-chain transaction, and most subnets require you to stake TAO. Check current fees before committing.
• Check validator activity. A subnet with few active validators may produce few requests no matter how well you serve.
• Plan for long-running uptime. Validators score responsiveness over time. Short sessions and interrupted serving hurt more than raw hardware.
• Decide how you will reach the chain. Every registration, weight submission, and reward query is a chain interaction. You need a Subtensor RPC endpoint you can rely on.

How mining on Bittensor works

Bittensor is organized into subnets. Each subnet defines a job: model inference, compute markets, data storage, prediction markets, and others. The network has four main roles:

• Miners produce the commodity, for example serving model predictions or doing computation.
• Validators score miners by querying them and comparing their outputs to ground truth.
• Subnet creators define the incentive mechanism that determines what miners are rewarded for.
• Stakers back validators with TAO, amplifying their influence over scoring.

The Subtensor chain records registrations, stakes, weights, and emissions. TAO is emitted at a predictable, decreasing rate, and the supply is capped. When more miners join a subnet, rewards dilute, so mining on Bittensor is a competitive design problem rather than a pure hardware race.

Step 1: Choose the right subnet

The first decision is not "what GPU do I need?" but "which subnet should I mine?"

Early subnets focused on text and image model inference. Newer ones cover compute markets, storage, prediction, and specialized model families. Each subnet has its own repository, its own miner code, and its own hardware profile. Some subnets can be served by a single consumer GPU; others are dominated by data-center clusters.

Start from the official Bittensor docs, look at the subnet list, and check the distribution of miner hardware and validator activity. A newer subnet usually has less competition, but it also has less demand and a shorter track record. Pick a subnet where you can actually run the reference miner well, then improve from there.

Step 2: Meet hardware and software requirements

There is no single "Bittensor mining rig." Requirements depend on the subnet. Still, most mining setups share a baseline:

• Linux is the practical choice for most miners, and the reference tooling is built for it.
• Python 3.10 or newer for the current Bittensor SDK and CLI. The official docs list the supported range, and the API has changed across major versions, so pin the SDK version your subnet expects.
• A GPU with enough VRAM for the model the subnet serves. Check the subnet's reference miner for minimum specs.
• A static or reachable address. Validators discover miners by peering. If your node is behind NAT or a cloud firewall, requests may never arrive.
• Enough storage and bandwidth for the datasets or responses the subnet requires.

If you are testing with your gaming PC, read the subnet's requirements first. Some low-competition subnets accept consumer GPUs, but the popular inference subnets are effectively a professional hardware market.

Step 3: Install the SDK and register as a miner

The Bittensor SDK ships with a CLI called btcli. It can create wallets, register miners, and submit weights. Setup looks roughly like this:

pip install bittensor

# Create a coldkey (funds) and hotkey (miner identity)
btcli wallet create --wallet-name my_miner

# See available subnets
btcli subnet list

# Register the hotkey on a specific subnet
btcli subnet register --netuid 1

Exact command names and flags change between SDK versions, in particular between v9, v10, and the newer unified SDK. If a command does not exist on your installed version, check the release notes for that version.

Registration requires TAO to pay the registration cost, and your hotkey must be funded for transaction fees. After registration, run the subnet's reference miner. Watch the logs for incoming queries from validators. If you see no queries after several minutes, check networking and registration before assuming the machine is wrong.

Step 4: Connect to Subtensor through an RPC endpoint

"Staying connected" is the part many mining guides skip. Your miner does four things through the Subtensor chain: sees the subnet state, registers, proves liveness, and reports weights. Each of those is an RPC call, and a slow or flaky endpoint stalls the whole miner.

You can verify chain connectivity with a basic JSON-RPC request:

curl -X POST https://your-subtensor-rpc.example \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"chain_getHeader","params":[],"id":1}'

A healthy response returns the chain's latest block height. If the endpoint lags behind, your miner may act on stale state.

For daily mining, weigh your options:

• Public endpoints are free but shared, and they can be congested during registration spikes.
• Managed RPC endpoints remove the operational burden of running your own node. OnFinality provides a Bittensor Finney endpoint alongside other supported chains, so you can point your SDK at a hosted URL. See the list of supported RPC networks and RPC pricing for details.
• Your own node or a dedicated node gives you full control over sync, storage, and access patterns. That is useful when you run many miners or validators and want to separate the chain-access layer from the ML serving layer.

Common pitfalls and how to debug them

I registered but validators never query me. Confirm that your miner is registered on the subnet it is serving, the reference miner is running, and the peer port is reachable from the internet. Then check the subnet's dashboard or validator distribution to see whether validators are actually active.

Registration keeps failing. Check that the hotkey has TAO for fees, you are using the intended chain (Finney vs. a test network), and the endpoint you broadcast to is synced. If a public endpoint is rejecting transactions, switch to a managed Subtensor endpoint.

Rewards are near zero. Rewards depend on scores from validators, competition, and cumulative uptime. Hardware alone rarely wins a mature subnet; miners that tune responses, keep latencies low, and avoid downtimes earn more.

My miner stops after a few hours. Watch memory, disk, and process logs. Many "mining" failures on Bittensor are infrastructure failures: a crashed model process, a full disk, or a lost network path.

Evaluation table: is this subnet worth mining?

Should you run infrastructure or use a managed endpoint?

Mining on Bittensor already means running heavy ML workloads. It usually does not also mean running a Subtensor node. The chain node is a separate service that must stay synced, pruned correctly, and reachable 24/7. For a single miner, that is unnecessary ops work.

When you use a managed RPC service, you separate the two concerns: your GPU serves validators, and a hosted endpoint handles chain state. OnFinality's Bittensor Finney endpoint is built for that pattern, and you can combine it with the supported networks list and RPC pricing to budget the chain-access part of mining. If you later run validators or many miners, move up to a dedicated node so chain load never competes with your serving workload.

Key Takeaways

• Bittensor is not proof-of-work. Miners serve ML workloads and get scored by validators.
• Pick a subnet before buying hardware, and check its real competition and costs.
• Registration requires TAO, a funded hotkey, and a hotkey bound to a subnet.
• A stable Subtensor RPC connection is part of mining. Plan for it the same way you plan for power and cooling.
• Start with a managed endpoint like OnFinality's Bittensor Finney endpoint, then move to a dedicated node when your operation outgrows it.

Frequently Asked Questions

Do I need a GPU to mine Bittensor? Not always. Some subnets reward compute-heavy tasks that need GPUs, while others are based on storage, prediction, or lightweight inference. Check the specific subnet's reference miner.

Is Bittensor mining profitable? It can be, but profitability depends on subnet choice, competition, hardware efficiency, and your ability to tune the miner. Reddit threads on this question often describe long periods without rewards. Treat it as an operating decision, not passive income.

What is the difference between a miner and a validator? Miners produce the work and are scored. Validators send queries, compare responses, and set weights that determine how TAO is distributed.

How much does it cost to register as a Bittensor miner? Registration is priced in TAO and can rise when a subnet is in demand. You also need TAO for transaction fees and typically stake to participate meaningfully.

What is Subtensor? Subtensor is the Bittensor blockchain. It stores registrations, stakes, weights, and emissions, and it is accessed through an RPC endpoint. OnFinality lists a public endpoint on the Bittensor Finney network page.