Max Allowed UIDs

Max Allowed UIDs
Parameter	MaxAllowedUids
Type	u16
Default	256
Example	netuid 1
Set by	Subnet owner

Max allowed UIDs is a per-subnet hyperparameter, listed in the documentation as MaxAllowedUids, that sets the maximum number of neurons a subnet can hold. Each registered neuron occupies one UID slot, so this value is the ceiling on how many UIDs can exist on a subnet at once (Subnet Hyperparameters).

What It Controls

The hyperparameter bounds capacity, not behavior. It does not change how a neuron registers, what registration costs, or how rewards are calculated. It only fixes how many UID slots the subnet exposes. Once the subnet holds that many neurons, it is full, and further entry depends on displacement rather than on free space (Glossary: UID Slot).

When every UID is occupied, a new registration displaces the weakest eligible incumbent using documented emissions-based replacement order. Official material still calls that ordering pruning score. Live deregistration compares current emissions, immunity status, and registration-block order on ties rather than relying on a separate maintained pruning-score table alone (Mining: Miner deregistration, Glossary: Pruning Score, Glossary: Immunity Period).

Documented Type, Default, and Setter

The Subnet Hyperparameters reference lists MaxAllowedUids as a u16 with a default of 256 and the description “Maximum number of neurons on a subnet.” It is changed through the sudo_trim_to_max_allowed_uids extrinsic, exposed in tooling as btcli sudo set --param sudo_trim_to_max_allowed_uids and the btcli sudo trim command, and the reference marks the permission required to set it as subnet owner (Subnet Hyperparameters).

The constants reference exposes the startup default as api.consts.subtensorModule.initialMaxAllowedUids, listed as 256. That constant names the initial UID-capacity ceiling used for a subnet, while the live MaxAllowedUids hyperparameter can later change on the selected netuid (Subtensor Constants: initialMaxAllowedUids, Subnet Hyperparameters).

Because it is a trim operation, lowering the cap below the current neuron count removes excess UIDs rather than leaving them in place. The ceiling on netuid 1 can differ from the documented default and from another subnet’s cap (Subnet Hyperparameters).

The constants reference exposes the startup value as api.consts.subtensorModule.initialMaxAllowedUids, listed as 256, which matches the documented default above. That constant names the launch ceiling, while the live MaxAllowedUids storage value is the owner-settable value each subnet uses after launch (Subtensor Constants: initialMaxAllowedUids, Subnet Hyperparameters).

Metagraph Count Shows How Many Slots Are Occupied

The Subnet Metagraph documentation describes the metagraph as the complete subnet state at a block, including all registered neurons. The hyperparameter names the ceiling; the metagraph snapshot names how many slots are occupied at one block height (Subnet Metagraph).

When occupied count reaches the ceiling, further registration depends on displacement rules rather than spare capacity (Mining: Miner deregistration).

Distinction from UID Slot

A UID slot is one participant position inside a subnet. MaxAllowedUids is the hyperparameter ceiling on how many of those slots may exist at once on the selected subnet (Glossary: UID Slot, Subnet Hyperparameters).

UID slot — one occupied neuron position.
MaxAllowedUids — total slot capacity for the subnet.

Distinction from UID Trimming

MaxAllowedUids names the configured population ceiling. UID trimming is the subnet-owner operation that removes low emitters and compresses survivors when the live set must be brought down to a lower target (UID Trimming, Subnet Hyperparameters).

MaxAllowedUids — the configured population ceiling.
UID trimming — the owner operation that compacts the live set down to that ceiling.

Distinction from Pruning Score

MaxAllowedUids sets how many neurons may coexist on a subnet. Pruning score names documented emissions-based displacement vocabulary used when that ceiling is already met (Glossary: Pruning Score, Mining: Miner deregistration).

Live deregistration applies that rule by comparing current emissions, immunity status, and registration-block order on ties rather than relying on a separate maintained pruning-score table alone (Mining: Miner deregistration).

Capacity vocabulary and displacement-ranking vocabulary answer different roster questions. The hyperparameter fixes how many slots exist; pruning score shorthand names which eligible incumbent is weakest once registration pressure forces one slot open (Glossary: UID Slot).

MaxAllowedUids — total neuron population ceiling on the subnet.
Pruning score — shorthand for emissions-based displacement ordering on a full subnet.

Distinction from Max Validators

MaxAllowedUids bounds the total neuron population on a subnet. MaxAllowedValidators bounds how many of those neurons may hold validator permits and submit weights (Subnet Hyperparameters, Glossary: Validator Permit).

MaxAllowedUids — total neuron population ceiling on the subnet.
MaxAllowedValidators — how many of those neurons may hold validator permits.

Distinction from Registration Allowed

Registration allowed is the Boolean switch that decides whether a subnet accepts new registrations. MaxAllowedUids sets how many slots exist when registration is open (Subnet Hyperparameters).

Registration allowed — whether new entry is currently open.
MaxAllowedUids — how many neuron slots the subnet exposes when registration is open.

Distinction from Mechanism Count

