Documentation / Concepts Bittensor / Chaîne et Runtime
EVM contracts
Dernière vérification le 2026-09-15
Bittensor runs an EVM: deploy and execute smart contracts, and use precompiles to transfer and stake from an EVM wallet.
Smart Contracts
Smart contracts are agreements that are codified in code. When two (or more) parties wish to execute a smart contract, they agree on the terms, and write those terms into code - the smart contract. Upon completion of the smart contract provisions, the contract is executed.
EVM - Ethereum Virtual Machine
EVM is used to execute smart contracts. Generally, this is done on the ethereum blockchain, but in the case of Bittensor, these are run solely on the Bittensor subtensor chain. It allows developers to write and deploy smart contracts in programming languages like Solidity.
It should be noted that EVM is not native to substrate blockchains (like Bittensor.). To enable EVM and smart contracts to be run on Bittensor, an EVM implementation was added.
Once you have created and compiled a smart contract, it must be deployed on the Bittensor (subtensor) EVM.
Once a contract is deployed on the subtensor, any user can call and interact with the contract.
Executing a Smart Contract on Bittensor
A standard Bittensor wallet (your coldkey) is unable to execute smart contracts. Your coldkey wallet is controlled on the Bittensor side of the network (you have your password and 12 word mnemonic of the Bittensor chain).
In order to create a smart contract, you must have an EVM Bittensor wallet.
Create a Bittensor MetaMask coldkey wallet
Inside the MetaMask browser extension, create a new account. Add a network manually:
text
Network name: "Subtensor"
New RPC URL: https://lite.chain.opentensor.ai
Chain ID: 964
Currency symbol: TAOEVM wallet/ Substrate wallet interactions
With an EVM wallet such as MetaMask, you can execute smart contracts. You can also use Bittensor features directly through precompiles: built-in contracts at fixed addresses that call the chain's native functions.
| Precompile | Address (decimal) | What it does |
|---|---|---|
| Balance transfer | 2048 | Send TAO from your EVM wallet to an ss58 (Substrate) address |
| Staking | 2049, 2053 | Add, remove and move stake, including alpha stake on subnets |
| Subnet | 2051 | Register a subnet; read and (as owner) set its hyperparameters |
| Neuron | 2052 | Register a neuron, set or commit weights, serve an axon |
| Proxy | 2059 | Manage proxies for your EVM-mapped account |
| Metagraph, Alpha, UID lookup | 2050, 2056, 2054 | Read subnet and pool state |
Other precompiles cover crowdloans, leasing, drand, ed25519/sr25519 signature checks and more. The full list is in the subtensor precompiles source.
Your Bittensor (Substrate) wallet cannot execute smart contracts directly.
So how do these two types of wallets interact?
EVM wallets on Bittensor
Your EVM wallet (in MetaMask) has an alias address in Bittensor that can receive funds from "regular" Substrate wallets. The alias is derived from your EVM address (a hash of "evm:" plus the address), so it has no private key on the Bittensor side and can't sign Substrate transactions. Any funds transferred into the alias immediately appear in the EVM wallet.
Bittensor wallets on EVM
In a similar way, Bittensor wallets have an alias address on EVM that can receive funds. This EVM 'alias' has no password and cannot be used to execute smart contracts on EVM, but can receive transfers or the execution of smart contracts.
Creating and executing Smart Contracts
The upstream subtensor docs have current guides on running smart contracts on Bittensor:
https://bittensor.com/docs/guides/evm
Contract verification
(from our friends at Taonado)
To verify the source code for a deployed contract on the taostats evm explorer. See hardhat.config.ts for configuration. This does not require a valid config.ts setup with keys etc..
pnpm hardhat verify --network taostats 0xDEPLOYED_CONTRACT_ADDRESS "CONSTRUCTOR_PARAM_0" "CONSTRUCTOR_PARAM_1"
If you run into issues verifying, it is likely an issue with the @openzeppelin/hardhat-upgrades package changes to how contracts are tested before verified. There is a compatibility issue with Blockscout. In particular, HardhatError HH110 : Invalid JSON-RPC response is possible with error: "Action not found."
To fix this, you have to temporarily uninitialize the @openzeppelin/hardhat-upgrades package for the purposes of verifying any contract, which will run the expected verify method which works with Blockscout's RPC.
Root cause is the @openzeppelin/hardhat-upgrades package checks if the address isBeacon by trying to get the implementation() address which the Blockscout eth-RPC returns an error message different than what is expected by the lib, so it incorrectly assumes there is an RPC issue.