Skip to main content

Bittensor

Bittensor — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Bittensor — an AI/Compute project on the Bittensor (Subtensor) network, token (symbol: TAO).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a network/protocol with an incentive economy around a “market for useful computational work” (including ML/AI) via subnets.
  • Who it’s for: subnet developers, miner operators (executors), validators (evaluators), users/integrators who consume the results.
  • Why onchain/token: onchain records state/weights/incentives and distributes rewards; the TAO token is needed for economic incentives and security.
  • What you can actually touch (Tier‑1): there are tutorials for launching a subnet and an example LLM‑inference subnet (architecture/flow challenge→score→weights).

How it works (very briefly)

  1. Participants join subnets: miners provide compute/model/service, validators evaluate the usefulness of the results.
  2. The network aggregates evaluations: validators form weights/rankings of participants per subnet.
  3. Rewards are distributed: issuance/rewards are distributed according to the onchain state and the protocol rules.
  4. Where the blockchain is: onchain stores the network state (metagraph/parameters) and enforces the distribution of incentives/penalties.
  5. Token role: TAO is used as the economic mechanism for incentives/security (rewards to participants, participation in network mechanisms).

Quick links: AI thesis fit

Project passport

Field Value
Project name Bittensor
Also known as (aliases) TAO, OpenTensor
Logo (logo) ../assets/bittensor_logotype_black.svg
Token symbol (ticker) TAO
Category AI/Compute | AI/Training
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) native
Token contract —
Token model (token_type) utility (incentives + security)
Max supply 21 000 000 TAO (hard cap)
Issuance halving schedule; 1 TAO per block (total)
Tokenomics (tokenomics, brief) Issuance is distributed via the onchain emissions mechanics (injection/distribution), including via Yuma Consensus; the distribution at the end of a tempo includes shares for subnet owner / miners / validators+stakers.
Governance onchain governance: Triumvirate (proposals) + Senate (vote)
Admins/keys privileged actions via governance (instead of a single sudo key)
Audit —
Bug bounty —
Team (team) OpenTensor (core contributors)
Funding (investors/funding) —
AI component (ai_component) incentivized ML/AI subnets with quality evaluation
Use‑case (use_case) market for useful ML/AI work + compute
DecAI Fit — AI thesis fit 6/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 3 / token_score 3 / evidence_score 3
Last verified 2026-02-10

General project overview

Bittensor is positioned as a decentralized protocol/network where participants are rewarded for “useful” computational work related to machine learning/AI. The network is organized as a set of subnets (subtasks/markets): each subnet has executors (miners), who deliver a result (model/inference/service), and evaluators (validators), who measure usefulness and form weights/rankings. The onchain part is used to record the network state and distribute economic incentives.

Separately important: the Tier‑1 documentation contains reproducible examples of how subnets are structured and launched (tutorials + an example subnet for LLM inference). This helps distinguish an “idea” from an actually described network mechanism.

Features/modules

  • Subnets: separate markets/tasks where miners compete and validators operate.
  • Metagraph/network parameters: the aggregated state/weights of participants.
  • Incentive economy: rewards to participants for contribution, as determined by the evaluation mechanisms.

Typical scenarios

  • Scenario 1: an operator launches a miner in a chosen subnet → receives TAO rewards when quality/usefulness is competitive.
  • Scenario 2: a validator evaluates miners’ results and publishes weights/scores → influences the distribution of incentives.
  • Scenario 3: a developer creates/develops a subnet (task) → attracts miners/validators and builds an economy around useful work.
  • Scenario 4 (Tier‑1 “demo surface”): a developer launches an example subnet locally/on a testchain following the tutorial and uses the example LLM‑inference subnet (challenge→scoring→weights) as a reference architecture.

Getting started (wallet/network)

  • What you need: a wallet/account for the Bittensor network and access to infrastructure (nodes/providers).
  • Network/chain: Bittensor (Subtensor).
  • Fees: network fees/costs associated with operations on the network and participation in protocol mechanisms (details — in the project documentation).

Architecture/tech (non‑AI)

  • Components: the Subtensor blockchain (state/parameters/incentive distribution), client/node software, the mechanism for tracking subnets and participants.
  • Participant roles: miners (executors), validators (evaluators), users/integrators, infrastructure operators.
  • Where logic runs: computation/evaluation — in participants’ offchain components; state recording and incentive distribution — onchain.
  • Dependencies: — (dependencies and infrastructure requirements depend on the chosen subnet and configuration).

