Child Hotkeys
A child hotkey is a separate validator key that a delegate validator authorizes to validate on its behalf in a selected subnet. The official documentation calls the originating delegate hotkey the parent hotkey, and describes child hotkeys as keys the parent re-delegates a portion of its stake to so they can validate in its place.
References: Child Hotkeys
Parent and Child
The parent hotkey is an existing delegate that already holds stake. A child hotkey is a different key that the parent points a share of that stake toward. The documentation explains that the child then validates on behalf of the parent, so the parent key does not have to sign every validation operation itself. This is a delegation relationship between two keys rather than a transfer of ownership of the underlying stake.
References: Child Hotkeys, Staking and Delegation Overview
Subnet Context
Child hotkeys are configured for a specific subnet, identified by netuid; for example, a validator can assign children for netuid 1 and a different set for another netuid. The documentation states that a parent may have at most five child hotkeys on a given netuid, and that the same parent can hold a separate set of children on a different netuid. The configuration is therefore independent per subnet.
Reference: Child Hotkeys
Child Take
Child take is the share of rewards a child hotkey keeps for validating on the parent’s behalf. The documentation describes it as subnet-specific, ranging from 0 (0%) to 0.18 (18%), with a default of 0, and paid from the dividends the parent’s stake would otherwise receive on that subnet. A child hotkey can also hold a separate delegate take, so the child take rate and the delegate take rate are described as independent settings.
References: Child Hotkeys, Glossary: Validator Take
Why Validators Use Them
The documented rationale is key security. Validating through children lets the parent delegate hotkey stay in a secure location while each child signs operations for its assigned subnet, optionally on a different machine. The documentation notes that if an attacker steals a child hotkey, only the subnets where that child is used are exposed, rather than the full parent key, which limits the impact of a compromised validation key.
Reference: Child Hotkeys
Parent Delegate Keeps the Stake
The Child Hotkeys documentation
describes a parent delegate hotkey that already holds stake and assigns a childkey proportion for a
specified netuid. The parent remains the delegated stake holder; the child configuration applies
the proportion for that subnet only.
Readers should attach both the parent hotkey and the netuid to a child-hotkey claim. The same
parent can use a different child set on another subnet without mixing the two configurations.
References: Child Hotkeys, Glossary: Hotkey
Parent Authorization Boundary
A child hotkey signs validation work because the parent delegate hotkey authorized it for a subnet.
That authorization does not make the child the owner of the parent’s stake or the general manager of
the parent’s wallet. The child-hotkey documentation keeps the relationship scoped to validating on
the parent’s behalf inside the selected netuid.
For readers, child-hotkey authority should therefore be read as delegated operational signing, not as custody transfer. The parent-child relationship explains who may validate for a subnet; it does not replace the wallet authority model for balances, stake ownership, or coldkey control.
Reference: Child Hotkeys
Child Take From Parent Dividends
Child take is the percentage of the parent’s dividends that a child hotkey keeps for validating on the parent’s behalf. The same documentation gives a subnet-specific range from 0 to 0.18, with a default of 0, and states that the child receives that percentage of the parent’s dividends on the selected subnet.
That wording keeps child take inside dividend-sharing vocabulary for one netuid. It is separate
from delegate take settings that apply more broadly to validator-delegator emission sharing.
References: Child Hotkeys, Glossary: Dividends
Separate Child Hotkeys per Subnet
Validators can run separate child hotkeys per subnet so the parent delegate hotkey does not need to be used everywhere. The documentation gives the security reason plainly: if one child key is compromised, only the subnets where that child is configured are exposed rather than every subnet the parent uses.
That makes child hotkeys a per-subnet operational choice. The parent delegate keeps stake; each child hotkey can sign validation work for the subnets where the parent authorized it.
The five-child limit and 18% take ceiling remain protocol limits from the official documentation rather than live values reported by this concept article.
References: Child Hotkeys, Glossary: Subnet Validator
Relationship to Multiple Mechanisms
A child hotkey validates on behalf of a parent delegate inside one subnet. The Glossary notes that each incentive mechanism has its own weight matrix for independent consensus calculations.
For readers, a child hotkey still names a delegated validation key. Weight-related actions it signs on the parent’s behalf should be read with that mechanism’s matrix context.
References: Multiple Incentive Mechanisms Within Subnets, Glossary: Weight Matrix
Relationship to Coldkey Swap
Child hotkeys and coldkey swap are related but different parts of Bittensor key management vocabulary. Child hotkeys are delegated validation keys that a parent hotkey authorizes to validate on its behalf inside specific subnets — a delegation relationship between two hotkeys managed at the subnet level. Coldkey swap is the on-chain identity migration that moves all hotkeys associated with a coldkey to a new coldkey address without resetting their subnet registrations or removing their existing stake. The Child Hotkeys documentation describes the parent-child delegation system, and the Coldkey Swap documentation describes how an identity can be migrated to a new coldkey while preserving existing hotkey state.
A coldkey governs its associated hotkeys, including any parent hotkey that has child hotkey configurations. When a coldkey swap occurs, the new coldkey inherits control of those hotkeys and the parent-child delegation relationships those hotkeys hold in each subnet. The swap operates at the coldkey level and does not reset or remove the hotkey relationships beneath it. Coldkey swap answers which coldkey controls the parent hotkey; child hotkeys answers which validation delegates that parent hotkey has authorized within each subnet.
References: Child Hotkeys, Coldkey Swap
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from local testing to testchain and then mainchain. For child hotkeys, that sequence changes how readers should interpret evidence about delegated validation keys.
In local testing, child hotkey configuration can show whether a parent hotkey is able to authorize a child to validate inside an isolated subnet environment. That is useful for checking the parent-child delegation relationship, but it remains isolated feedback from a local environment.
On testchain, child hotkey behavior can be observed in a shared testing network. This gives stronger evidence about how a child key validates on a parent’s behalf and how child take interacts with parent dividends than a private local run, while still keeping the result separate from production mainchain activity.
On mainchain, child hotkeys belong to live subnet validation state. The Child Hotkeys documentation describes child hotkeys as keys the parent re-delegates a portion of its stake to so they can validate in its place, so production child hotkey context is tied to active delegation inside a live subnet.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A child hotkey configuration observed in one environment should not be read as identical evidence about delegated validation activity in another environment.
For readers, this keeps child hotkey examples from sounding stronger than their environment supports. Local, testchain, and mainchain contexts can all describe parent-child validation delegation, but they do not carry the same interpretive weight.
Relationship to Yuma Consensus
Child Hotkeys and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, child hotkeys names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
This page defines the concept at a high level. It does not report which child hotkeys a parent currently has, current take values, current stake proportions, or wallet ownership. Those are live chain state and change over time; they should be checked for the relevant netuid with the Bittensor CLI when current data is needed. The numeric rules described here, such as the five-child limit and the 18% take ceiling, are protocol limits from the documentation.
Reference: Child Hotkeys
Relationship Scope
Child hotkeys should be read as a key-relationship concept, not as a general staking or delegation recommendation. Wallet and key documentation separates key custody from staking relationships, so claims about child hotkeys should preserve whether the source is discussing account structure or delegated stake behavior (Bittensor Wallets, Staking and delegation overview).
That distinction helps readers avoid treating every hotkey relationship as evidence about validator selection, emissions, or reward outcomes.
Five-Child Limit Applies Per netuid
Official Child Hotkeys documentation states that a parent may have at most five child hotkeys on a given netuid, while the same parent can hold a different child set on another netuid. The limit is therefore subnet-local rather than a single global count across every subnet the parent uses.
Readers should name the netuid when citing the five-child rule. A parent at the limit on netuid 1 does not by itself describe child configuration on another subnet.
Child Keys Can Operate From Separate Hosts
The child-hotkeys documentation describes validators using children so the parent delegate hotkey can stay in a secure location while each child signs operations for its assigned subnet, optionally on a different machine. Child hotkey vocabulary therefore includes an operational deployment choice, not only a reward-sharing setting.
That security rationale keeps child exposure subnet-scoped. A compromised child key affects only the subnets where that child is configured, as described in the official child-hotkeys reference.