Mining TAO on Bittensor: How Do You Keep a Miner Registered and Rewarded?

Mining TAO on Bittensor is often described as "mining", but nothing is hashed. There is no proof-of-work puzzle and no GPU race to find a block. A Bittensor miner is a process that registers a hotkey on a subnet, produces whatever output that subnet rewards, and then relies on the chain to score it, weight it, and pay it out in TAO emissions. If you are coming from Bitcoin or Ethereum mining, the mental model is wrong in a way that matters: your bottleneck is rarely raw compute, it is staying registered and getting your weights set on time.

That is why this article treats mining TAO as an operations problem first and a modelling problem second. The model is your business, the chain connection is your uptime.

What actually happens when you "mine" TAO

A Bittensor subnet is a competitive market. Miners submit work, validators score that work, and the chain converts those scores into emissions. Your miner earns TAO when three conditions hold at the same time:

1. Your hotkey is registered on the subnet (you hold a UID).
2. Your miner is responding to validator queries within the subnet's tempo window.
3. Validators are setting weights that reflect your score, and those weights land on chain.

Break any one of those and your emissions go to zero for that tempo. Registration is the part people underestimate. Each subnet has a fixed number of UIDs, so registering means outbidding whoever currently holds the slot you want. If your miner underperforms, you get deregistered and your slot is recycled to a new registrant. Re-registering costs TAO again.

So the real mining loop looks like this: register, run, get scored, set weights, collect emissions, monitor for deregistration, re-register if needed. Everything except the model itself runs over RPC.

Decision guide: own Subtensor node or managed Bittensor RPC?

Before you tune a model, decide how your miner will reach the chain. This is the single choice that most affects whether your miner stays online.

A practical middle path: run a local Subtensor node for development and for reading chain state, and use a managed endpoint as the connection your production miner and validator scripts actually depend on. OnFinality exposes a Bittensor Finney endpoint over both HTTP and WebSocket, which covers the two access patterns miners use most: one-shot extrinsics and subscription-based block watching. See the Bittensor Finney network page for the current endpoint details, and RPC pricing if you want to size cost against your number of hotkeys.

Registration, deregistration, and the calls that matter

Most Bittensor tooling wraps these calls, but knowing them helps you debug. The chain is Subtensor, and it exposes a Substrate-style JSON-RPC interface.

Two failure modes show up constantly. First, nonce collisions: if you fire a registration and a weight-setting extrinsic back to back, they can share a nonce and one is dropped. Second, stale reads: if your endpoint is behind the chain head, you may think you are registered when you are not, or set weights against an old tempo.

Here is a minimal health probe you can run against any Bittensor endpoint before pointing a miner at it:

curl -s -X POST 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 recent block header, the endpoint is reachable and following the chain. Compare the block number against a second source before you trust it for weight-setting.

Wiring a miner to a WebSocket endpoint

Miners and validators that need to act at tempo boundaries should subscribe rather than poll. A WebSocket connection lets you react to new heads as they arrive, which is exactly what you want when a weight-setting window opens.

import { ApiPromise, WsProvider } from "@polkadot/api";

const provider = new WsProvider(
  "wss://bittensor-finney.api.onfinality.io/public-ws"
);

const api = await ApiPromise.create({ provider });

// React to each new block head instead of polling on a timer.
const unsubscribe = await api.rpc.chain.subscribeNewHeads((header) => {
  const blockNumber = header.number.toNumber();
  console.log("new head", blockNumber);

  // Your tempo logic goes here: check UID, check stake,
  // decide whether this is the block to set weights.
});

// Always keep a handle so you can unsubscribe cleanly on shutdown.
process.on("SIGINT", async () => {
  await unsubscribe();
  await api.disconnect();
  process.exit(0);
});

Two operational notes. First, treat the subscription as recoverable: if the socket drops, reconnect with backoff rather than crashing the miner. Second, do not assume one connection is enough for a fleet of hotkeys. A single WebSocket can carry many subscriptions, but a single point of failure is still a single point of failure.