Token/economics (expanded, no forecasts)

  • Token utility: the economic mechanism for rewarding/incentivizing network participants (miners/validators) and for the operation of the protocol.
  • Protocol necessity drivers: without economic incentives the network loses its mechanism of competition for quality and of sustainable reward distribution.
  • Issuance/burn: TAO has a hard cap of 21M and a halving schedule; total issuance — 1 TAO per block (total), distributed across subnets via the onchain emissions mechanics (in two stages: injection and distribution).
  • Security/incentive mechanisms: rewards are tied to evaluations/weights and the onchain state of the network.

Governance

  • Who makes decisions: onchain governance with a bicameral model: the Triumvirate creates proposals, the Senate approves them.
  • How protocol parameters change: via onchain proposals; execution requires (50% + 1) of Senate votes and the closing of the proposal by a Triumvirate member.
  • Admins/keys: previously, some privileged actions required a single sudo key; according to the current Tier‑1 documentation, such actions have been moved into the governance process via the Triumvirate and the Senate.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • System model: the specifics of incentives, validation and result evaluation depend on the particular subnets and their mechanisms.

Project status and timeline

  • Current status: mainnet.
  • Key releases/milestones: Dynamic TAO — mainnet upgrade 2025-02-13; subtensor release notes are published in the official documentation (see links_*).
  • Roadmap: development milestones/plans are published in the repository milestones (see links_*).

Ecosystem/integrations

  • Integrations: —.
  • Partners: —.
  • Where it’s actually used: network activity/state can be observed via the official explorer (see links_*).

AI component of the project

  • What is real AI here? the network is oriented toward markets for useful ML/AI work via subnets, where the quality of results is evaluated and affects rewards.
  • What is truly onchain? onchain stores the network state/parameters and enforces the distribution of incentives (not just token issuance/transfers).
  • Why is a token needed? TAO is needed as an incentive/security mechanism (rewarding participants based on evaluation results/onchain state).
  • Red flags (based on the information found): claims about “SOTA/best models” without reproducible metrics and independent comparisons; mixing marketing descriptions of individual subnets with protocol-level evidence. Even with Tier‑1 tutorials available (AI_2=1), this does not replace quality metrics (AI_3=0).
  • Red flags (based on the information found): claims about “SOTA/best models” without independent benchmarks/comparisons; mixing marketing descriptions of individual subnets with protocol-level evidence. The presence of tutorials and protocol metrics for “how the network evaluates/rewards” does not replace external quality verification of specific models/subnets.

DecAI Fit component summary

  • DecAI Fit: 6/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity high 3
