> ## Content Index > Fetch the complete content index at: https://www.tao.media/llms.txt > Use this file to discover other available public pages before exploring further. # What Is a UID on Bittensor? How Neurons Register and Stay Alive - URL: https://www.tao.media/what-is-a-uid-on-bittensor-how-neurons-register-and-stay-alive/ - Published: 2026-10-13T21:51:31.000Z - Updated: 2026-10-13T21:51:31.000Z - Description: Learn what a UID is on Bittensor, how subnet registration works, why immunity matters, and how pruning affects miners and validators. - Author: Tristan Hillerich - Tags: Educational, Bittensor A UID is a per-subnet identifier assigned to a hotkey after registration, giving that hotkey a seat in the subnet's active neuron set. Each subnet has its own UID list. UID 42 on one subnet is not the same thing as UID 42 on another subnet. A single hotkey can hold UIDs on multiple subnets at the same time, but Bittensor's mining guide states that a hotkey can hold only one UID per subnet. So a UID is best understood as a local subnet seat. It tells the chain and other participants where a hotkey sits inside that subnet's competitive environment. ## Neuron = Hotkey + UID on a Subnet In Bittensor, a neuron is the on-chain participant that appears in a subnet's metagraph. For practical purposes, it is the combination of: - A hotkey - A subnet - A UID assigned inside that subnet The hotkey is the operational key used by the miner or validator. The UID is the numbered seat that lets the subnet track that hotkey's activity, emission, incentive, trust, and other metagraph values. Wallets and UIDs serve different purposes. A coldkey can pay for registration, a hotkey can receive the UID, and the UID becomes the subnet-specific position through which the hotkey competes for emissions. The UID is not the same as the coldkey, the hotkey, or the broader wallet identity. It is also not a guarantee of payment. Holding a UID means the hotkey has a seat. Whether that seat earns depends on the subnet's incentive mechanism, validator evaluation, Yuma Consensus, and whether the neuron remains registered when rewards settle. ## How Registration Works on Bittensor To get a UID on a non-root subnet, a participant typically uses `burned-register`. The official `burned-register`transaction documentation describes it directly. The signing coldkey pays the subnet's current floating registration cost, and the hotkey receives a UID. Registration does three things: 1. The coldkey pays the cost to enter the subnet. 2. The hotkey is assigned a UID. 3. The hotkey appears in that subnet's active neuron set. The hotkey can be the wallet's default hotkey or another hotkey passed during registration. Once registered, you can check the hotkey's UID through wallet registration commands or subnet metagraph queries. This process applies to regular subnets. The root network, netuid 0, uses `root_register` rather than the burned-register flow, so root registration is not the same process. Registration is also not a full mining setup guide. Paying to register gives a hotkey a subnet seat, but the actual work depends on the subnet. Each subnet defines its own task, codebase, validator expectations, hardware needs, and incentive mechanism. The chain handles registration and rewards; the subnet defines what useful work means. ## Registration Cost and Subnet Capacity Bittensor subnets have limited UID capacity. The `max_allowed_uids` hyperparameter defines how many neuron slots a subnet has, and Bittensor documentation describes the default maximum as 256, with subnet owners able to size capacity within protocol limits. When a subnet is not full, a new registration can append a new UID. When a subnet is full, a new registration has to replace an existing neuron, which is where pruning comes in. Registration cost is also dynamic. The `burned-register` documentation describes it as a floating cost known exactly only at execution time. The price to register can change depending on subnet conditions, so check it live before submitting a transaction. The word "burned" can also mislead in newer configurations. When a subnet's collateral lock share is zero, the full registration cost is burned or recycled. When the collateral lock share is greater than zero, part of the cost can be locked as miner collateral instead of fully burned. That detail depends on subnet config, so treat registration economics as live subnet data rather than a universal constant. A mature subnet with all UID slots filled must replace an existing participant to admit a new one, which makes registration competitive. ## What Is the Immunity Period? The immunity period is a temporary grace window after registration during which a newly registered neuron is generally protected from pruning to make room for a new registration. Bittensor's `immunity_period` documentation defines it as a number of blocks. A neuron counts as immune while the current block minus its registration block is less than the subnet's immunity period. The default value is 4096 blocks, or about 13.7 hours at 12-second blocks. That default is not a universal rule. Subnet owners can set different immunity periods, and real subnets often use values that differ from the default, so query the live `immunity_period` before relying on it. The immunity period exists because new participants need time to be discovered, evaluated, and to start earning emissions. Validators may not immediately query a freshly registered miner, and emissions settle at tempo boundaries rather than continuously every block. Immunity gives a new UID some runway. Immunity is not absolute, though. If a subnet's non-immune pool becomes too small, Bittensor's documentation notes that the chain can prune the lowest-emission immune neuron instead. The `MinNonImmuneUids` setting keeps enough non-immune UIDs available, and the default is 10\. Immunity is a preference in the pruning logic, not a permanent shield. ## How Pruning and Deregistration Work Pruning is the process of removing an existing neuron from a subnet when a new registration needs a slot. On a full subnet, the chain looks for the lowest-emission prunable neuron. Bittensor's mining guide is explicit that pruning score is emission-based and that the chain does not separate miners from validators for pruning. Whoever earns least is first at risk. The pruning order works like this: 1. If the subnet has open UID capacity, the new registration gets a new slot. 2. If the subnet is full, the chain looks for a non-immune neuron with the lowest emission. 3. If there is a tie, the older registration is pruned first. 4. If there is still a tie, the lower UID is pruned first. 5. Owner-immune hotkeys are skipped within the owner-immune limit. 6. If too many neurons are immune, an immune neuron may still be pruned. Deregistration is mechanical. It does not mean the chain has made a subjective judgment about the participant. It means the neuron lost its UID slot under the subnet's pruning rules. Deregistration also does not confiscate ordinary stake. The mining guide notes that eviction costs the participant the UID, while stake stays where it is. On collateral-enabled subnets, locked collateral can remain attached to the hotkey and be credited when the participant re-registers, depending on the subnet's collateral rules. After the immunity runway ends, a UID has to earn enough emission to avoid being the lowest-emission prunable seat. ## How UIDs Connect to Tempo Payouts A UID is also the position that receives rewards when a subnet epoch settles. Bittensor emissions do not flow continuously to a neuron every block. The emissions documentation explains that distribution happens at epoch boundaries, which occur according to each subnet's tempo. The default tempo is 360 blocks, or roughly 72 minutes, though subnet settings can vary. At the epoch, the accumulated alpha is paid to the hotkeys holding each UID when the epoch fires. If a neuron is pruned in the middle of a tempo, it does not receive a partial payout for that partial tempo. The payout lands on whoever holds the UID at epoch settlement. A pruned participant's last payout was the last successful epoch that occurred while it was still registered. UID lifecycle and tempo are connected. Registration gives the hotkey a seat, immunity gives it a runway, emission determines whether it keeps the seat, and tempo determines when the seat gets paid. ## Axon Publishing and Validator Discovery Registration puts a hotkey into the subnet's metagraph, but miners still need validators to reach them. Bittensor's mining guide summarizes the chain-side work of mining as registering, telling validators where to reach the miner, and avoiding eviction. That "where to reach you" step is handled through serving or axon information, depending on the subnet and implementation. The axon is the network endpoint validators use to query a miner. If validators cannot discover or reach a miner, the miner may fail to produce useful responses, which can lead to low incentive and low emission. Over time, that can raise pruning risk. Registration alone is not enough. A UID without a reachable, competitive service is a seat waiting to be outcompeted. ## Common Misconceptions About UIDs ### A UID Is Not a Wallet A UID is a subnet-specific seat assigned to a hotkey. It is not a coldkey, a hotkey, or a wallet address. The coldkey can pay for registration. The hotkey receives the UID. The UID is the numbered position inside the subnet. ### A UID Is Not Globally Unique Across Bittensor UIDs are local to each subnet. UID 10 on subnet A and UID 10 on subnet B are different seats in different metagraphs. This is similar to a seat number in two different venues. The number may match, but the location and context differ. ### Immunity Is Not Permanent Protection The immunity period is a grace window, not a permanent guarantee. It can end, it can vary by subnet, and in edge cases an immune neuron can still be pruned if the pruning logic needs to preserve enough non-immune UIDs. ### One Hotkey Can Register on Multiple Subnets A hotkey can hold UIDs on multiple subnets at the same time, but only one UID per subnet. That makes the hotkey a reusable operational identity across subnets, while each UID remains subnet-specific. ## Why UIDs Matter for Bittensor Participants UIDs turn Bittensor's abstract network design into a concrete competitive process. A subnet is not an unlimited list of participants. It has a defined number of UID slots. Participants pay to register, receive a seat, use that seat to perform subnet work, and stay registered by earning enough emission to avoid pruning. For miners, the UID is the seat they need to serve work and compete for incentive. For validators, it is the position through which their subnet activity appears in the metagraph. For learners, it is one of the clearest ways to see how Bittensor combines blockchain registration, decentralized AI work, and competitive emissions. The lifecycle: register, receive a UID, use the immunity period well, earn emission, keep the seat, and get paid at epoch if the hotkey still holds the UID. That lifecycle is why UIDs show up constantly in Bittensor dashboards, support questions, and subnet operations. They are the scarce seats through which hotkeys participate in a subnet. ## Conclusion A UID on Bittensor is best understood as a subnet seat for a hotkey. It is local to one subnet, assigned through registration, tracked in the subnet's metagraph, and paid at epoch if the hotkey still holds that seat. The important details are practical. Registration costs can float. Subnet capacity is limited. Immunity gives new neurons a runway but not absolute protection. Pruning is based on emission, not on whether the participant thinks of itself as a miner or validator. Tempo determines when rewards settle. For anyone learning Bittensor, UIDs bridge high-level concepts and real subnet mechanics. They show how participants enter the network, how competition is enforced, and why emissions ultimately decide who keeps a seat. This article is for educational purposes only and is not financial, investment, legal, or operational advice. Registering, mining, validating, staking, or interacting with Bittensor involves technical and financial risk. Always verify live subnet parameters and official documentation before taking action. ## FAQs ### What Is a UID on Bittensor? A UID on Bittensor is a numbered subnet-specific seat assigned to a hotkey after registration. It identifies the hotkey's position inside that subnet's metagraph. ### Is a UID the Same as a Hotkey? No. A hotkey is an operational key. A UID is the subnet-specific slot assigned to that hotkey after registration. The hotkey can hold UIDs on multiple subnets, but only one UID per subnet. ### How Do You Get a UID on Bittensor? For most non-root subnets, a participant gets a UID by registering with `burned-register`. The coldkey pays the subnet's current floating registration cost, and the hotkey receives the UID. ### Can a UID Be Removed? Yes. If a subnet is full, a new registration can prune an existing neuron. The chain generally selects the lowest-emission non-immune neuron, with tie-break rules based on older registration and then lower UID. ### What Is the Immunity Period on Bittensor? The immunity period is a temporary block-based grace window during which a newly registered neuron is generally protected from pruning. The default is 4096 blocks, but subnet owners can set different values, so check the live subnet setting. ### Does Immunity Guarantee That a UID Cannot Be Pruned? No. Immunity is not absolute. If too many neurons are immune or the non-immune pool is too small, the chain can still prune an immune neuron under the protocol's rules. ### Does Deregistration Take My Stake? Deregistration removes the UID seat, but it does not confiscate ordinary stake. Bittensor's mining guide notes that stake stays where it is. Collateral-enabled subnets can have additional collateral rules. ### When Does a UID Get Paid? A UID gets paid when the subnet epoch fires, according to that subnet's tempo. Rewards go to the hotkey holding the UID at epoch settlement, not continuously every block. ### Are UID Numbers Global Across Bittensor? No. UID numbers are per-subnet. The same UID number can exist on multiple subnets, but each one refers to a different subnet seat. ### Why Do Low-Emission UIDs Get Pruned? Low-emission UIDs get pruned because Bittensor uses emission-based pruning when a full subnet needs to make room for a new registration. Emission is the chain's mechanical signal for which active neuron is least competitive in that subnet.