How Bittensor Subnets Work

Every Bittensor subnet runs the same basic loop: validators ask miners to do something, score how well they did it, and the chain converts those scores into payouts. The specific task changes from subnet to subnet — but the scoring mechanism underneath, Yuma Consensus, is the same everywhere. This is the piece that makes Bittensor's incentive structure work without a central party deciding who gets paid.

If you haven't read Bittensor subnets: the complete guide yet, it's useful context for where this fits in the bigger picture.

The two roles

Miners run the actual work the subnet is built around — serving a model, completing a scrape, returning an inference result, submitting a training checkpoint. They register a hotkey on the subnet and respond to whatever validators send them.

Validators don't do the underlying task. They send test queries (or observe live traffic, depending on the subnet's design), evaluate the responses against some measure of correctness or quality, and submit a weight vector — a ranked score for every miner they evaluated — once per epoch.

A subnet can have anywhere from a handful to hundreds of each. The mix matters: a subnet with many validators independently reaching similar conclusions about miner quality is harder to game than one with only two or three.

Weight vectors become a weight matrix

Every validator on a subnet submits its own weight vector. Stack every validator's vector together and you get a weight matrix — one row per validator, one column per miner. That matrix, along with the amount of stake backing each validator, is the input to Yuma Consensus.

What Yuma Consensus actually computes

Yuma Consensus takes the weight matrix and each validator's stake and produces two things:

1. A consensus score per miner — effectively, what the stake-weighted majority of validators agree that miner is worth, with outlier scores (validators far from the pack) discounted.
2. A trust and incentive score per validator — validators whose scores track the consensus closely earn more; validators who consistently diverge from it (whether from bad evaluation logic, laziness, or attempted collusion) earn less.

This second part is what keeps validators honest without anyone auditing them by hand. A validator can't simply inflate every miner's score to curry favor — doing so moves it further from consensus and directly reduces its own emissions.

Tempo: how often this happens

Each subnet has a tempo — a hyperparameter, set by the subnet owner, that determines how many blocks pass between epochs. The chain-wide default is 360 blocks (roughly 72 minutes at Bittensor's ~12-second block time), and owners can configure it anywhere up to 50,400 blocks (about a week). At the end of every tempo, accumulated block rewards for that subnet are distributed according to the latest Yuma Consensus output.

Why this design matters

The practical effect is that Bittensor doesn't need anyone — not the subnet owner, not the Bittensor Foundation, not a DAO vote — to decide who gets paid inside a subnet. It's computed from validator behavior, checked against itself, and settled on-chain automatically every tempo. That's also why the quality of a subnet's validator set is one of the strongest signals of whether it's healthy — see how to evaluate a Bittensor subnet for how to read that in practice.

It's also why the root network matters at the level above individual subnets: the same Yuma Consensus mechanism that scores miners inside a subnet is used again, one layer up, to score entire subnets against each other.

Related Articles

• Back to the complete Bittensor subnets guide
• A framework for judging whether a subnet is well-run
• How the root network scores subnets the same way subnets score miners
• The different kinds of tasks subnets are built around