Burn Half Life
Burn half life is a per-subnet hyperparameter, listed in the documentation as BurnHalfLife, that
controls how quickly a subnet’s dynamic registration burn cost decays back toward its floor when no
new registrations are occurring. The
Glossary: Register entry describes
the registration burn as a dynamic value that decays over time according to BurnHalfLife while
staying inside the documented MinBurn and MaxBurn band
(Subnet Hyperparameters).
What It Controls
The hyperparameter sets the decay horizon, measured in blocks, for the burn cost a registrant pays. Each successful registration raises the live burn, and between registrations the burn eases downward; burn half life governs how fast that easing happens. It does not set the floor or ceiling of the burn, which are the separate min burn and max burn hyperparameters (Glossary: Register).
A shorter half life means the live burn returns toward the floor faster after a registration spike, while a longer half life keeps an elevated burn in place for longer. The actual cost a registrant pays at any block depends on recent registration activity and on how half life, increase multiplier, and burn bounds interact for that subnet (Subnet Hyperparameters).
The name reflects the shape of that decay. Between registrations the chain multiplies the current
burn value by a per-block decay factor chosen so that the burn value halves over each span of
BurnHalfLife blocks, then clamps the result to the configured floor. Because the decay is
multiplicative rather than a constant per-block subtraction, the burn eases quickly right after a
spike and then more gradually, and it cannot fall below min burn even as the decay continues
(Glossary: Register,
Subnet Hyperparameters).
Because the decay horizon is measured in blocks while a subnet’s consensus cycle length is its tempo, the relationship between the two decides how burn decay lines up with epoch boundaries. When half life is longer than one tempo, an elevated registration burn can persist across several consensus cycles before easing toward the floor; when it is shorter than one tempo, most of the decay can occur within a single epoch (Subnet Hyperparameters, Glossary: Tempo, Glossary: Burn Cost).
Documented Type and Setter
The Subnet Hyperparameters
reference lists BurnHalfLife among the registration-burn hyperparameters and describes it as the
decay horizon, in blocks, for the neuron registration burn cost between registrations. The decay
horizon on netuid 1 can differ from another subnet’s half life
(Subnet Hyperparameters).
The value in force is per-subnet chain state and should be read for that subnet rather than assumed from another subnet’s setting.
Distinction from Min Burn and Max Burn
Min burn and max burn set the floor and ceiling of the dynamic registration burn band, while burn half life sets how fast the live burn moves downward inside that band between registrations (Subnet Hyperparameters, Glossary: Register).
- Min burn / max burn — the lower and upper bounds of the burn range.
- Burn half life — the decay speed of the live burn toward the floor.
Distinction from Burn Increase Mult
Burn increase mult raises the live burn when a registration succeeds, while burn half life pulls the live burn back down toward the floor during quieter periods (Glossary: Register).
- Burn increase mult — steps the burn up on each successful registration.
- Burn half life — decays the burn back down between registrations.
Distinction from Registration
Burn half life shapes how the dynamic registration burn changes over time. Neuron registration is the action of claiming a UID slot by paying that burn. On ordinary subnets such as netuid 1, admission is continuous without interval-based registration windows; burn half life governs how the live charge decays between successful registration events (Glossary: Register, Miner registration, Subnet Hyperparameters).
Burn half life shapes decay timing for the live registration burn. The hyperparameter reference
marks MaxRegistrationsPerBlock as not used for neuron registration on current ordinary subnets, so
live admission is governed by continuous burn pricing through burn half life and burn increase mult
rather than by a per-block registration cap
(Subnet Hyperparameters: MaxRegistrationsPerBlock,
Subnet Hyperparameters,
Glossary: Register).
Readers tracing older material that pairs burn decay with per-block throughput should treat max registrations per block as legacy vocabulary and verify live registration economics from the current burn hyperparameters on the relevant netuid (Miner registration).
- Neuron registration — claiming a UID slot by paying the dynamic registration burn.
- Burn half life — how fast that registration burn decays between registrations.
Distinction from Max Registrations Per Block
Burn half life sets the decay horizon for registration burn pricing between successful registrations on a subnet such as netuid 1. Max registrations per block is legacy hyperparameter vocabulary for a per-block ceiling on neuron registrations under older models. The reference now states that cap is not used for live neuron registration; continuous burn pricing governs admission instead (Subnet Hyperparameters: MaxRegistrationsPerBlock, Subnet Hyperparameters).
Pricing-decay vocabulary and legacy throughput-cap vocabulary answer different registration questions. Burn half life governs how quickly an elevated burn eases toward the floor between successful registrations; max registrations per block names an obsolete per-block burst limit rather than the live burn path on ordinary subnets today (Glossary: Register).
- Burn half life — decay horizon easing elevated burn between registrations.
- Max registrations per block — legacy per-block registration cap vocabulary.
Distinction from Adjustment Interval
Burn half life sets the decay horizon over which elevated burn cost eases back toward the floor
between registration events on ordinary subnets such as netuid 1. Adjustment interval is legacy
registration-pricing vocabulary for the block window between demand-comparison recalibrations. The
canonical get_subnet_hyperparams_v3 API no longer returns AdjustmentInterval; live burn decay
and step-up economics are instead governed by BurnHalfLife and BurnIncreaseMult
(Subnet Hyperparameters).
- Adjustment interval — legacy interval-based burn recalibration vocabulary removed from V3.
- Burn half life — decay horizon easing elevated burn between registrations.
Distinction from Burn Cost
Burn half life sets how quickly subnet registration burn decays over time. Burn cost is the dynamic TAO amount a participant pays to register on a subnet at a given moment (Subnet Hyperparameters, Glossary: Burn Cost).
- Burn half life — decay schedule for registration burn over time.
- Burn cost — current TAO price for subnet registration.
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 half life is per-subnet chain state. The decay horizon configured on one netuid governs how quickly an elevated registration burn eases toward the floor between registrations on that subnet, but the live value can differ from reference defaults and from half life 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 decay horizon (Bittensor Networks).
Burn half life names decay timing inside the registration-cost band; Yuma Consensus still settles validator weights into emission shares each epoch on the active subnet (Yuma Consensus).
- Burn half life — decay horizon for elevated registration burn between events on a subnet.
- Per-subnet boundary — live half life is chain state on one netuid.
Distinction from Yuma Consensus
Burn half life is a per-subnet hyperparameter that sets how quickly the dynamic registration burn decays over time. Yuma Consensus is the separate tempo process that converts validator weight submissions into emission shares each epoch (Subnet Hyperparameters, Yuma Consensus, Emission).
-
Burn half life — decay schedule for the dynamic registration burn.
-
Yuma Consensus — on-chain settlement that turns validator weights into emission shares. Burn half life names registration burn decay; Yuma processes validator weights into rewards (Yuma Consensus: Validator emissions).
-
Registration vs settlement — burn half life paces registration-burn decay; Yuma aggregates validator weights into emission shares at epoch boundaries (Subnet Hyperparameters, Yuma Consensus).
-
Timing not price — half life names decay speed inside the min/max band, not the live burn amount (Glossary: Burn Cost).
Reader Boundary
Burn half life should not be read as a fixed registration price, as the min or max burn bounds, or as a live per-block registration throughput cap. It names only the decay horizon for the live burn between registrations on a selected netuid (Subnet Hyperparameters, Subnet Hyperparameters: MaxRegistrationsPerBlock).