Staking Precompile
The staking precompile lets Ethereum-style code interact with the staking feature of Subtensor. Through it, an EVM smart contract can reach native staking actions such as adding stake to a hotkey or removing stake from one, rather than those actions being available only through native Bittensor tooling (Staking Precompile, Bittensor EVM Smart Contracts).
What It Represents
A precompile is a contract exposed at a fixed address on the Bittensor EVM that bridges EVM calls to native chain functionality. The staking precompile is the bridge for staking: it lets a contract participate in the same delegation actions the native side exposes, so staking can be driven from the EVM layer instead of requiring a separate native transaction (Bittensor EVM: Examples and Precompiles, Staking Precompile).
The conceptual point is that it connects two layers. The action that ultimately runs is native Subtensor staking; the precompile is the doorway that lets Ethereum-style contracts request it (Bittensor EVM Smart Contracts).
The Calling Contract Acts as the Coldkey
A defining behavior is that the precompile treats the calling contract’s own address as the coldkey, because it cannot see the original caller behind the contract. As a result, the contract itself, not an external user’s coldkey, is the account whose funds back the stake, and it must hold sufficient liquid TAO for the action to succeed (Staking Precompile).
This makes the staking precompile a specific case where an EVM-side address feeds into native coldkey accounting, in contrast to the general rule that an EVM account does not identify a native coldkey (H160 Address, Staking Precompile).
Versioning Context
The documentation describes more than one version of the staking precompile, with an earlier version kept for backward compatibility and a later version that revises how staking amounts are supplied. For readers, the durable idea is that the precompile is a maintained bridge whose exact interface can change across versions, so building against it means confirming the current version rather than assuming a fixed one (Staking Precompile).
Each version sits at its own fixed address on the Bittensor EVM. The staking precompile documentation gives the current V2 address as 0x0000000000000000000000000000000000000805 and the deprecated V1 address as 0x0000000000000000000000000000000000000801 (Staking Precompile).
Distinction from Staking
Staking is the native action of delegating TAO support behind a hotkey through Subtensor. The staking precompile is the EVM entry point that reaches those same native actions from Ethereum-style code, so staking is the underlying capability while the precompile is the EVM-side bridge to it (Staking and Delegation Overview, Staking Precompile).
- Staking — the native delegation action behind a hotkey.
- Staking precompile — the EVM bridge that reaches that action from contracts.
Distinction from H160 Address
An H160 address is the Ethereum-style account identifier used on the Bittensor EVM. The staking precompile is a fixed-address bridge to native staking, a callable entry point rather than an account format (H160 Address, Bittensor EVM Smart Contracts).
- H160 address — an EVM account identifier.
- Staking precompile — a fixed-address bridge reaching native staking.
Distinction from Coldkey
A coldkey is the native ownership key that authorizes staking. When EVM code calls the staking precompile, the calling contract stands in as the coldkey for the resulting stake, so the contract holds that role rather than an external coldkey (Wallets, Coldkeys and Hotkeys in Bittensor, Staking Precompile).
- Coldkey — native ownership key that authorizes staking.
- Staking precompile — EVM bridge where the calling contract acts as the coldkey.
Reader Boundary
This page defines the concept at a high level. It is not a deployment walkthrough, an interface reference, or a guarantee that the precompile’s versions and interface never change. Readers building against it should confirm current details in the EVM documentation.