Regenerating a Key
Regenerating a key refers to recovering wallet key material from recovery information. In Bittensor wallet context, official documentation treats key material and recovery phrases as security-sensitive.
References: Glossary: Regenerating a Key, Working with Keys
Wallet Recovery Context
The term belongs to wallet recovery and key custody. Recovery information can restore access to wallet keys, so it should be protected with the same care as other sensitive wallet material.
References: Glossary: Mnemonic, Wallets
Coldkey and Hotkey Context
The Glossary: Regenerating a Key defines regenerating a key as recreating a lost or deleted coldkey or hotkey using the associated mnemonic. The recovery path applies to wallet key material tied to that mnemonic, not to subnet registration slots or validator permissions.
References: Glossary: Regenerating a Key, Glossary: Mnemonic
Reader Boundary
This page defines the term. It does not ask readers to enter a recovery phrase, expose keys, or follow a specific recovery action. The Working with Keys documentation is the better source for current security-sensitive wallet actions.
Recovery Versus Subnet Participation
Regenerating a key restores wallet key material from recovery information; it does not by itself recreate subnet UID slots, validator permits, or on-chain registration state. The glossary defines regenerating a key as recreating a lost or deleted coldkey or hotkey using the associated mnemonic, which keeps the operation inside wallet recovery vocabulary rather than subnet entry vocabulary.
Readers should not treat key regeneration as a substitute for registration or delegation setup on a subnet. Restored hotkey files can sign operational work again, but subnet participation still depends on the registration and permit context described in official mining and validating documentation. Live chain state determines what a restored key can operate after recovery completes. Registration commands and permit tables belong in those operational references rather than in recovery prose.
References: Glossary: Regenerating a Key, Glossary: Register
Coldkey Versus Hotkey Regeneration Scope
The glossary applies regeneration to both coldkeys and hotkeys tied to a mnemonic, but those roles carry different authority after recovery. Coldkeys control balances, stake authority, and hotkey management; hotkeys carry operational authority for subnet roles. Regenerating one key type restores that role’s signing material, not necessarily every other key in the wallet hierarchy.
Readers should identify which key was lost before choosing a recovery path. Regenerating a hotkey restores operational signing for subnet work under the owning coldkey; regenerating a coldkey restores custody-level authority described in wallet documentation. The mnemonic must match the key being restored, because recovery material is tied to the specific wallet keys it originally generated.
References: Glossary: Regenerating a Key, Wallets, Coldkeys and Hotkeys
Regeneration Versus Rotation Operations
Regenerating a key recreates lost key files from saved recovery material. Hotkey swap and coldkey swap, by contrast, are deliberate on-chain rotation or identity migration operations while keys still exist or while a controlled migration is authorized. The recovery path answers missing local key material; swap operations answer compromised or migrated on-chain identity under documented rules.
Mixing the terms can confuse incident response. A deleted hotkey file may call for regeneration from a mnemonic, while a suspected hotkey leak may call for hotkey swap under the security documentation without treating the coldkey as lost. Operational steps, fees, and rate limits for swap paths belong in official wallet and security references rather than in this concept article. Recovery restores local signing files; swap migrations change on-chain key identity under separate documented rules.
References: Glossary: Regenerating a Key, Coldkey and Hotkey Workstation Security
Relationship to Mnemonic
Regenerating a key and a mnemonic are related but different parts of Bittensor wallet vocabulary. A mnemonic is the recovery phrase (seed phrase) from which wallet key material can be derived, while regenerating a key is the recovery operation that uses that mnemonic to recreate lost or deleted coldkey or hotkey material. The Glossary: Mnemonic describes the mnemonic as the human-readable representation of the wallet seed, and the Glossary: Regenerating a Key describes key regeneration as the process of using that mnemonic to recreate a key.
For readers, the mnemonic is the recovery material that should be protected offline, while regenerating a key names the recovery procedure that uses that material to restore wallet access.
References: Glossary: Mnemonic, Glossary: Regenerating a Key
Relationship to Coldkeys
Regenerating a key and coldkeys are related but different scopes in Bittensor wallet vocabulary. A coldkey is the security-sensitive key that holds TAO balances and owns hotkeys, while regenerating a key is the recovery operation that can restore that coldkey (or a hotkey) from a saved mnemonic when the original key file is lost or deleted. The Wallets, Coldkeys and Hotkeys documentation describes coldkeys as the custody anchor for wallet security, and the Glossary: Regenerating a Key describes regenerating as the procedure for recovering key material using the associated mnemonic.
For readers, the coldkey is the wallet identity being protected, while regenerating a key is the recovery path that restores access to that identity when key files are no longer available on the local machine.
References: Wallets, Coldkeys and Hotkeys, Glossary: Regenerating a Key
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Regenerating a Key, this sequence gives readers a boundary for interpreting key-regeneration examples and environment-boundary notes.
Localnet examples are isolated and reflect local chain state, so they are useful for controlled experiments rather than evidence of live Bittensor behavior. Testnet examples add shared non-production conditions, which can reveal integration behavior without touching mainnet state.
On mainnet, Regenerating a Key examples should be read as live production key-management behavior on the production Bittensor network.
The Bittensor Networks reference separates mainnet, testnet, and localnet, so outcomes from one environment should not be treated as proof of behavior in another.