Burn Increase Mult
Burn increase mult is a per-subnet hyperparameter, listed in the documentation as
BurnIncreaseMult, that raises a subnet’s dynamic registration burn cost when a registration
succeeds. The
Subnet Hyperparameters reference
describes it as the factor by which the current neuron registration burn cost is multiplied when a
registration succeeds, which is what makes registration more expensive as demand rises.
What It Controls
The hyperparameter sets the step-up applied to the live burn cost after each successful registration. Registration burns TAO, and that cost is dynamic: it rises with registrations and eases back during quieter periods. Burn increase mult names the upward side of that movement, while burn half life names the downward decay (Glossary: Register).
When registrations cluster, each success multiplies the burn upward, which raises the price of the next slot and throttles a registration rush. It does not set the floor or ceiling of the burn; those are the separate min burn and max burn hyperparameters (Subnet Hyperparameters).
Because the step-up fires only after a successful registration rather than at tempo boundaries, several increases can land within one consensus cycle when registrations cluster inside a single epoch. Burn half life eases the live burn every block between those events; burn increase mult raises it only at registration boundaries (Subnet Hyperparameters, Glossary: Register, Glossary: Tempo).
Documented Application
The subnet hyperparameters reference describes BurnIncreaseMult as the factor by which the current
neuron registration burn cost is multiplied when a registration succeeds, before MinBurn and
MaxBurn clamping. Higher values make rapid successive registrations more expensive
(Subnet Hyperparameters: BurnIncreaseMult,
Glossary: Register).
The hyperparameters overview applies that burn-half-life and burn-increase-mult pricing model to non-root neuron registration, so the step-up governs ordinary subnet UIDs rather than root’s separate registration economics (Subnet Hyperparameters).
A configured multiplier below one therefore cannot undercut the floor on its own; the post-multiply burn is clamped back inside the documented min-burn and max-burn band before it becomes the next live quote (Subnet Hyperparameters: MinBurn, Subnet Hyperparameters: MaxBurn, Miner registration).
Documented Description and Setter
The Subnet Hyperparameters
reference lists BurnIncreaseMult as a registration-burn hyperparameter and describes it as the
factor by which the current burn is multiplied on a successful registration. The step-up factor on
netuid 1 can differ from another subnet’s multiplier
(Subnet Hyperparameters).
Unlike the burn bounds MinBurn and MaxBurn, which carry fixed documented defaults, the reference
does not publish a single default for BurnIncreaseMult. It records the value as network-dependent
and directs readers to read it from the live hyperparameter table rather than assume a constant,
which is why the infobox shows no default figure
(Subnet Hyperparameters).
The reference also documents it as a floating-point multiplier in the runtime rather than a normalized integer, so it is read as a plain factor applied to the current burn rather than a value that must be scaled like the TAO-denominated burn bounds (Subnet Hyperparameters).
The value in force is per-subnet chain state, so a subnet’s real step-up behavior should be read for
that subnet rather than assumed. For the documented example netuid 1 on Finney mainnet it can be
read with btcli subnet hyperparameters --netuid 1 --network finney, which keeps the multiplier
claim reproducible against a parseable netuid
(Subnet Hyperparameters: View hyperparameters).
Distinction from Burn Half Life
Burn increase mult steps the live burn up on each registration, while burn half life decays it back toward the floor between registrations (Glossary: Register).
- Burn increase mult — raises the burn when a registration succeeds.
- Burn half life — decays the burn back down during quiet periods.
Distinction from Min Burn and Max Burn
Min burn and max burn fix the lower and upper bounds of the registration-burn band, while burn increase mult moves the live burn upward inside that band as registrations occur. Max burn in particular caps the upper bound the multiplier can climb toward, so each successful registration steps the live burn higher without ever exceeding that ceiling (Subnet Hyperparameters, Mining: Miner registration, Glossary: Register).
- Min burn / max burn — the floor and ceiling of the burn range.
- Burn increase mult — the per-registration step that climbs within that range toward the max-burn ceiling.
Distinction from Registration
Burn increase mult shapes how the dynamic registration burn responds to demand. Neuron registration is the action that triggers the step-up by paying the current burn to claim a UID slot (Glossary: Register, Miner registration).
- Neuron registration — claiming a UID slot by paying the dynamic registration burn.
- Burn increase mult — factor that multiplies the burn upward after each successful registration.
Distinction from Max Registrations Per Block
Burn increase mult is a pricing step: it multiplies the live registration burn upward after each successful registration on a subnet such as netuid 1. Max registrations per block is legacy per-block cap vocabulary that the current hyperparameter reference marks as not used for neuron registration, so live admission is governed by burn pricing rather than by that cap (Subnet Hyperparameters: MaxRegistrationsPerBlock, Subnet Hyperparameters).
The two answer different historical questions. Burn increase mult is part of the current burn step-up model, while max registrations per block describes an older per-block throughput cap that should not be read as live registration control on ordinary subnets today.
- Burn increase mult — per-registration step-up applied to the live burn price.
- Max registrations per block — legacy per-block registration cap vocabulary.
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
Burn increase mult is per-subnet chain state. The step-up multiplier configured on one netuid controls how sharply registration burn rises after each successful registration on that subnet, but the live value can differ from reference defaults and from the multiplier on another netuid (Subnet Hyperparameters, Glossary: Burn Cost).
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 step-up multiplier (Bittensor Networks).
Burn increase mult names the per-registration increase inside the burn band; Yuma Consensus still settles validator weights into emission shares each epoch on the active subnet (Yuma Consensus).
- Burn increase mult — per-registration burn step-up multiplier on a subnet.
- Per-subnet boundary — live multiplier is chain state on one netuid.
Distinction from Yuma Consensus
Burn increase mult is a per-subnet hyperparameter that steps the dynamic registration burn upward after each successful registration. Yuma Consensus is the separate tempo process that converts validator weight submissions into emission shares each epoch (Subnet Hyperparameters, Yuma Consensus, Emission).
-
Burn increase mult — per-registration multiplier toward the burn ceiling.
-
Yuma Consensus — on-chain settlement that turns validator weights into emission shares. Burn increase mult names registration burn stepping; Yuma processes validator weights into rewards (Yuma Consensus: Validator emissions).
-
Registration vs settlement — burn increase mult paces registration economics; Yuma aggregates validator weights into emission shares at epoch boundaries (Subnet Hyperparameters, Yuma Consensus).
-
Demand response — clustered registrations step burn upward inside the min/max band (Glossary: Register).
Reader Boundary
Burn increase mult should not be read as a fixed registration price or as the min or max burn bounds. It names only the per-registration step-up applied to the live burn on a selected netuid. It does not report the live multiplier, the current registration-burn quote, or the min-burn and max-burn band on that netuid; those are separate hyperparameter reads (Subnet Hyperparameters, Subnet Hyperparameters: View hyperparameters).