> ## 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.

# Bittensor v482 Adds Coldkey-Swap Merges, Narrow Validator Proxies, and Miner Payout Fix
- URL: https://www.tao.media/bittensor-v482-adds-coldkey-swap-merges-narrow-validator-proxies-and-miner-payout-fix/
- Published: 2026-10-23T18:04:55.000Z
- Updated: 2026-10-23T18:04:55.000Z
- Description: The runtime upgrade changes how holders consolidate coldkeys and lets validators delegate routine work without granting control over stake.
- Author: Tristan Hillerich
- Tags: Bittensor, News

Bittensor's Subtensor runtime v482 is live on mainnet, allowing an announced coldkey swap to merge into a destination account that already holds stake, hotkeys, or subnet ownership. Previously, those associations caused the swap to fail.

The [v482 release](https://github.com/RaoFoundation/subtensor/releases/tag/v482?ref=tao.media) also introduces two restricted proxy types for validator operations, corrects miner payouts under custom eTAO emission splits, and enables the emission flag by default for newly registered subnets.

The changes affect how holders consolidate accounts, how validators separate operational signing from asset control, and how subnet rewards reach miners. The coldkey-swap change is breaking because existing destinations now trigger a merge rather than an error.

## What a Coldkey-Swap Merge Preserves

A coldkey controls a Bittensor account's funds and ownership relationships; hotkeys handle operational roles such as mining and validation. Moving TAO between accounts does not transfer all those relationships. The announced coldkey-swap process moves the associated onchain state.

Under the [new merge rules](https://github.com/RaoFoundation/subtensor/pull/3267?ref=tao.media), overlapping alpha stake positions on the same hotkey and subnet are added together. Lists of owned and staking hotkeys are combined without duplicates, while subnet ownership, lease interests, unpaid dividends, miner collateral, and pending registrations transfer or merge under their respective accounting rules.

The destination retains its own identity, auto-stake policy, and account preferences when it is already in use or configured. Source auto-stake settings can follow a swap onto an eligible blank destination. Key lineage is recorded for a rename onto a key without staking associations or existing lineage, instead of treating every consolidation as a simple account rename.

Destination restrictions still apply. An account that rejects locked alpha can refuse a source carrying active locks, and a preference against staking-hotkey growth can block additions. Active locks or residual conviction on the destination also prevent admission. Combined hotkeys, stake positions, pending registrations, and lock-processing work are capped so execution stays within bounded computational limits.

Ordinary proxy grants, pending proxy announcements, and the `RealPaysFee` setting remain on the old coldkey. Lease-beneficiary proxies are an exception and move with the lease relationship. Scripts that previously relied on `ColdKeyAlreadyAssociated` to reject an occupied destination need to account for the new behavior; the error's index remains reserved, but the error is no longer returned.

## A Reserved Destination and a Recoverable Announcement

The V2 announcement call, `announce_coldkey_swap_v2`, accepts the destination address directly, validates it before charging the swap fee, and reserves it during the waiting period. Each announcement, including a re-announcement, incurs the key-swap cost.

The reservation prevents another party from registering the address as a hotkey, transferring stake or locks onto it across coldkeys, or executing a competing coldkey swap into it. Those protections address ways an outside party could alter the destination and obstruct the pending swap. The merge PR records fixes and regression tests for both third-party stake transfers and competing legacy swaps into reserved destinations.

The destination account can release its own reservation, and reservations expire after the configured re-announcement window. The legacy hash-based announcement remains available for compatibility, but it does not reserve the destination. SDK and CLI announcement intents now use V2, with `announceColdkeySwapV2` also exposed through the EVM neuron precompile.

A separate [auto-stake protection](https://github.com/RaoFoundation/subtensor/pull/3272?ref=tao.media) snapshots destination-policy eligibility at announcement and authenticates it during execution. This prevents a small unsolicited transfer, commonly called dusting, from causing the source's auto-stake policy to be lost while the reservation is active. Destination protections are still checked, and reservation expiry or release restores current-destination eligibility checks.

Failed execution now preserves the announcement instead of consuming it. For recovery cases, a new root-authorized [reset that keeps the coldkey locked](https://github.com/RaoFoundation/subtensor/pull/3239?ref=tao.media) can clear an announcement and dispute while leaving ordinary account operations restricted. A successful swap to a different coldkey, or a full reset, releases that restriction. Operators can inspect the retained recovery lock with `btcli wallet swap-check`.

## Validator Proxies Separate Weights From Asset Control

The new [Validate and Weights proxy types](https://github.com/RaoFoundation/subtensor/pull/3194?ref=tao.media) let a validator hotkey authorize a separate operations key to perform a limited set of tasks. The validator hotkey, not the coldkey, is the account granting these permissions.

| Proxy Type | Permitted Operations                                                                              | Intended Use                                                                             |
| ---------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Weights    | The 12 weight-setting, commit, reveal, and related variant calls                                  | A third-party weight setter that cannot change serving endpoints or EVM-key associations |
| Validate   | All Weights calls, axon and TLS serving, Prometheus serving, EVM-key association, and commitments | A validator's own operations machine                                                     |

Neither type permits balance transfers, staking, basket trades, root claims, registration, key swaps, child-key management, take changes, or identity changes. They also exclude general-purpose wrappers such as Utility, Proxy, and Multisig calls, preventing those wrappers from becoming a route around the restricted call lists.

A compromised `Validate` delegate could still submit bad weights or redirect the axon endpoint or associated EVM key. `Weights` excludes those endpoint, association, and commitment powers, making it the narrower permission for an external weight-setting service.

The [validator setup guide](https://www.bittensor.com/docs/guides/proxies?ref=tao.media) has operators fund the validator hotkey for the proxy deposit and grant fee, authorize the operations hotkey with `btcli proxy add`, and submit operational calls using `--proxy-for` to identify the validator hotkey. The CLI signs Validate and Weights grants and removals with the wallet's hotkey.

Separately, fee payment through `RealPaysFee` can now follow up to three proxy levels. Each level must independently consent; a delegation does not automatically authorize fee payment throughout the chain.

## Miner Rewards Follow the Funded eTAO Budget

Etao lets subnet owners choose emission allocations within protocol limits. That makes it necessary for Yuma, Bittensor's consensus and reward-allocation system, to pay the miner share actually funded rather than assume a roughly equal split between miner and validator-side budgets.

The [Yuma payout fix](https://github.com/RaoFoundation/subtensor/pull/3269?ref=tao.media) addresses calculations that could underpay or overpay miners when those budgets differed. The developers' example uses a 33% owner, 30% validator, and 37% miner split: miners received 120.6 alpha against a funded miner budget of 133.2 alpha.

Yuma now distributes the accumulated mining budget in proportion to positive incentive scores. A deterministic integer-allocation routine assigns rounding remainders so the full budget is consumed when incentive scores are nonzero. Existing zero-incentive fallback behavior and Null Consensus payouts are preserved. The change does not include compensation for past miscalculated payouts.

For new subnets, the [release integration changes](https://github.com/RaoFoundation/subtensor/pull/3271?ref=tao.media) set `SubnetEmissionEnabled` to true at registration. Owners must still call `start_call` after `StartCallDelay`, root retains the ability to disable emissions, and existing subnets are not migrated to the new default.

The upgrade also fixes a [Null Consensus scheduling stall](https://github.com/RaoFoundation/subtensor/pull/3231?ref=tao.media) identified on testnet. A due Null epoch now receives the block's epoch slot before earlier subnets in storage order, preventing those subnets from repeatedly taking the slot and leaving the Null epoch and later subnets waiting. Blocks without a due Null epoch retain the configured epoch cap and existing ordering.