Token necessity high 3
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): In Tier‑1 sources, AI is described as an operating goal/mechanic of the network, not a “plan/intent”.
  • Evidence: Tier‑1 — https://bittensor.com/whitepaper
  • Why sufficient / why not (one line): This “intent” item adds no signal when Tier‑1 already describes a working AI focus/mechanic.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The network organizes a market for useful ML/AI work (models/inference/compute) via subnets with competition on quality.
  • Evidence: Tier‑1 — https://bittensor.com/whitepaper ; https://docs.bittensor.com/
  • Why sufficient / why not (one line): Official sources directly describe the ML/AI purpose and the evaluation/incentive mechanism around it.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): The Tier‑1 documentation contains reproducible tutorials and an example LLM‑inference subnet (example architecture and steps for launching a subnet).
  • Evidence: Tier‑1 — https://docs.bittensor.com/tutorials/basic-subnet-tutorials, https://docs.bittensor.com/subnets/walkthrough-prompting
  • Why sufficient / why not (one line): there is a “how‑to” and an example subnet for LLM‑inference; quality metrics of individual subnets (AI_3) are still not recorded.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 1
  • Metrics: RANK, TRUST, CONSENSUS, INCENTIVE, DIVIDENDS, EMISSION (protocol metrics/scores per subnet that affect incentives).
  • Context (version/date/how measured): the metrics are observable via the metagraph / wallet overview; they are updated according to subnet/epoch rules and reflect validators’ evaluation in the incentive mechanism (context — “Validating in Bittensor” + the description of fields in the overview output).
  • Evidence: Tier‑1 — https://docs.bittensor.com/subnets/register-validate-mine
  • Why sufficient / why not (one line): Tier‑1 describes quantitative metrics and their role in the distribution of emissions/incentives; these are protocol “usefulness evaluation” metrics, not external benchmarks of model quality.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): There is a technical description of the principles/mechanics of the network and of the incentives for ML/AI work.
  • Evidence: Tier‑1 — https://bittensor.com/whitepaper ; https://github.com/opentensor/bittensor
  • Why sufficient / why not (one line): The whitepaper + the open implementation provide sufficient technical context for understanding the mechanics.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Bittensor (Subtensor)
  • Addresses/identifiers: — (within this card we record the existence of the network/explorer; addresses/IDs depend on the entity and are observable in the explorer)
  • Evidence: Tier‑1 — https://bittensor.com/scan ; https://docs.bittensor.com/
  • Why sufficient / why not (one line): The existence of an official explorer and network documentation confirms the onchain component.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: recording of network parameters/state (including the metagraph/weights) and distribution of incentives according to protocol rules.
  • Evidence: Tier‑1 — https://docs.bittensor.com/ ; https://bittensor.com/whitepaper
  • Why sufficient / why not (one line): Onchain is used as part of the network mechanism, not just as a “token on a chain”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, the transparent recording of state/evaluations and the trusted distribution of incentives (the core of the network mechanism) break down.
  • Evidence: Tier‑1 — https://bittensor.com/whitepaper ; https://docs.bittensor.com/
  • Why sufficient / why not (one line): The incentive mechanism and the network state are part of the protocol; “moving them offchain” changes the trust model.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a native token, TAO.
  • Evidence: Tier‑1 — https://docs.bittensor.com/ ; https://bittensor.com/whitepaper
  • Why sufficient / why not (one line): Tier‑1 sources describe the token and its role in the network economy.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): Registering a participant in a subnet (obtaining a UID) has a registration cost in TAO; the paid TAO is “recycled” back into the emissions system.
  • Evidence: Tier‑1 — https://docs.bittensor.com/subnets/recycled-tao
  • Why sufficient / why not (one line): This is a protocol payment/cost of participation (UID registration) in the TAO token, i.e. a token-as-fee mechanism is present (although it is not “pay-per-call” for inference).
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): TAO is used for incentives: rewards to network participants depend on evaluations/weights and the onchain state.
  • Evidence: Tier‑1 — https://bittensor.com/whitepaper ; https://docs.bittensor.com/
  • Why sufficient / why not (one line): The incentive/reward mechanism is described in Tier‑1 as fundamental to the operation of the network.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Governance is tied to stake: the Senate is formed from the top delegate hotkeys and requires a share of the total stake; senators vote on Triumvirate proposals.
  • Evidence: Tier‑1 — https://docs.bittensor.com/governance ; https://docs.bittensor.com/governance/senate
  • Why sufficient / why not (one line): Tier‑1 explicitly links the right to participate in the Senate/voting to the size of the stake (delegated or self‑stake), so the token/stake is used as a governance mechanism.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The token does not look “replaceable” without changing the trusted incentive model.
  • Evidence: Tier‑1 — https://bittensor.com/whitepaper
  • Why sufficient / why not (one line): The incentive economy is the core of the protocol; replacing the token with “just a DB/points” changes the security and motivation of participants.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://bittensor.com/whitepaper The purpose of the network (a decentralized ML/AI network) and the basic mechanics of incentives/evaluation.
Tier‑1 https://docs.bittensor.com/ Official documentation on the network/participants/mechanics and on the use of the onchain component.
Tier‑1 https://docs.bittensor.com/tutorials/basic-subnet-tutorials Reproducible tutorials for launching a subnet (locally/testchain/mainchain) based on the subnet template.
Tier‑1 https://docs.bittensor.com/subnets/walkthrough-prompting An example subnet based on LLM inference: architecture, roles, scoring and the “challenge→response→weights” flow.
Tier‑1 https://bittensor.com/scan The existence of a working network and an observable onchain state via the official explorer.
Tier‑1 https://github.com/opentensor/bittensor Open implementation of the protocol (codebase), confirming the existence of a public technical implementation.
Tier‑1 https://docs.bittensor.com/chain-rel-notes Active network releases/changes (confirmation of the project’s life cycle).
Tier‑1 https://docs.bittensor.com/dynamic-tao/dtao-faq Hard cap of 21M for TAO; issuance procedure (including 1 TAO per block) and the Dynamic TAO context.
Tier‑1 https://docs.bittensor.com/emissions Emissions mechanics: 1 TAO per block (total), injection/distribution stages, tempo and reward distribution proportions.
Tier‑1 https://docs.bittensor.com/subnets/recycled-tao Registration costs in TAO: upon UID registration the cost is “recycled” back into the emissions system.
Tier‑1 https://docs.bittensor.com/governance Onchain governance: Triumvirate/Senate; abandonment of the single sudo key for privileged actions.
Tier‑1 https://docs.bittensor.com/governance/senate Senate requirements (including stake > 2% of total) and the voting procedure for proposals.
Tier‑1 https://docs.bittensor.com/dynamic-tao Date of the Dynamic TAO mainnet upgrade: 2025-02-13.

No comments to display

Back to top