AutoStakeDestination
Storage Map v315 → v411 · 1 shape changeAuto-stake destination hotkey for a coldkey on a subnet .
Explore chainThe Big Picture
Auto-stake enables automatic compounding. Instead of emissions going to your free balance (where you'd manually re-stake them), they automatically stake to a designated hotkey. Set it once and your stake compounds without any further action. This storage shows where each coldkey's rewards go.
Why This Matters
Earning rewards but want them automatically restaked? Auto-stake does that. This tells you which hotkey will receive your rewards. If not set, rewards go to free balance and you must manually stake.
Example Scenario
Query AutoStakeDestination(coldkey=you, netuid=1) returns hotkey_X. Your emissions from subnet 1 will automatically stake to hotkey_X. If it returns None/default, auto-stake isn't enabled.
Common Questions
- How do I enable auto-stake?
- Use the set_auto_stake_destination call to configure where rewards should go. You can set different destinations for different subnets.
- Can I auto-stake to a different validator?
- Yes, you can set any hotkey as your auto-stake destination - doesn't have to be one you own.
- Does auto-stake work cross-subnet?
- Each subnet has its own auto-stake destination. You configure per-subnet where rewards go.
- What if the destination hotkey deregisters?
- Auto-stake to a non-existent destination may fail. Monitor your destinations and update if validators deregister.
Use Cases
- Check where your rewards will auto-stake
- Verify auto-stake configuration is correct
- Build wallet UIs showing auto-stake status
- Calculate compound yield projections
- Debug why rewards aren't appearing in expected location
From Chain Metadata
DMAP ( cold, netuid )--> hot | Returns the hotkey a coldkey will autostake to with mining rewards.
Purpose & Usage
Purpose
Where rewards automatically stake - enables compound staking without manual intervention.
Common Query Patterns
- Query destination by coldkey-netuid
- Check if auto-stake is configured
- Verify auto-stake setup before relying on it
Migration Notes
key type changed from AccountId to (AccountId, u16)
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
hot (AccountId)
Decoding the value
AccountId (32-byte hex)Bittensor uses SS58 prefix 42 for both hotkeys and coldkeys. The 32 bytes are sr25519 public keys.
value as `0x${string}` // 32-byte AccountIdRelationships
Modified By
Related Events
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 AutoStakeDestination storage
const cold = "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY";
const netuid = 1;
const result = await api.query.SubtensorModule.AutoStakeDestination.getValue(cold, netuid);
console.log("AutoStakeDestination:", result);Version History
- key :
AccountId→(AccountId, u16) - hashers :
Blake2_128Concat→Blake2_128Concat,Identity
Runtime Info
View Source- Pallet
- SubtensorModule
- Storage Kind
- Map
- First Version
- v315
- Current Version
- v411