Subnet Task

Subnet Task
Context	Subnet incentives
Defines	Miner work
Evaluated by	Validators
Boundary	Not the scoring model

A subnet task is the work target a Bittensor subnet asks miners to perform. It gives the subnet’s incentive design a concrete output to request and evaluate (Glossary: Subnet Task, Understanding Subnets).

The term belongs to subnet design vocabulary. It names the requested work, while protocol, scoring, and consensus vocabulary describe other parts of how that work is exchanged, evaluated, and connected to incentives (Understanding Incentive Mechanisms).

That makes the task the first concept to identify before reading a subnet’s protocol, scoring model, or incentive mechanism. The task says what miners are trying to produce; the surrounding mechanism explains how that work is requested, measured, and rewarded.

Requested Work

The task is the work a subnet is built to request. Subnet documentation describes subnets as markets with their own goals and standards, while the glossary places the subnet task in the work miners perform (Understanding Subnets, Glossary: Subnet Task).

This makes the task the starting point for interpreting the subnet’s purpose. It identifies what kind of useful output is being requested before the reader turns to protocol or scoring details.

The task can be broad or narrow depending on the subnet, but it stays tied to the work target. A claim about a subnet task is clearest when it names the subnet and the work being requested (Understanding Subnets).

Miner and Validator Roles

Miners perform the task, and validators evaluate the returned work against the subnet’s standards (Understanding Subnets, Understanding Incentive Mechanisms).

Those roles keep the task from becoming a generic project description. The task identifies the work target; miner and validator terms identify who produces and evaluates work around that target.

That role split keeps the article centered on work rather than account details. Miners and validators matter here because the task moves through production and evaluation before incentives are assigned.

Protocol Distinction

Subnet task and subnet protocol are related but separate ideas. The task names the requested work, while the protocol names the interaction pattern used to request and return that work (Glossary: Subnet Task, Glossary: Subnet Protocol).

That distinction keeps content and exchange separate. A task can describe the desired output even when the protocol details explain the request and response format around that output.

This is why task language is useful even when protocol details vary. The task remains the requested work target, while the protocol explains how subnet components exchange that work (Glossary: Subnet Protocol).

Scoring Distinction

The subnet scoring model is adjacent but different. The task says what work is being requested, while the scoring model describes how returned work is judged (Glossary: Subnet Scoring Model, Understanding Incentive Mechanisms).

This distinction matters because a task alone does not say whether a particular output was useful. The scoring model supplies the evaluation method that judges returned work against the task.

Task and scoring therefore sit in sequence. The task defines the work target first; the scoring model evaluates whether returned work satisfies that target (Glossary: Subnet Scoring Model).

Incentive Mechanism

A subnet task is one part of a larger incentive mechanism. The incentive mechanism also includes the protocol around the task and the evaluator method that connects performance to incentives (Glossary: Incentive Mechanism, Understanding Incentive Mechanisms).

This keeps the task from carrying the full weight of the incentive system. A task names what is requested; the incentive mechanism explains how requests, scoring, and incentives fit together.

That makes task language narrower than incentive-mechanism language. The task supplies the work target; the mechanism supplies the surrounding evaluation and reward design.

Multiple Mechanism Scope

When multiple incentive mechanisms operate inside a subnet, the mechanism matters for task interpretation. Each mechanism can have its own evaluation system and bond-pool frame (Multiple Incentive Mechanisms Within Subnets, Glossary: Multiple Incentive Mechanisms).

That makes mechanism scope part of a task claim. A task described for one mechanism does not automatically describe every mechanism inside the same subnet.

Relationship to Yuma Consensus

Subnet Task and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).

For readers, subnet task names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.

Reader Boundary

Subnet task is requested-work terminology. It is not the scoring model, the protocol, the consensus result, or a claim that every returned output is useful (Glossary: Subnet Task, Glossary: Subnet Scoring Model, Yuma Consensus).

A subnet task identifies the work miners are asked to produce inside a subnet or mechanism.

Validators Encode Task Performance in Weight Vectors

Yuma Consensus describes validators submitting vectors that rank miner work they have evaluated against the subnet task. Validator weights therefore carry task-performance scores rather than describing the task definition itself (Understanding Incentive Mechanisms).

Subnet task names what miners should produce; validator weights name how returned work was judged relative to that target.

Consensus Turns Task Evaluations Into Incentives

Official incentive-mechanism documentation places task design, protocol, and scoring inside subnet design, then connects validator evaluations to emission outcomes through Yuma Consensus. Miner incentives and validator dividends sit downstream of the task-evaluation path rather than inside the task label itself.

That ordering keeps vocabulary precise. The task defines requested work; consensus and emissions describe how evaluated work is rewarded after many validator signals merge.

Multiple Mechanisms Can Carry Separate Tasks

When a subnet runs multiple incentive mechanisms, each mechanism can maintain independent evaluation tracks with separate weight matrices and bond pools (Multiple Incentive Mechanisms Within Subnets).

Task reading therefore needs mechanism context on those subnets. The same netuid can host more than one work target depending on which incentive mechanism is being discussed.

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For subnet task, that sequence changes how readers should interpret requested-work examples on a selected netuid or incentive mechanism.

In localnet, subnet-task examples can be tested in an isolated environment. Local miner outputs and validator evaluations reflect local chain configuration rather than production subnet task design.

On testnet, a subnet task can be observed in a shared, non-production network. Testnet task descriptions on a selected netuid are separate from mainnet subnet task state (Glossary: Subnet Task).

On mainnet, a subnet task describes live requested work on the production Bittensor network for the subnet or mechanism being discussed.

The Bittensor Networks reference separates mainnet, testnet, and localnet. A subnet-task example from one environment should not be read as representing production task design on another network.