ChildKeys
Storage Map v195 → v472 · 1 shape changeChild hotkeys and proportions for a parent hotkey on a subnet .
Explore chainThe Big Picture
Child keys allow a parent hotkey to distribute its stake among multiple child hotkeys. Each child receives a proportion of the parent's stake, enabling complex validator operations - like running multiple specialized miners under one validator umbrella.
Why This Matters
How does a validator split stake among its operations? ChildKeys shows the distribution. Each child receives a proportion of the parent's stake for their specific role.
Example Scenario
Query ChildKeys(netuid=1, parent_hotkey=X) returns three entries whose u64 proportions are 9223372036854775807, 5534023222112865484 and 3689348814741910323. Divide each by u64::MAX to read them: child A gets 50%, B gets 30%, C gets 20% of the parent's stake on subnet 1.
Common Questions
- What are proportions in?
- u64 scaled to u64::MAX, so 18446744073709551615 is 100% and half of that is 50%. The runtime checks that the proportions sum to at most u64::MAX (ensure_total_proportions), and a smaller sum simply leaves the remainder with the parent.
- Why use child keys?
- Validators with complex operations can delegate stake to specialized child hotkeys without moving actual TAO. Enables organizational flexibility.
- How does this affect emissions?
- Children earn based on their effective stake (proportion × parent stake). Emissions flow through the hierarchy based on these proportions.
Use Cases
- Check how a validator distributes stake to child operations
- Build stake flow visualizations
- Calculate child hotkey effective stakes
- Research stake delegation patterns
- Verify child key configurations
From Chain Metadata
DMAP ( parent, netuid ) --> Vec<(proportion,child)>
Purpose & Usage
Purpose
Track stake distribution to child hotkeys - enables stake delegation within hotkey relationships.
Common Query Patterns
- Query children for a parent on a subnet
- Iterate all parent-child relationships
- Calculate stake distribution from parent to children
Notes
- Returns Vec<(proportion, child)>
Migration Notes
key type changed from (AccountId, u16) to (AccountId, NetUid)
Update decoders: SCALE encoding is positional, so any signature change (added, removed, or type-changed fields, or storage shape changes) shifts byte offsets and existing decoders will misparse this item. Re-derive types from the new metadata.
Query Keys
Stored Value
Vec<(proportion,child)> (Vec<(u64, AccountId)>)
Default Value
Absent keys read as this value — querying a key that has never been written returns this default, not an error or empty result.
Relationships
Modified By
Code Examples
import { createClient, Binary } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws";
import { sub } from "@polkadot-api/descriptors"; // generated by: npx papi add sub -w wss://entrypoint-finney.opentensor.ai:443
const client = createClient(getWsProvider("wss://entrypoint-finney.opentensor.ai:443"));
const api = client.getTypedApi(sub);
// Query ChildKeys storage
const parent = "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY";
const netuid = 1;
const result = await api.query.SubtensorModule.ChildKeys.getValue(parent, netuid);
console.log("ChildKeys:", result);On-Chain Activity
10K–100K estimated writes
#45 most written storage item
Modified via user-submitted extrinsics
As of block 7,429,232
Version History
- key :
(AccountId, u16)→(AccountId, NetUid)
Runtime Info
View Source- Pallet
- SubtensorModule
- Storage Kind
- Map
- First Version
- v195
- Current Version
- v472