Yuma Version
Yuma version is a per-subnet hyperparameter, listed in the documentation as YumaVersion, that
selects which Yuma Consensus version a
subnet uses when processing validator weights. The reference describes it as toggling the consensus
mechanism between Yuma Consensus v2 and v3
(Subnet Hyperparameters).
What It Controls
The hyperparameter chooses the consensus implementation path for a subnet, not the subnet task, miner incentives formula in the abstract, or the tempo at which epochs run. Validator weights still feed into Yuma settlement on each epoch; the version flag decides whether that settlement follows the v2 or v3 consensus rules on the selected netuid (Subnet Hyperparameters, Yuma Consensus).
Yuma Consensus v3 introduces bond-scaling refinements that make validator-miner bonds more responsive to independent evaluation, while v2 follows the earlier bonding model. Enabling v3 on a subnet therefore changes how bonds evolve inside consensus without replacing the broader epoch structure (How Yuma Consensus 3 Makes Bittensor More Fair, Yuma Consensus).
The flag is owner-tunable per subnet, so netuid 1 can run one version while another netuid runs the other, and the live value is chain state rather than a network constant (Subnet Hyperparameters, Bittensor Networks).
Documented Type, Default, and Setter
The Subnet Hyperparameters
reference lists YumaVersion as a Bool with a default of false and marks the permission required
to change it as subnet owner. With the default off, a subnet uses the v2 path unless an owner
enables v3 for that netuid
(Subnet Hyperparameters).
The reader-facing parameter name and its on-chain setter differ. The flag is exposed in tooling as
btcli sudo set --param yuma_version, but the underlying setter extrinsic is named
sudo_set_yuma3_enabled, reflecting that toggling the version on is what enables the v3 path
(Subnet Hyperparameters).
YumaVersion is also one of the rows returned by the canonical get_subnet_hyperparams_v3 runtime
API, so the live consensus version for a subnet can be read from the current hyperparameter table
rather than inferred from the default
(Subnet Hyperparameters).
Because each subnet carries its own hyperparameters, the consensus version on one netuid can differ from the documented default and from the version active on another subnet (Subnet Hyperparameters).
Per-Subnet and Opt-In By Design
Because the flag is per-subnet and defaults to false, the network can run mixed consensus versions at the same time: some subnets on the v2 path and others on v3, each according to its own owner’s choice. There is no network-wide switch that moves every subnet at once (Subnet Hyperparameters).
Adoption of v3 is therefore opt-in per netuid. A subnet keeps the v2 path until its owner explicitly sets the flag, and the change applies only to that subnet’s own consensus settlement rather than to any other netuid (Subnet Hyperparameters, How Yuma Consensus 3 Makes Bittensor More Fair).
Reading the Live Value for netuid 1
Yuma version is per-subnet chain state, so any live claim is tied to a specific netuid. For the
documented example netuid 1 on Finney mainnet, readers can verify the live flag with
btcli subnet hyperparameters --netuid 1 --network finney, which prints that subnet’s
hyperparameter table including this Boolean row
(Subnet Hyperparameters: View hyperparameters).
The infobox uses netuid 1 only as an example label; other subnets expose their own values
(Bittensor Networks).
Distinction from Yuma Consensus 3
Yuma version is the per-subnet hyperparameter that selects v2 or v3 consensus on a netuid. Yuma Consensus 3 is the consensus refinement itself — the bond-scaling model that v3 applies when this flag is enabled (Subnet Hyperparameters, Yuma Consensus 3).
- Yuma version — owner-settable toggle choosing v2 or v3 on a subnet.
- Yuma Consensus 3 — the v3 bonding and consensus refinement that runs when v3 is selected.
Distinction from Liquid Alpha
Yuma version selects whether a subnet runs Yuma Consensus v2 or v3 bonding rules on netuid 1. Liquid alpha is a separate hyperparameter that varies bond-smoothing by consensus alignment, but the current epoch path applies that liquid-alpha smoothing only when v3 is selected. The v2 path keeps ordinary EMA bond computation without liquid alpha (Subnet Hyperparameters, Consensus-based Weights, How Yuma Consensus 3 Makes Bittensor More Fair).
Enabling v3 changes the consensus bonding model itself; liquid alpha tunes how alignment maps into bond smoothing inside that v3 path rather than choosing between v2 and v3 (Yuma Consensus).
- Yuma version — per-subnet toggle between Yuma Consensus v2 and v3.
- Liquid alpha — alignment-varying bond smoothing used on the v3 bonding path when enabled.
Distinction from Bonds Penalty
Yuma version switches the consensus implementation path between v2 and v3 on the selected netuid. Bonds penalty sets the magnitude of the out-of-consensus bond penalty applied when validator weights exceed the consensus benchmark during bonding (Subnet Hyperparameters, Yuma Consensus: Penalizing out-of-consensus bonds).
A subnet can enable v3 without changing bonds penalty, and can tune bonds penalty independently of which Yuma version is active on netuid 1 (Subnet Hyperparameters).
- Yuma version — selects v2 or v3 consensus bonding rules.
- Bonds penalty — hyperparameter magnitude for out-of-consensus bond-path adjustment.