This chapter builds on: Ch 3 The Subtensor Chain
Learn / Accounts & Identity

Accounts & Identity

Every participant in Bittensor needs an identity on-chain. This chapter explains how accounts work, why Bittensor uses two keys instead of one, and how participants register to join subnets.

Coldkeys & Hotkeys

Most blockchains give you a single key pair: one private key, one public address. Bittensor takes a different approach. Every participant operates with two key pairs: a coldkey and a hotkey. This dual-key design separates security from daily operations.

Your coldkey is your bank vault. It holds your TAO, signs high-value transactions (transfers, staking, unstaking), and should be kept in cold storage, ideally offline. You only bring it out when you need to move funds or change delegation. Compromise your coldkey and you lose everything.

A hotkey, by contrast, is like a debit card. It handles day-to-day operations: mining, validating, setting weights, and serving requests. Hotkeys are "hot" because they need to be online and signing transactions constantly. If a hotkey is compromised, an attacker can disrupt your operations but cannot steal your staked TAO; that requires the coldkey.

Why two keys?

Miners and validators must run software 24/7 on internet-connected machines. If the same key that holds your funds is also the one signing every weight update, a server compromise means total loss. The dual-key model lets you keep your wealth (coldkey) isolated from your operations (hotkey). One coldkey can manage multiple hotkeys across different subnets.

Scenario: A Miner's Hotkey Gets Compromised

Step 1 of 6

Bob runs a miner on Subnet 3

Bob has a coldkey in cold storage and a hotkey running 24/7 on a cloud server. His hotkey is registered on SN3 with UID 42 and has 50,000 TAO staked to it (delegated from Bob's coldkey and other nominators).

Creating an Identity

Bittensor accounts use the same cryptographic primitives as Polkadot: Sr25519 key pairs encoded as SS58 addresses. The SS58 format is a base-58 encoding that includes a network prefix, so you can tell which network an address belongs to at a glance. Bittensor uses prefix 42 (the generic Substrate prefix, shared by chains that have not registered a dedicated prefix).

Creating an account is as simple as generating a key pair. No on-chain transaction is needed; the account "exists" the moment someone sends TAO to it or it appears in a transaction. The btcli command-line tool is the standard way to create and manage wallets. Each wallet directory contains a coldkey file and one or more hotkey files.

On-chain identity metadata (name, description, URL) can be set via the set_identity extrinsic. This helps other participants identify who is behind a given address, particularly useful for validators seeking delegated stake, since nominators want to know who they are trusting.

You can look up any Bittensor account on the bittensor.ai account explorer to see balances, stake, and transaction history.

Registration & UIDs

Having an account is not enough to participate in a subnet. Miners and validators must register on each subnet they want to join. Registration assigns a UID (a number from 0 to n-1, where n is the subnet's max size), and this is your identity within that specific subnet. UIDs are reusable: if a participant is deregistered, their UID can be reassigned to a new registrant.

There are two ways to register. Burn-based registration requires destroying (burning) a specified amount of TAO. The burn cost adjusts dynamically: it increases when many participants are registering and decreases when fewer are. This acts as a market-driven rate limiter, preventing spam while keeping entry accessible during quiet periods.

Proof-of-Work (PoW) registration is the alternative: solve a computational puzzle to earn a slot. This path doesn't cost TAO but requires compute power. The difficulty adjusts to target a consistent registration rate. In practice, most participants use burn-based registration for its simplicity and speed.

Each subnet has a maximum number of UIDs (set by the subnet owner). When all slots are full, new registrants can only join by replacing the lowest-performing participant, a mechanism called pruning. The result is continuous competitive pressure: you must contribute value to keep your slot.