Where miners actually lose emissions

Most "mining TAO" problems are not model problems. They are the following, roughly in order of how often they bite:

• Silent deregistration. Your UID gets recycled and your miner keeps running against a slot it no longer owns. Poll your UID on a schedule and alert on change.
• Weight-setting that never lands. The extrinsic is submitted but not included, often because of a nonce collision or a fee shortfall. Confirm inclusion, not just submission.
• Endpoint drift. Your node or endpoint falls behind the chain head. Weight-setting against a stale view is worse than not setting weights at all.
• Registration cost surprises. Recycle cost moves with demand. Budget for re-registration as a recurring cost, not a one-time fee.
• Key management mistakes. Hotkeys are hot for a reason. Keep coldkeys offline and never let a miner process hold more authority than it needs.

A useful habit is to log, for every tempo, three numbers: your UID, the chain head you acted on, and whether your extrinsic was included. When emissions drop, those three numbers usually tell you which of the failure modes above you hit.

Choosing an endpoint for a production miner

If you are evaluating RPC options for a Bittensor miner, the criteria are narrower than a general dApp checklist. You care about:

OnFinality provides Bittensor Finney access as a managed RPC API, and for teams running many hotkeys or subnets, dedicated node infrastructure removes noisy-neighbour effects and gives you a private endpoint. If you are comparing providers more broadly, the RPC provider selection guide covers the general evaluation framework, and supported RPC networks lists what is available today.

One caution that applies to every provider, including us: do not assume a public endpoint is the right home for a validator's weight-setting path. Public endpoints are shared. If your emissions depend on a specific extrinsic landing in a specific window, size your plan and your failover accordingly.

A realistic first-week plan

If you are starting from zero, a sequence that avoids the common traps:

1. Pick one subnet and read its incentive mechanism before writing any code.
2. Run a local Subtensor node or point a development miner at a managed endpoint to learn the registration flow.
3. Register one hotkey and watch a full tempo cycle without changing anything. Record your UID, your score, and your emissions.
4. Add monitoring for UID changes and chain head freshness before you add a second hotkey.
5. Only then scale to multiple hotkeys, and decide at that point whether shared or dedicated infrastructure fits your risk tolerance.

Step three is the one people skip, and it is the one that teaches you what your subnet actually rewards.

Key Takeaways

• Bittensor mining is registration plus scoring plus weight-setting, not proof-of-work hashing.
• Your emissions depend on staying registered and getting weights set on time; the chain connection is the operational risk.
• HTTP handles extrinsics, WebSocket handles tempo-boundary reactions; production miners usually need both.
• Nonce collisions and stale chain reads are the two most common causes of missed emissions.
• A managed Bittensor RPC endpoint is a reasonable default for production miners; a local node is still useful for development and deep debugging.
• Budget for re-registration as a recurring cost, and monitor your UID as a first-class metric.

Frequently Asked Questions

Is mining TAO the same as Bitcoin mining?

No. There is no proof-of-work. You register a hotkey on a subnet, produce the output that subnet rewards, and validators score it. Emissions follow from scores and weights, not from hash rate.

Do I need to run my own Subtensor node to mine TAO?

Not necessarily. Many miners use a managed RPC endpoint for the chain connection and run only the miner process itself. A local node is still useful for development, backtesting, and debugging when you suspect an endpoint is behind the chain head.

What happens if my miner goes offline?

You stop being scored for that period, and if you underperform long enough you can be deregistered. Re-registering costs TAO, so uptime on the chain connection has a direct cost.

Can I use one RPC endpoint for many hotkeys?

Technically yes, but watch concurrency and rate limits. If your emissions depend on timely weight-setting, consider whether shared access or dedicated infrastructure better matches your risk tolerance.

Where do I find the Bittensor endpoint details?

The current HTTP and WebSocket endpoints for Bittensor Finney are listed on the Bittensor Finney network page. For cost planning across multiple hotkeys, see RPC pricing.