Proxy Wallets
Proxy wallets are a Bittensor security pattern where one account is allowed to act on behalf of another account. The official Proxies overview describes the protected account as the safe wallet or real account, and the acting account as the proxy wallet.
The goal is controlled delegation. A user can keep the more sensitive wallet in a higher-security environment while allowing a separate proxy account to perform selected operations.
For readers, proxy wallets answer the question of how to delegate authority without exposing the protected account. The delegation is scoped and revocable, which keeps the security benefit separate from full key transfer or key sharing (Proxies overview, Wallets, Coldkeys and Hotkeys).
Why Proxies Matter
The official wallets guide explains that Bittensor wallets use coldkey and hotkey roles for different kinds of authority. Proxy wallets add another layer: a safe wallet can delegate limited action authority to a proxy account rather than being used directly for every supported operation.
The security value comes from limits. The Proxies overview describes proxy types that restrict which categories of calls a proxy can make. It also describes optional delay and announcement behavior, which can give the safe wallet holder time to reject a pending proxy action.
For readers, proxy wallets reduce key exposure rather than eliminate all risk. The security gain depends on how narrowly the proxy’s authority is scoped and whether the safe wallet holder monitors proxy actions. A broad proxy type can still introduce risk if the proxy key is misused, so the proxy type selection and key handling practices for the proxy account both contribute to the overall security model (Proxies overview, Coldkey and hotkey workstation security).
Safe Wallet and Proxy Wallet
The safe wallet is the account being protected. The Working with proxies guide emphasizes that the safe wallet and proxy wallet are separate accounts and that both require careful key handling.
The proxy wallet is the account granted delegated authority. A proxy relationship is most useful when its scope matches the intended operational task. A broad proxy can still create risk, so the official docs recommend using the narrowest proxy type that fits.
For readers, the safe wallet and proxy wallet are not interchangeable. The safe wallet remains the ownership anchor — it controls assets and can revoke proxy authority. The proxy wallet holds delegated operating access that is constrained by the proxy type and can be removed by the safe wallet at any time (Working with proxies, Proxies overview).
Security Boundaries
Proxy wallets do not replace normal key security. The coldkey and hotkey workstation security guide treats coldkey material as highly sensitive, and the proxy documentation warns that proxy benefits depend on using constraints correctly.
Pure proxies are related but different. The pure proxies guide describes them as keyless accounts controlled through a delegator, mainly useful for account indirection patterns such as multisignature setups. For ordinary wallet delegation, regular proxy wallets are the simpler concept.
For readers, security boundaries should be read as complementary layers. Proxy wallets reduce direct coldkey exposure; coldkey and hotkey security practices protect the underlying keys; and proxy type selection limits blast radius if a proxy key is compromised. No single layer covers all risk by itself (Proxies overview, Coldkey and hotkey workstation security).
Multisig Boundary
Proxy wallets and multisig wallets both reduce direct coldkey exposure, but they do it through different control models. The proxy documentation describes a separate proxy account acting for a safe wallet under a scoped proxy type, while the official multisig guide describes a wallet whose actions require approvals from multiple signers.
For readers, proxy wallets are delegated-operation tools, while multisig wallets are shared-approval custody tools. A proxy can make selected calls for a protected account; a multisig setup changes how the protected account’s authority is approved before action.
References: Proxies overview, Secure your Coldkey with a Multisig Wallet
Proxy type scopes
The official Proxies overview groups proxy
permissions into scoped categories rather than granting blanket control of the safe wallet. Any
proxies can perform any call the safe wallet could make, while narrower types such as NonTransfer,
Staking, and Governance limit which extrinsics the proxy may submit. Choosing the narrowest type
that still covers the intended workflow reduces blast radius if a proxy key is misused or
compromised.
The same overview notes that some proxy types support optional delay and announcement behavior. When enabled, a proxy can signal an upcoming action before it executes, giving the safe wallet holder a window to reject the pending call. That pattern is useful for high-value accounts where operational convenience must not remove human review entirely.
Reference: Proxies overview
Delay Protection Requires Active Monitoring, Not Automatic Notice
A delayed proxy does not submit and immediately execute a call. It first announces the call, waits out the configured delay, and only then executes the announced action (Proxies overview).
That delay does not notify the safe wallet holder automatically. The Working with Proxies guide states the delay protects the holder only if they are watching: if a proxy key is compromised, an attacker can announce a call and wait out the delay without interference from anyone who is not actively checking for pending announcements.
That makes monitoring frequency part of the security model, not an optional habit. The same guide recommends checking for pending announcements on a schedule shorter than the configured delay, and revoking any proxy relationship that is not being actively watched, since a dormant delayed proxy is little safer than one with no delay at all (Working with Proxies).
Relationship to Coldkey Swap
Proxy wallets and coldkey swap are related but different parts of Bittensor wallet security vocabulary. A proxy wallet grants a separate account limited, scoped authority to act on behalf of a protected safe wallet, without giving that proxy account full ownership or changing which coldkey controls the safe wallet. Coldkey swap is the on-chain identity migration that replaces a coldkey’s controlling address, moving all associated hotkeys and their registrations to a new coldkey without resetting them. The Proxies overview describes the proxy-wallet delegation model, and the Coldkey Swap documentation describes how ownership can be migrated to a new coldkey while preserving existing hotkey state.
A proxy wallet does not change which coldkey owns the safe wallet — it only grants another account temporary, scoped permission to submit specific categories of calls on the safe wallet’s behalf. Coldkey swap does change the controlling coldkey permanently, replacing the original SS58 address with a new one that inherits the same hotkeys and their registrations. Use a proxy wallet to protect your coldkey by operating through a less exposed account; use coldkey swap when you need to change the controlling coldkey itself — for example, after a security incident or to migrate to a more secure key environment.
References: Proxies overview, Coldkey Swap
Relationship to Coldkeys
Proxy wallets and coldkeys are related but different parts of Bittensor wallet-security vocabulary. A coldkey is the security-sensitive key that controls TAO balances and owns hotkeys, while a proxy wallet is the delegated-authority pattern that allows a separate account to perform limited operations on behalf of a protected coldkey without exposing the coldkey itself to internet-connected environments. The Wallets, Coldkeys and Hotkeys documentation describes coldkeys as the custody anchor that should be kept offline when possible, and the Proxies overview describes proxy wallets as the security pattern for scoped delegation where the safe wallet (coldkey) remains protected while a proxy account handles routine operations.
For readers, the coldkey names the high-security key being protected, while proxy wallets name the delegation mechanism that reduces how often that coldkey must be exposed for operational tasks.
References: Wallets, Coldkeys and Hotkeys, Proxies overview
Relationship to Staking Proxy Attacks
Proxy wallets and staking proxy attacks are related but different parts of Bittensor wallet-security vocabulary. Proxy wallets are the normal delegation pattern where one account acts for a protected wallet with limited authority, while staking proxy attacks describe the specific risk scenario where a compromised staking proxy misuses its delegated authority to perform unfavorable staking operations even though it lacks full transfer authority. The Proxies overview describes proxy wallets as the scoped-delegation security pattern, and Avoid Staking Proxy Attacks explains the residual risk when staking-proxy authority is compromised.
For readers, proxy wallets name the security architecture itself, while staking proxy attacks name the specific threat model where delegated staking authority becomes a value-positioning risk if the proxy account is exposed or misused.
References: Proxies overview, Avoid Staking Proxy Attacks
Relationship to Yuma Consensus
Proxy Wallets and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, proxy wallets names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
Proxy wallet should not be read as coldkey replacement, multisig threshold control, or proof of full wallet authority. It names scoped delegation where a separate account can submit limited call types on behalf of a protected coldkey (Proxies overview).
The Safe Wallet Remains the Protected Coldkey
Proxy documentation describes a safe wallet whose coldkey stays protected while a proxy account performs delegated actions. Delegation changes who may submit certain calls, not which coldkey owns the underlying wallet records (Proxies overview, Wallets, Coldkeys and Hotkeys).
For readers, proxy vocabulary is about authority scoping around an existing coldkey. It should not be confused with coldkey swap, which migrates controlling coldkey identity on chain.
Proxy Types Limit Different Call Categories
The proxies overview lists proxy types that scope which categories of extrinsic a delegate may submit, including staking-related authority that is narrower than full transfer control (Proxies overview, Avoid Staking Proxy Attacks).
A precise claim should name the proxy type being discussed. Staking delegation, transfer authority, and other scoped permissions are related wallet-safety topics but not interchangeable labels.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For proxy wallets, that sequence changes how readers should interpret evidence about delegated authority and proxy account configuration.
In localnet, proxy wallet mechanics can be tested in an isolated environment. Localnet proxy delegation and permission outcomes reflect local chain configuration and do not represent production wallet security state.
On testnet, proxy wallet behavior can be observed in a shared, non-production network. Testnet proxy account interactions are separate from mainnet wallet authority state.
On mainnet, proxy wallets are live Subtensor accounts that use delegated authority to perform on-chain actions on behalf of a controlling coldkey. The Proxies overview documentation describes the proxy wallet mechanics that apply on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A proxy wallet example from one environment should not be read as representing delegation authority or proxy configuration in another environment.