MaxAllowedUids sets the ceiling on how many registered neurons a subnet can hold, while mechanism count sets how many incentive mechanisms share that UID population. Official documentation requires that mechanism count multiplied by max allowed UIDs must not exceed 256 (Subnet Hyperparameters, Multiple Incentive Mechanisms Within Subnets).

MaxAllowedUids — the ceiling on registered UID slots in the subnet.
Mechanism count — how many incentive mechanisms run within the product constraint.

Distinction from Multiple Incentive Mechanisms

MaxAllowedUids names the ceiling on registered neurons, while multiple incentive mechanisms names the model in which more than one evaluation path runs inside that shared UID space (Glossary: Multiple Incentive Mechanisms, Multiple Incentive Mechanisms Within Subnets).

MaxAllowedUids — the ceiling on registered UID slots those mechanisms share.
Multiple incentive mechanisms — parallel evaluation paths inside one subnet.

Chain Reads for netuid 1

Readers can verify live hyperparameter values for the documented example netuid with btcli subnet hyperparameters --netuid 1 --network finney (Subnet Hyperparameters: View hyperparameters).

That read path keeps live hyperparameter claims tied to a parseable netuid.

Per-Subnet Live Value Boundary

Max allowed UIDs is per-subnet chain state. The neuron slot ceiling configured on one netuid fixes how many UIDs that subnet can hold at once, but the live cap can differ from the reference default of two hundred fifty-six and from the ceiling on another netuid (Subnet Hyperparameters, Glossary: UID Slot).

This article’s infobox uses netuid 1 as an example label when reading one subnet’s hyperparameter table on Finney mainnet. That example helps readers verify one row; it is not proof that every subnet exposes the same live ceiling (Bittensor Networks).

MaxAllowedUids bounds structural capacity; Yuma Consensus still settles validator weights from registered neurons into emission shares each epoch on the active subnet (Yuma Consensus).

MaxAllowedUids — ceiling on registered neuron slots on a subnet.
Per-subnet boundary — live ceiling is chain state on one netuid.

Distinction from Yuma Consensus

MaxAllowedUids is the per-subnet hyperparameter that caps how many registered UID slots a subnet exposes. It names metagraph roster capacity on the hyperparameter table, not the settlement step that converts validator weight submissions into emission shares (Subnet Hyperparameters, Glossary: UID slot).

Yuma Consensus is the on-chain mechanism that runs at the epoch boundary on the selected netuid. It reads the weight matrix from eligible validators among registered neurons, applies clipping and bonding, and converts the result into miner incentives and validator dividend shares (Yuma Consensus, Emission).

When the ceiling is met, documented displacement rules—compared through emissions standing, immunity status, and registration order—decide which occupant leaves, not Yuma directly. Capacity limits who can hold slots; Yuma settles weight signals from neurons who remain registered on the active metagraph (Glossary: Pruning Score, Glossary: Immunity Period, Yuma Consensus: Validator emissions).

Readers should treat MaxAllowedUids as a roster-size cap on one netuid, and Yuma as the mechanism that allocates rewards from consensus among registered participants.

MaxAllowedUids — ceiling on registered UID slots for one subnet.
Yuma Consensus — epoch-boundary settlement from eligible validator weights to emission shares.

Distinction from Min Allowed Weights

Max allowed UIDs and min allowed weights are different subnet hyperparameters governing different things. Max allowed UIDs caps how many UID slots a subnet can hold, bounding total participants, while min allowed weights sets the minimum number of miners a validator must assign weights to for its weight set to be valid (Subnet Hyperparameters, Glossary: UID Slot, Glossary: Weight Vector).

Subnet hyperparameters documentation validates weight submissions against min allowed weights for UIDs that hold a validator permit. Max allowed UIDs can be full while a permitted validator’s weight vector still fails the minimum-miner check separately (Subnet Hyperparameters: MinAllowedWeights, Glossary: Validator Permit).

When max allowed UIDs is full, a new register extrinsic cannot claim another slot until pruning removes an incumbent; min allowed weights instead governs whether a validator’s submitted weight vector names enough miners to count at epoch settlement—roster capacity and weight validity are separate checks (Subnet Hyperparameters: MaxAllowedUids, Subnet Hyperparameters: MinAllowedWeights, Glossary: Register).

Max allowed UIDs — the cap on a subnet’s UID slots.
Min allowed weights — the minimum number of weights a validator must set.

Reader Boundary

This page defines the concept at a high level. It does not report the live UID ceiling on any particular subnet or how many slots are currently occupied. It should not be read as proof of which incumbent would be displaced, as Yuma rank, or as incentive outcomes on the relevant netuid. Displacement eligibility comes from live emissions, immunity status, and registration order on the relevant netuid at observation time (Glossary: Pruning Score, Mining: Miner deregistration).

Those are on-chain state values that should be checked for the relevant netuid—for example, btcli subnet hyperparameters --netuid 1 --network finney (Subnet Hyperparameters: View hyperparameters). The documented default is 256, the type is u16, and the parameter is set by the subnet owner through a trim extrinsic (Subnet Hyperparameters).