Childkey Take
Childkey take is the percentage of validation dividends a child hotkey keeps when it validates on behalf of a parent hotkey on one subnet. Official documentation also labels it child hotkey take (Child Hotkeys).
It is not the child key itself or a validator commission across every subnet. It names only the parent-child split on the selected netuid, within the documented 0% to 18% range with a default of 0% (Child Hotkeys, Glossary: Netuid).
What It Represents
A parent hotkey can re-delegate a portion of its stake to a child hotkey so the child validates on that parent’s behalf on one subnet. The childkey take is the portion of the resulting dividends the child keeps for doing that validation work (Child Hotkeys, Glossary: Delegate).
That makes childkey take a payout-split term inside a parent-child validation relationship. It is not a separate registration status, a weight score, or a general validator commission applied across every subnet.
The capped range keeps the split parent-favorable. Because the take tops out at 18 percent, the child hotkey can keep at most a minority share of the routed dividends, so the majority returns through the parent relationship even at the maximum rate (Child Hotkeys).
The constants reference exposes that range as startup values. The default and floor are
api.consts.subtensorModule.initialDefaultChildKeyTake and initialMinChildKeyTake, both listed as
0, and the ceiling is initialMaxChildKeyTake, listed as 11796, which normalizes against the
u16 maximum to about 0.18 — the 18 percent cap above. Each names a launch value, while the live
childkey-take value is the per-subnet rate a child hotkey actually uses after launch
(Subtensor Constants: initialMaxChildKeyTake,
Subtensor Constants: initialDefaultChildKeyTake,
Child Hotkeys).
Subnet-Specific Rate
The child-hotkeys documentation states that the take is subnet-specific: one child hotkey can have one take on one netuid and a different take on another (Child Hotkeys, Glossary: Netuid).
Readers should therefore attach the netuid before comparing childkey-take statements. The stable concept is the per-subnet rate; the live value belongs to the selected subnet configuration rather than to the child hotkey in the abstract.
Change Window
The child-hotkeys documentation describes a roughly 30-day pacing window for childkey-take changes.
The rate-limit reference documents TxChildkeyTakeRateLimit as a 216,000-block cooldown between
successful increases, returning TxChildkeyTakeRateLimitExceeded when an increase is attempted too
soon. Lowering take can proceed without waiting out that window. The cooldown applies only when the
new take is higher than the current take, and it is separate from the 150-block cooldown on
assigning or revoking child hotkeys through set_children
(Child Hotkeys,
Chain Rate Limits: Child key take rate limit,
Chain Rate Limits: Child hotkey operations rate limit).
The constants reference exposes the startup cooldown as
api.consts.subtensorModule.initialTxChildKeyTakeRateLimit, listed as 216000 blocks. That block
count is the chain-side form of the roughly 30-day childkey-take increase window
(Subtensor Constants: initialTxChildKeyTakeRateLimit,
Child Hotkeys).
This cooldown is about how often the take may be raised. It does not change what childkey take means, and it does not pace decreases the same way it paces increases.
Distinction from Validator Take
Childkey take is the share a child hotkey keeps when validating on behalf of a parent hotkey on one subnet. Validator take is the separate commission a validator keeps from delegated-stake emissions before the remainder flows to nominators (Child Hotkeys, Glossary: Validator Take %, Staking and delegation overview).
The two takes share the same 0% to 18% range and the same 216,000-block increase cooldown, but their
defaults sit at opposite ends of that range. The constants reference lists
initialDefaultChildKeyTake as 0, so childkey take starts at the floor with full headroom to be
raised, whereas initialDefaultDelegateTake is 11796, the encoded 18% that is also the top of the
range, so a default delegate take can only be held or lowered. The increase cooldown is therefore
something a childkey-take setter meets early, while a default delegate rarely encounters it at all
(Subtensor Constants: initialDefaultChildKeyTake,
Subtensor Constants: initialDefaultDelegateTake).
- Childkey take — parent/child split on routed validation dividends for one subnet.
- Validator take — validator/nominator commission on delegated-stake emissions.
Distinction from Child Hotkeys
Child hotkeys name the authorized worker keys a parent hotkey assigns per subnet. Childkey take names the rate attached to that relationship (Child Hotkeys).
- Child hotkey — the key that validates on the parent’s behalf.
- Childkey take — the percentage that key keeps from the resulting dividends.
Distinction from Subnet Owner Take
Childkey take arises only when a parent hotkey re-delegates stake to a child hotkey for validation. Subnet owner take is the documented protocol share of subnet alpha emissions allocated to the subnet owner (Child Hotkeys, Emission: Distribution).
- Childkey take — optional payout split inside parent-child validation.
- Subnet owner take — protocol allocation to the subnet owner.
Distinction from Yuma Consensus
Childkey take is the subnet-specific share of validator dividends a child hotkey keeps when it validates on behalf of a parent hotkey. It names a payout-split rate inside the parent-child routing relationship, not the epoch-boundary mechanism that converts weight submissions into emission shares (Child Hotkeys, Glossary: Dividends).
Yuma Consensus is the on-chain mechanism that runs at the epoch boundary on the selected netuid. It reads the weight matrix from eligible validators, applies clipping and bonding, and converts the result into miner incentives and validator dividend shares (Yuma Consensus, Emission).
Childkey take sits downstream of that settlement step. Yuma determines how much dividend value the routed validation position earns; childkey take only decides how much of that dividend the child hotkey keeps versus what returns through the parent relationship (Child Hotkeys).
Readers should treat childkey take as a parent-child dividend split rate, and Yuma as the per-subnet mechanism that settles validator weights into payouts.
- Childkey take — subnet-specific share of routed validation dividends kept by the child hotkey.
- Yuma Consensus — epoch-boundary settlement from eligible validator weights to emission shares.
Reader Boundary
This page defines the term childkey take as the parent-child dividend split rate on one netuid. The live take value for a child hotkey on a selected netuid is readable through subnet hyperparameters; what this article does not provide by itself is whether a recent increase is still inside the 216,000-block cooldown window or the live routed dividend split at settlement time (Subnet Hyperparameters: View hyperparameters, Chain Rate Limits: Child key take rate limit, Child Hotkeys, Glossary: Netuid).