Weight Vector

How a weight vector represents one validator's miner evaluations before subnet consensus.

A weight vector is one validator’s structured set of miner evaluations inside a Bittensor subnet. Each element represents a weight assigned to a subnet miner according to that validator’s evaluation (Glossary: Weight Vector, Yuma Consensus).

The scope is narrow. A single vector is one validator’s signal before aggregation, not the whole subnet result. The individual values inside the set are validator weights (Glossary: Validator Weights, Glossary: Weight Vector).

Per-Validator Signal

A weight vector comes from one validator’s evaluation process. It expresses how that validator scores miners under the relevant subnet task and incentive mechanism (Glossary: Weight Vector, Understanding Incentive Mechanisms).

That keeps the term narrower than final rank or reward allocation. Consensus can use many vectors, but each vector remains a per-validator input.

Yuma Consensus compares many validator signals. One vector expresses one validator’s view; it does not stand in for every validator’s evaluation.

That makes vector language useful when the focus is the validator that supplied the structured evaluation signal.

Task and Mechanism Scope

The meaning of a weight vector depends on the subnet task. The incentive mechanism defines useful work, and the vector records one validator’s evaluation relative to that definition (Understanding Incentive Mechanisms, Glossary: Weight Vector).

This prevents cross-subnet overreach. A vector from one subnet’s task does not automatically describe performance under another subnet’s task or scoring method.

The mechanism supplies the meaning of the entries. Without the subnet task and scoring rules, the vector is only a structure; the incentive mechanism explains what the entries are evaluating.

The same vector shape can appear in different subnet tasks, but interpretation belongs to the task and scoring model that produced the values.

Value, Vector, and Matrix

Weight vector and validator weights describe closely related ideas. The vector is the per-validator structure, while validator weights are the evaluation signals inside that structure (Glossary: Validator Weights, Glossary: Weight Vector).

The useful distinction is scale. Validator-weight language is more precise for an individual score, while weight-vector language is more precise for the whole structured set from one validator.

Weight vector and weight matrix are different levels of the same input vocabulary. A vector belongs to one validator, while the matrix is the subnet-level collection of validator weight vectors (Glossary: Weight Matrix, Glossary: Weight Vector).

This distinction keeps one validator’s view from being mistaken for the combined input set. The matrix vocabulary names the grouped input; vector vocabulary names one validator’s structured evaluation set.

Consensus-based weights documentation uses the broader weight language for validator-submitted signals. The vector term keeps that broader process grounded in one validator’s submitted set (Consensus-Based Weights).

Consensus and Filtering Terms

A weight vector is distinct from consensus score. The vector is an evaluation signal, while consensus score is the stake-weighted benchmark used to filter outlier weights before final rank results (Glossary: Consensus Score, Glossary: Weight Vector).

That makes consensus score downstream of validator weight signals. A vector supplies input; the consensus score helps constrain how those signals can influence the final result.

Rank is downstream as well. A vector supplies one validator’s miner evaluations, while rank is the consensus-adjusted miner-side result after signals are filtered and aggregated (Glossary: Rank, Yuma Consensus).

Submitted vectors are therefore pre-filtering inputs. Consensus score and rank appear after many validator inputs are compared, clipped, and aggregated (Yuma Consensus, Consensus-Based Weights).

Stake Influence

Weight vectors are interpreted inside a stake-weighted consensus process. Stake weight helps determine how much influence a validator’s vector carries during consensus (Glossary: Stake Weight, Glossary: Weight Vector).

This keeps evaluation and influence separate. The vector records miner evaluations; stake weight helps determine how strongly that validator signal is counted.

Stake weight does not replace vector vocabulary. It describes influence around the signal, while the vector describes the structured miner-evaluation input.

That split keeps the value and its influence separate. The vector records evaluations; stake-related terms explain how much effect a validator’s submitted signal can have.

Visibility and Timing

Independent validator evaluation is what gives a weight vector useful information. Weight copying weakens that purpose when validators rely on visible weights instead of fresh evaluation (The Weight Copying Problem, Commit Reveal).

Commit Reveal can add a timing layer by delaying visibility of fresh weight signals. That protects timing around the information, but it does not change the definition of a vector.

Relationship to Yuma Consensus

Weight Vector 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 vector 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 vector names per-validator consensus-input vocabulary. It describes one validator’s structured miner-evaluation set before subnet-level matrix and consensus processing, not stake weight, rank, or a complete reward model (Glossary: Weight Vector, Yuma Consensus).

Specific examples belong to the subnet, mechanism, network, and source that produced the vector. Validator weights, weight matrices, consensus score, rank, and stake weight describe neighboring parts of the same consensus process.

Weight Setting Builds One Validator’s Vector

Official Yuma Consensus documentation describes each subnet validator as periodically submitting a vector of weights that ranks miner work. Weight setting is the validator-side process; the Glossary: Weight Vector names the structured score set that process produces.

That keeps process and structure separate. Weight setting explains what a validator does; a weight vector names the per-validator miner scores that action creates.

set_weights Carries the Vector On Chain

Bittensor documents weight submission as a dispatchable extrinsic call that carries a validator’s weight vector for a subnet. The vector term describes the submitted scores; the extrinsic is how those scores reach chain state for later consensus processing (Glossary: Validator Weights).

Readers should not treat the vector as only an off-chain concept. On-chain submission is what makes one validator’s structured evaluation available to Yuma Consensus.

Vectors Can Rank Only Evaluated Miners

Yuma Consensus states that each validator submits a vector ranking the value of work for each miner that validator has evaluated. A weight vector therefore reflects observed miner work under the subnet task, not an automatic score for every registered UID on the subnet.

That scope keeps vector reading tied to evaluation. The structure holds one validator’s miner judgments, and those judgments apply to miners the validator actually scored.

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For weight vector, that sequence changes how readers should interpret examples tied to subnet state, validator activity, or chain observations.

In localnet, weight vector examples can be tested in an isolated environment. Local chain state reflects local configuration rather than production network behavior.

On testnet, weight vector can be observed in a shared, non-production network. Testnet readings on a selected netuid are separate from mainnet state (Weight Vector).

On mainnet, weight vector applies on the live production Bittensor network for the environment and subnet context being discussed.

The Bittensor Networks reference separates mainnet, testnet, and localnet. A weight vector example from one environment should not be read as representing production behavior on another network.

Further Reading

Topics ConsensusValidation