Mechanism Count
Mechanism count is a per-subnet hyperparameter, listed in the documentation as MechanismCount,
that sets how many incentive mechanisms a subnet runs. The reference describes it as the number of
mechanisms on a subnet and notes that changing it requires keeping the product of mechanism count
and the subnet’s maximum UID count must not exceed 256
(Subnet Hyperparameters).
What It Controls
The hyperparameter sets how many separate incentive mechanisms share a subnet’s emissions. Each mechanism can run its own evaluation context and Yuma Consensus path with separate bond pools, while miners and validators remain registered once for the subnet as a whole (Multiple Incentive Mechanisms Within Subnets).
Mechanism count does not define the tasks inside each mechanism, how validators score miners, or how emissions are split among mechanisms after the count is set. Those belong to incentive-mechanism design and the separate mechanism-emission-split configuration documented for subnet owners (Multiple Incentive Mechanisms Within Subnets).
Documented Type, Default, and Setter
The Subnet Hyperparameters
reference lists MechanismCount as a u8 with a default of 1. It is changed through the
sudo_set_mechanism_count extrinsic, and the reference marks the permission required to set it as
subnet owner. The hyperparameter table lists no btcli sudo set helper for this field
(Subnet Hyperparameters).
Because each subnet carries its own hyperparameters, the mechanism count is defined per subnet. A
default of 1 matches the backward-compatible case in which a subnet runs a single incentive
mechanism
(Multiple Incentive Mechanisms Within Subnets).
The rate-limit reference documents a 7,200-block cooldown (about 24 hours) between successful
sudo_set_mechanism_count updates on a subnet. That limit is separate from the emission-split
update cooldown listed for multiple-mechanism subnets, so changing mechanism count and changing how
emissions are split are paced independently
(Chain Rate Limits: Subnet Mechanism count update rate limit).
Owners checking mechanism count on netuid 1 with
btcli subnet hyperparameters --netuid 1 --network finney should expect that pacing window before
another count change is accepted on the same subnet
(Subnet Hyperparameters: View hyperparameters).
Distinction from Multiple Incentive Mechanisms
Multiple incentive mechanisms name the general model in which one subnet can apportion emissions across more than one evaluation path. Mechanism count names the hyperparameter that sets how many such mechanisms the subnet is configured to run (Glossary: Multiple Incentive Mechanisms).
- Multiple incentive mechanisms — the multi-mechanism subnet model.
- Mechanism count — the on-chain count configured for a subnet.
Distinction from Max Allowed UIDs
Mechanism count and max allowed UIDs are separate subnet hyperparameters that share a documented capacity constraint. Mechanism count sets how many incentive mechanisms run on the subnet, while max allowed UIDs sets the ceiling on how many registered neurons those mechanisms share. The reference requires that mechanism count multiplied by max allowed UIDs must not exceed 256, so raising mechanism count can force lowering the UID ceiling before the change is accepted (Subnet Hyperparameters, Multiple Incentive Mechanisms Within Subnets).
For readers, max allowed UIDs answers how many participants the subnet can hold, while mechanism count answers how many evaluation paths share that population. A subnet can keep a high UID ceiling with a mechanism count of one, but adding mechanisms shrinks the UID headroom the product rule allows (Subnet Hyperparameters: MaxAllowedUIDs).
When the product would exceed 256, the owner must first reduce live UID capacity, either by lowering max allowed UIDs or by using UID trimming, before the higher mechanism count is accepted (Subnet Hyperparameters: MaxAllowedUIDs, UID Trimming).
- Mechanism count — how many incentive mechanisms run on the subnet.
- Max allowed UIDs — the ceiling on registered UID slots those mechanisms share.
Distinction from UID Trimming
Mechanism count and UID trimming both touch subnet capacity, but they name different operations. Mechanism count is the hyperparameter that sets how many incentive mechanisms run, while UID trimming is the owner action that removes excess UIDs when live registration exceeds the configured ceiling (UID Trimming, Subnet Hyperparameters).
For readers, trimming reduces an oversized UID set to fit max allowed UIDs. Mechanism count changes can require that ceiling to move first because the product of mechanism count and max allowed UIDs must not exceed 256. Trimming addresses live over-capacity; mechanism count addresses how many evaluation paths share whatever capacity remains (Multiple Incentive Mechanisms Within Subnets).
- Mechanism count — the configured number of incentive mechanisms on a subnet.
- UID trimming — the action that brings live UID count back under the configured ceiling.
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
Mechanism count is per-subnet chain state. The number configured on one netuid applies only to that subnet’s incentive layout, but the live count can differ from the reference default and from the count on another netuid (Subnet Hyperparameters, Multiple Incentive Mechanisms Within Subnets).
This article’s infobox uses netuid 1 as an example when discussing one subnet at a time on Finney mainnet. That label helps readers anchor examples; it is not proof that every subnet shares the same live count (Bittensor Networks).
Mechanism count governs how many incentive paths run; Yuma Consensus still describes how validator weights are combined within each path once those paths are active (Yuma Consensus).
- Mechanism count — configured number of incentive mechanisms on a subnet.
- Per-subnet boundary — live value is chain state on one netuid.
Distinction from Yuma Consensus
Mechanism count is the hyperparameter that sets how many incentive mechanisms run on a subnet. That configuration value is separate from the aggregation path Yuma uses to combine validator weights inside each mechanism track (Subnet Hyperparameters, Multiple Incentive Mechanisms Within Subnets).
Yuma Consensus reads submitted weights per mechanism and credits miner incentives and validator dividends when the epoch closes on the selected netuid (Yuma Consensus, Emission).
Split subnets keep separate scoring tracks. Mechanism count names how many tracks exist; Yuma names how weights in each track settle into credited shares (Understanding Incentive Mechanisms).
- Mechanism count — configured number of incentive mechanisms on a subnet.
- Yuma Consensus — weight-aggregation path inside each mechanism.
Reader Boundary
This page defines the concept at a high level. It does not report the live mechanism count on any
particular subnet, how emissions are split among mechanisms, whether a proposed count change would
pass the UID-product constraint, or how soon another count change could be accepted after a prior
update. Those are live chain state and subnet-design choices that should be checked for the relevant
netuid with btcli subnet hyperparameters --netuid <NETUID> and the multiple-mechanism
documentation for that subnet
(Subnet Hyperparameters,
Multiple Incentive Mechanisms Within Subnets).