Weight Matrix
A weight matrix is the subnet-level collection formed from validator weight vectors. It organizes validator-assigned weight vectors so Yuma Consensus can process them as structured consensus input (Glossary: Weight Matrix, Yuma Consensus).
The term separates one validator’s vector from the combined input set. One vector represents one validator’s relative evaluation of miner work; the matrix is the organized collection of those vectors for the subnet consensus process.
That collection makes the term useful when the subject is subnet-level consensus input. A single validator vector can explain one validator’s view, while the matrix shows the set of validator vectors available for Yuma processing (Glossary: Weight Vector, Yuma Consensus).
Input Collection
Each validator weight vector represents one validator’s relative evaluation of miner work. The weight matrix arranges those vectors together so Yuma Consensus can compare and aggregate validator signals as a group (Glossary: Validator Weights, Glossary: Weight Matrix).
The structure preserves the difference between one validator’s signal and the subnet-level collection. A weight vector carries one evaluator’s miner weights; the matrix is the organized set of those vectors available to the subnet consensus process (Glossary: Weight Vector, Glossary: Weight Matrix).
This makes the matrix an input structure, not a separate scoring rule. It gives the consensus process a common shape for reading many validator weight vectors together.
The practical reading is collection-first: a matrix belongs with the subnet and mechanism whose validators produced the vectors.
Consensus-based weights documentation uses the broader weight language for validator-submitted signals. The matrix term names the subnet-level collection of those validator inputs (Consensus-Based Weights).
That collection still belongs to a selected subnet and mechanism. The same matrix shape can appear across subnets, but the miner work and validator scoring rules give the entries their meaning (Understanding Incentive Mechanisms).
Consensus Processing
Yuma Consensus uses validator signals to produce subnet incentive outcomes. The weight matrix is the organized input to that process; Yuma Consensus is the aggregation process that filters, bonds, and turns those inputs into outcomes (Yuma Consensus, Glossary: Rank).
This keeps matrix language separate from result language. The matrix is the structured input that Yuma processing reads before rank, dividend, and incentive terms become meaningful (Glossary: Rank, Yuma Consensus).
Filtering and Output Terms
The weight matrix and consensus score describe different parts of the same Yuma process. The matrix collects validator weight vectors, while consensus score is the stake-weighted benchmark used to filter outlier weights before final rank calculations (Glossary: Consensus Score, Glossary: Weight Matrix).
That distinction prevents the input collection from being confused with the filtering benchmark. The matrix supplies the set of signals; the consensus score is derived during filtering.
Rank and trust are later consensus terms. Rank names the miner-side result after aggregation, and trust describes how much miner-side support remains after clipping (Glossary: Rank, Glossary: Trust).
Validator trust is also later than the matrix. It measures validator-side influence after consensus filtering, while the matrix names the collection of validator weight vectors before those effects are read (Glossary: Validator Trust, Glossary: Weight Matrix, Yuma Consensus).
This order keeps input and output language plain. The matrix gathers submitted validator vectors; consensus score, rank, trust, and validator trust describe processing results.
That order also explains why matrix examples need the selected subnet. Without the task and mechanism, the matrix only shows the input shape, not what the validator signals evaluated.
Timing and Mechanism Scope
Tempo and Commit Reveal add timing detail around validator weights. Tempo provides the block-based cadence for subnet epochs, while Commit Reveal can delay visibility of newly set validator weights (Glossary: Tempo, Commit Reveal).
Those timing concepts do not replace the matrix. They explain when related validator-weight signals are processed or revealed, while the weight matrix names the structured collection itself.
When a subnet uses multiple incentive mechanisms, each mechanism can have its own weight matrix for independent consensus calculations. The mechanism identifies which evaluation setting the matrix belongs to (Multiple Incentive Mechanisms Within Subnets, Glossary: Multiple Incentive Mechanisms).
Mechanism scope is therefore part of the term. A matrix for one mechanism is still a validator-weight collection, but another mechanism in the same subnet can have a different matrix.
Relationship to Yuma Consensus
Weight Matrix 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 matrix 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 matrix names consensus input terminology. It describes the organized validator-vector collection before Yuma Consensus filtering and aggregation (Glossary: Weight Matrix, Yuma Consensus).
The central point is that the matrix organizes validator weight vectors for consensus. Later results depend on how Yuma Consensus filters and aggregates that organized input.
Yuma Resolves the Matrix Into Emission Shares
Yuma Consensus resolves the matrix of validator rankings into two emissions vectors, one for miners and one for validators. The Glossary: Weight Matrix names the grouped validator inputs; those inputs feed the on-chain step that allocates subnet emissions.
That keeps input and payout vocabulary separate. The matrix is structured consensus input; miner and validator emission shares are among the outputs Yuma produces from that input.
Each Mechanism Can Keep Its Own Matrix
When a subnet runs multiple incentive mechanisms, each mechanism can maintain a separate weight matrix for independent consensus calculations (Multiple Incentive Mechanisms Within Subnets).
Matrix reading therefore needs mechanism context. Two matrices on the same subnet can share a cadence but still represent different evaluation settings rather than one combined input set.
Bond Weights Adjust From Clipped Matrix Values
Yuma Consensus documentation describes bond weights as a blend of a validator’s submitted weight and the consensus benchmark when a submission exceeds that benchmark. Those adjusted values update validator-miner bonds that later factor into validator dividend allocation.
That step sits between raw matrix input and validator-side payout. The matrix gathers submitted weights; clipping and bond adjustment translate those inputs into the bond terms used in validator emissions.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For weight matrix, that sequence changes how readers should interpret grouped validator-vector collections and mechanism-scoped matrix examples.
In localnet, weight-matrix examples can be tested in an isolated environment. Local validator vectors reflect local chain configuration rather than production subnet consensus input.
On testnet, a weight matrix can be observed in a shared, non-production network. Testnet matrix readings on a selected netuid and incentive mechanism are separate from mainnet matrix state (Glossary: Weight Matrix).
On mainnet, a weight matrix describes live grouped validator-weight input for Yuma Consensus on the production Bittensor network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A weight-matrix example from one environment should not be read as representing production consensus input on another network.
Relationship to Validator Trust
Weight matrix and validator trust are related but different Yuma Consensus terms. Weight matrix names the subnet-level collection of validator weight vectors assembled for consensus processing, while validator trust names the validator-side influence measure after those signals are clipped (Glossary: Weight Matrix, Glossary: Validator Trust).
For readers, the weight matrix describes organized consensus input and validator trust describes a validator metric produced after that input is filtered. One is the structured collection submitted toward Yuma Consensus, and the other summarizes how much validator-side influence remains after outlier weights are removed (Yuma Consensus).
A complete weight matrix does not by itself report validator trust readings for individual validators, because validator trust belongs to the post-clipping evaluation layer rather than to the raw matrix layout.
Readers tracing a subnet consensus example should keep matrix-input vocabulary separate from validator-trust outcome vocabulary so each term stays tied to its step in the Yuma process.