Max Validators
Max validators is a per-subnet hyperparameter that sets the maximum number of validators a subnet allows. Official documentation describes it as the maximum validators on a subnet, making it a cap on how many neurons can act as validators there at once.
References: Subnet Hyperparameters
What It Controls
The hyperparameter bounds the size of a subnet’s validator set. A subnet can hold many registered neurons, but only up to this maximum may serve as validators at the same time. It does not decide which specific neurons validate; it only sets the ceiling on how many can.
Reference: Subnet Hyperparameters
Default and Setting
The documentation lists a default of 64 and marks the parameter as set at the root level rather than by the subnet owner. The value actually in force is per-subnet chain state and can differ from the documented default, so a subnet’s real cap should be read for that subnet.
Reference: Subnet Hyperparameters
Subnet Context
Max validators is one of the subnet hyperparameters, the on-chain state variables that configure a single subnet, for example netuid 1. Because each subnet carries its own hyperparameters, the validator cap is defined per subnet and applies only within that subnet.
Reference: Subnet Hyperparameters
Relationship to Validator Permits
Validator status on a subnet is granted through validator permits, which go to the higher-stake neurons. The maximum-validators cap bounds how many of those permits can exist at once: it sets the ceiling that the permit system fills, so it connects directly to how many neurons end up validating on the subnet.
References: Subnet Hyperparameters, Validator Permit
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For max validators, that sequence changes how readers should interpret validator-cap and permit examples.
In localnet, max-validators hyperparameters can be tested in an isolated environment. Localnet validator caps do not represent production subnet limits.
On testnet, validator permit rules can be exercised in a shared non-production network. Testnet validator caps are separate from mainnet subnet state.
On mainnet, max validators is a live per-subnet hyperparameter on production subnets. Observed validator caps depend on the selected subnet’s on-chain hyperparameter state (Subnet Hyperparameters).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A max-validators example from one environment should not be read as representing production validator limits in another environment.
Relationship to Yuma Consensus
Max Validators 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, max Validators 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 max-validators value set on any particular subnet or which neurons currently hold validator permits. Those are live chain state and should be checked for the relevant netuid. The default of 64 is the documented value, and the parameter is governed at the root level.
Reference: Subnet Hyperparameters
Permits Go to Top Stake-Weight Neurons Up to K
The Glossary: Validator Permit states that validator permits are awarded to the top K neurons by stake weight and are required for setting weights and participating in consensus. Max validators names that K ceiling on a subnet such as netuid 1.
The hyperparameter therefore bounds how many permit flags can be true at once. It does not pick specific UIDs; stake-weight ranking fills the available permit slots up to the configured maximum.
Registration Count Can Exceed the Validator Cap
A subnet can register more neurons than its max-validators setting allows. The hyperparameter caps how many of those registered participants may act as validators at the same time, not how many UIDs the subnet can hold overall (Subnet Hyperparameters).
That split keeps slot limits separate from validation rights. Many neurons may remain registered while only the permitted subset submits validator weights under the cap.
Metagraph Exposes validator_permit Flags
The Subnet Metagraph documentation lists
validator_permit as a boolean array showing whether each neuron has validator permits to set
weights and participate in consensus. Reading permit state for netuid 1 therefore uses metagraph
snapshot fields rather than the hyperparameter name alone.
The boolean array describes chain-recorded permit status at one block height. The max-validators hyperparameter describes the configured ceiling those flags cannot exceed.