Weight Setting

How weight setting names the validator process of scoring miners in Bittensor subnets.

Weight setting is the validator process of assigning numerical scores to miners in a Bittensor subnet. Validators observe miner work and submit weights that reflect how well each miner performed the subnet task (Glossary: Validator Weights, Yuma Consensus).

Weight setting is process vocabulary for the evaluation side of subnet consensus. It does not name the emission outcome or the miner incentive that follows from consensus.

Role in Yuma Consensus

Weight setting feeds into Yuma Consensus, which aggregates validator evaluations into miner incentives and validator dividends. Validators set weights; Yuma Consensus processes those weights into consensus scores and emission shares (Yuma Consensus, Glossary: Consensus Score).

This keeps weight setting separate from the consensus calculation itself. Weight setting is the input side; Yuma Consensus is the aggregation and output side.

Validator Weights Vocabulary

Validator weights is the related amount term. Weight setting names the process; validator weights names the submitted numerical scores that result from that process (Glossary: Validator Weights).

A weight-setting statement describes what a validator does. A validator-weights statement describes the values submitted. The distinction keeps process vocabulary separate from amount vocabulary.

Subnet Context

Weight setting is subnet-specific. Each subnet defines what miners produce, and validators in that subnet evaluate the output by setting weights (Understanding Subnets).

This keeps weight setting tied to the subnet’s evaluation context. It is not a network-wide scoring mechanism or a ranking system independent of a particular subnet’s task definition.

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For weight setting, that sequence changes which subnet evaluation context a reader should assume when interpreting validator score submissions.

In localnet, weight-setting flows can be tested in an isolated environment. Localnet validator weights do not represent production consensus outcomes.

On testnet, weight setting can be exercised on a shared non-production network. Testnet consensus results are separate from mainnet subnet state (Yuma Consensus).

On mainnet, weight setting concerns live validator evaluations on the selected netuid that feed Yuma Consensus.

The Bittensor Networks reference separates mainnet, testnet, and localnet. A weight-setting example from one environment should not be read as representing production consensus behavior in another environment.

Relationship to Yuma Consensus

Weight Setting 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, weight setting 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

Weight setting is concept vocabulary for the validator evaluation process in Bittensor subnets. The term should not be read as a miner ranking table, a staking guide, or an emission forecast (Glossary: Validator Weights).

Actual weight values and their emission effects depend on subnet context, validator behavior, and consensus configuration. The concept travels across subnets; observed outcomes belong to specific environments (Bittensor Networks).

Each Setting Produces a Weight Vector

Official Yuma Consensus documentation describes each subnet validator as periodically submitting a vector of weights that ranks the miners that validator has evaluated. Weight setting is the validator-side action that turns observed miner work into that per-validator score set.

The Glossary: Weight Vector names one validator’s structured miner scores. Those individual vectors are combined into the subnet-level Glossary: Weight Matrix, which Yuma Consensus reads as its ranking input. Weight setting therefore describes building one validator’s row in that wider matrix, not the subnet-wide result after aggregation.

Understanding Incentive Mechanisms documentation adds that validators compute weight vectors from miner performance and transmit them to the chain. The chain waits for the latest ranking signals from the subnet’s validators before assembling the matrix for consensus. One validator’s setting step supplies evaluation material; the full matrix appears only after those submissions are gathered across the subnet.

References: Yuma Consensus, Glossary: Weight Matrix

Stake Weight Scales How Much a Setting Counts

Official Yuma Consensus documentation explains that the algorithm combines validator submissions using stake-weighted aggregation rather than treating every setting as one equal vote. When consensus compares weights for a miner, validator stake helps determine how much each submitted score influences the merged result.

Understanding Subnets: Validator stake weight documentation describes validator stake weight as the influence measure used during consensus. The Glossary: Stake Weight defines stake weight as the amount of stake backing a neuron, which affects how strongly that neuron’s validator weights count when those scores are merged with others in the same subnet.

That split keeps evaluation and influence separate in weight-setting vocabulary. Validator weights express what a validator scored about miner work; stake weight expresses how strongly that validator’s setting counts inside the aggregation step that follows submission.

References: Understanding Subnets: Validator stake weight, Glossary: Stake Weight

Weight Setting Follows the Tempo Cycle

Official Understanding Incentive Mechanisms documentation places weight setting inside a recurring evaluation rhythm rather than a one-off snapshot. Validators compute weight vectors from miner performance and transmit them as part of the subnet’s ongoing incentive process.

The Glossary: Tempo defines tempo as the subnet-specific interval over which Yuma Consensus calculates emissions from the latest available ranking weight matrix. Implementation of the Yuma Consensus Epoch documentation states that validator weights are submitted during the preceding tempo, while emission results from the consensus pass are finalized at the end of each tempo period.

Weight setting therefore belongs to a periodic submission window inside subnet timing. Validators may update scores across the tempo, but the miner-facing and validator-facing outcomes tied to those settings are credited when epoch processing completes at the tempo boundary rather than at every intermediate submission moment.

References: Understanding Incentive Mechanisms, Glossary: Tempo

Relationship to Validator Weights

Weight setting and validator weights are related but different subnet evaluation terms. Weight setting names the validator process of submitting miner evaluations for a subnet, while validator weights name the score values validators submit as consensus input (Glossary: Validator Weights, Understanding Incentive Mechanisms).

For readers, weight setting describes when and how validators score miner work inside a subnet tempo window, and validator weights describe the resulting signals Yuma Consensus receives before filtering and aggregation (Yuma Consensus, Glossary: Weight Vector).

A weight-setting schedule or eligibility rule does not by itself report every validator weight value stored for consensus processing on that subnet.

Validator weights can change across a tempo as validators update scores, while weight setting names the broader submission process those updates belong to (Glossary: Tempo).

Official incentive-mechanism documentation keeps submission-process language separate from submitted-weight signal language so readers can follow how evaluations enter Yuma Consensus.

Further Reading

Topics ConsensusSubnets