DOCSEARCHbyAlgolia
Submit Docs

Bittensor Documentation

website·Indexed 36 days ago

https://www.bittensor.com/docs

Documentation for Bittensor, an open network where independent subnets produce digital commodities. Includes guides for the SDK, btcli, and the subtensor chain, as well as comprehensive migration paths from v9/v10 to v11. Covers core concepts such as TAO emissions, beta tokens, chain consensus, and the metagraph.

Tokens
304.6K
Snippets
1.4K
Records
2.6K
Agent score
72%

What's inside Bittensor

  1. Overview of Bittensor Multisig Wallets

    A multisig wallet in Bittensor removes single points of failure by deriving an account address from a set of coldkeys and a threshold (M-of-N). A call only executes once M of N signatories have approved it. The address is derived deterministically from the sorted signatory set and threshold; no on-chain registration is required. Note that changing the membership set changes the resulting multisig address.

  3. Overview of Bittensor repository scripts

    The scripts/ directory contains tools used for CI/CD, Docker image construction, and manual development. Key scripts include:

    • benchmark_action.sh & benchmark_all.sh: Validate and regenerate benchmark weights.
    • build_all_chainspecs.sh: Rebuilds chainspec JSON files while preserving genesis WASM.
    • docker_entrypoint.sh: Entrypoint for Docker images.
    • fix_rust.sh: Runs fmt, clippy fix, and zepter for code quality.
    • install_build_env.sh & install_prebuilt_binaries.sh: Setup build environments and binaries for localnet/CI.
    • localnet.sh & localnet_patch.sh: Spin up and patch local development chains.
    • srtool/build-srtool-image.sh: Builds the local srtool Docker image.

  4. Overview of EVM Staking via staking-v2 Precompile

    The staking-v2 precompile (address 0x0000000000000000000000000000000000000805) allows EVM accounts and smart contracts to add, remove, move, and transfer stake.

    Coldkey Logic: The precompile uses the caller's ss58 mirror as the coldkey.

    • For Externally Owned Accounts (EOAs), the coldkey is the EVM key's mirror.
    • For smart contracts, the coldkey is the contract address's mirror. The TAO being staked must reside in the contract's balance.

  5. Overview of Bittensor EVM Runtime

    Subtensor runs a full EVM runtime that supports standard smart contracts, eth_* JSON-RPC, MetaMask, Hardhat, and Remix. Contracts execute on the Bittensor chain using TAO as the native currency. The system utilizes two address domains: ss58 (native accounts using sr25519/ed25519) and h160 (EVM accounts using secp256k1).

  6. Overview of Validator roles and requirements

    A validator is a hotkey responsible for scoring miners on a subnet. To function effectively, a validator must:

    1. Be registered on the subnet.
    2. Accumulate sufficient stake (own and delegated) to hold a validator permit.
    3. Set weights that agree with consensus to earn dividends (shared with nominators).

    Validators act as the gateway to a subnet; external applications query miners through a validator's registered hotkey. High-stake validators are prioritized by miners, while weak validators may be ignored.

  7. Overview of the Subnet EVM Precompile

    The Subnet precompile allows for the registration of subnets and exposes selected subnet configurations to the EVM. All state-changing functions in this precompile are payable.
    // Precompile Details
Address: 0x0000000000000000000000000000000000000803
Solidity Interface: ISubnet
Rust Implementation: SubnetPrecompile

  8. Overview of Basket Trading for Root Validators

    Basket trading (introduced in runtime v461) allows root validators to actively manage the composition of their fund's dividends. Dividends accumulate as subnet alpha in a chain-owned escrow account. The swap_basket call is the primary mechanism to rebalance the fund by selling one holding for TAO and using that TAO to buy another holding in a single atomic transaction. A trade changes the fund's holdings but does not change who owns the shares (beta) or the dividend accrual process.

  11. Overview of Bittensor Proxy Accounts

    Proxy accounts allow a primary account (coldkey) to delegate specific operational powers to a secondary 'delegate' key. This improves security by ensuring the primary coldkey holding the funds does not need to be on a networked machine for daily operations. If a delegate key is compromised, the blast radius is limited to the specific proxy type granted, and the delegation can be revoked without moving the principal funds.

  12. Overview of the Bittensor release pipeline

    Shipping is managed via a single pipeline called the 'release train' (release-train.yml) which runs on every push to the main branch. The process follows a strict promotion path: Build once $\rightarrow$ Deploy to Devnet $\rightarrow$ Smoke-check Devnet $\rightarrow$ Deploy to Testnet $\rightarrow$ Smoke-check Testnet $\rightarrow$ Publish SDK release candidate to PyPI $\rightarrow$ Propose Mainnet upgrade via multisig. A separate workflow, watch-mainnet-release.yml, monitors the chain and publishes final release artifacts only after the mainnet upgrade executes.
    push to main
  └─ srtool build (once per train)
       └─ deploy devnet ───── smoke-check devnet
            └─ deploy testnet ── smoke-check testnet ── publish SDK rc to PyPI
                 └─ propose mainnet upgrade (multisig)