Bittensor EVM Smart Contracts
A full ethereum virtual machine (EVM) runtime operates as an application layer on top of the Bittensor blockchain (Subtensor). This allows users to:
- deploy most EVM smart contracts on subtensor without changing the code,
- interact with deployed smart contracts on the subtensor blockchain, and
- access standard Ethereum JSON-RPC methods.
Bittensor EVM smart contracts are executed solely on the Bittensor blockchain, not on the Ethereum blockchain.
See:
- Examples and Precompiles
- EVM on Testnet
- EVM on Local Chain
- EVM on Mainnet
- Opentensor Foundation Blogpost: EVM on Bittensor
EVM and Subtensor wallets on the Bittensor blockchian
Bittensor wallets are based on Polkadot-style ss58 addresses, whereas Ethereum uses h160 addresses.
The holder of a private key for an ss58 address based on the corresponding public key can sign transactions on any Bittensor chain for that address. Anyone who creates key-pairs using btcli wallet, for example, holds the private key and the corresponding seed phrase, and hence can sign Bittensor transactions for that wallet.
Similarly, creating an Ethereum wallet gives you control of the h160 private key for the corresponding public key.
You can easily convert an h160 address to an ss58 address, or vice versa, but this does not yield the corresponding private key. This means that if you create a wallet in Bittensor, you will not be able to sign Ethereum contracts with it, nor versa.
The HashedAddressMapping
Every EVM call that touches Substrate state (staking, registering, setting weights) requires a Substrate Account—AccountId32. The runtime derives this from the H160 address using a one-way hash:
AccountId32 = Blake2b_256("evm:" ++ h160_bytes)
This is called HashedAddressMapping. It is deterministic — the same H160 always produces the same AccountId32 — but irreversible. You cannot reconstruct an H160 private key from the AccountId32.
How it works
When a smart contract calls a precompile function—for example, addStake on StakingV2, the contract's own H160 address is hashed to produce the coldkey for the stake position. The stake is held by the contract on-chain, not by the user who called the contract.
Use the AddressMapping precompile (0x80C) to compute the Substrate coldkey for any EVM address.
Types of EVM wallets
In the context of Bittensor EVM we can distinguish between the types of wallets available:
| Type | Created with | Can sign | Used for |
|---|---|---|---|
| EVM wallet | MetaMask or any Ethereum key generator | EVM transactions, precompile calls | Interacting with smart contracts, calling precompiles |
| Bittensor wallet | btcli wallet, Bittensor SDK | Substrate extrinsics | Staking via btcli/SDK, key operations, governance |
The Bittensor EVM uses the standard Ethereum gas model. Gas fees are paid in TAO (not a separate fee token). Always ensure that you have enough TAO in required the EVM wallet to cover the gas fees for each transaction.
Ethereum vs Bittensor EVM smart contract runtime
On the Ethereum network, nodes such as full nodes, validator nodes and archive nodes run the Ethereum Virtual Environment (EVM) run-time environment. Smart contracts operate under this EVM. See the below high-level diagram.
Note that all operations performed by Bittensor EVM are executed solely on the Bittensor blockchain, not on the Ethereum blockchain.
