Kappa
Kappa is a per-subnet hyperparameter that sets the consensus majority ratio used by Yuma Consensus. Official documentation describes it as the consensus majority ratio and states that the weights set by validators with lower normalized stake than kappa are not used in calculating consensus.
References: Subnet Hyperparameters
What It Controls
Kappa marks the stake-weighted majority point used when validator weights are combined into a consensus result. Per the documentation, weights coming from validators whose normalized stake falls below kappa do not enter the consensus calculation. In effect, kappa sets how much of the stake-weighted agreement forms consensus and where lower-stake input stops counting.
References: Subnet Hyperparameters, Glossary: Kappa
Default and Representation
The documentation lists kappa as a u16 value with a default of 32767, which is approximately 0.5
once normalized against the maximum of that type. That places the default near the halfway point of
stake-weighted agreement. The value actually in force is per-subnet chain state and can differ from
the documented default.
Reference: Subnet Hyperparameters
Subnet Context
Kappa is one of the subnet hyperparameters, the on-chain state variables that configure a single subnet, for example netuid 1. Unlike hyperparameters a subnet owner can change directly, the documentation marks kappa as a root-level parameter, so it is governed at that level rather than set by ordinary participants.
Reference: Subnet Hyperparameters
Relationship to Consensus
Yuma Consensus aggregates validator weights into a stake-weighted result, and kappa is the majority ratio that aggregation relies on to separate the broad stake-weighted agreement from lower-stake input. This makes kappa a parameter behind the consensus threshold rather than a value assigned to any single validator or miner.
References: Subnet Hyperparameters, Yuma Consensus
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For kappa, that sequence changes how the consensus majority ratio in force should be read, because the value is per-subnet chain state rather than a fixed constant.
In localnet, kappa can be exercised in an isolated environment to observe how the majority ratio filters lower-stake validator weights. A localnet kappa value reflects that test chain state rather than production governance.
On testnet, kappa applies on a shared non-production network where validator stake and weights are separate from mainnet. A testnet kappa reading describes that environment’s chain state.
On mainnet, kappa is the root-level consensus majority ratio governing live subnets such as netuid 1, where the value in force drives real Yuma Consensus outcomes (Subnet Hyperparameters).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A kappa value observed in one environment should not be read as the parameter in force on another.
Relationship to Yuma Consensus
Kappa 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, kappa 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
This page defines the concept at a high level. It does not report the kappa value set on any particular subnet or the current consensus outcome of an epoch. Those are live chain state and should be checked for the relevant netuid. The 32767 figure, about 0.5 normalized, is the documented default, and the parameter is governed at the root level.
Reference: Subnet Hyperparameters
Consensus Clipping Trims Outlying Weights After Aggregation
Yuma Consensus documentation describes consensus clipping as trimming validator weights that depart from the stake-weighted agreement point. Kappa names which stake-weighted validator input counts toward that agreement, while clipping names how far individual weight values can depart before they stop being rewarded.
Those are sequential defenses inside the same epoch. Kappa filters which validator rows participate in the majority calculation on a subnet such as netuid 1, and clipping then punishes inflated ratings that still outlie the resulting agreement (Understanding Incentive Mechanisms).
References: Yuma Consensus, Understanding Incentive Mechanisms
Normalized Stake Ranks Validators Against the Threshold
The Glossary: Kappa ties the parameter
to normalized stake when deciding
whether a validator’s weights enter consensus. Official hyperparameter documentation lists kappa as
a u16 value with a default of 32767, which normalizes to roughly one half of the type’s maximum.
That representation keeps kappa on a stake-ranking scale rather than on a raw neuron count. A validator below the majority ratio stops contributing weight rows to the consensus calculation even if it still holds a validator permit on the subnet.
References: Glossary: Kappa, Subnet Hyperparameters
Root-Level Parameters Differ From Owner-Settable Rules
Subnet hyperparameters split between root-level values and owner-settable values. Kappa is documented at the root level, unlike parameters such as min allowed weights that a subnet owner can raise for a subnet such as netuid 1.
That governance split matters for reading scope. Kappa describes a network-wide consensus threshold pattern applied per subnet, while owner-settable weight-form rules describe how individual subnets shape valid validator submissions without changing the root-level majority ratio itself.
References: Subnet Hyperparameters, Glossary: Kappa