Bittensor
DePIN+1 · Robotics+2Token Transparency Filing
Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
The frontier models we increasingly rely on are built by a handful of corporations, and increasingly the sovereigns behind them. The intelligence they produce inherits their values, biases, and interests. Today there is no competitive alternative. Bittensor creates the alternative to centralized AI the same way Bitcoin became the alternative to fiat.
(Source: About, Bittensor Whitepaper, Bittensor FAQ)
(b) Operational priorities
Each subnet has an owner who is responsible for operating and maintaining the subnet on a go-forward basis. The Rao Foundation is responsible for core protocol and blockchain development while the Opentensor Foundation is responsible for ecosystem events, official announcements, and community and developer programs such as the Novelty Search podcast and the Bittensor Subnet Ideathon. Independent ecosystem companies also fund and maintain core infrastructure. Latent Holdings maintains the Bittensor documentation and ecosystem tools including TAO.app. The blockchain currently uses Proof-of-Authority validation, with plans to (1) transition to a nominated Proof-of-Stake system and (2) implement an onchain governance system.
(Source: About, Community Links, Chain Consensus, SimplyTao Weekly Recap)
(c) High-level project overview
Bittensor is a network composed of subnets, with each subnet using token incentives to coordinate a network of miners around a specific objective. The Bittensor protocol autonomously allocates TAO emissions to the best performing subnets, creating an alternative AI ecosystem that can optimally coordinate resources and labor, at global scale, to produce machine intelligence.
(Source: Bittensor FAQ, Understanding Subnets, Emission)
(d) Primary token functions
TAO is the native token of Bittensor and the ecosystem's reserve asset. The protocol mints TAO each block and directs it toward the highest-performing subnets, allocating it based on how much TAO is staked to each. TAO is also what you use to acquire subnet tokens, pay transaction fees, and register subnets.
(Source: Bittensor FAQ, About, Understanding Subnets, Root Claim: Overview)
(e) Control surface reliance
Currently, the Rao Foundation operates the Proof-of-Authority nodes for the network and only the Triumvirate, a group of entities that hold the network’s sudo keys, has the ability to upgrade the blockchain. Only approved authorities can author blocks or vote on finality, and the authority set can be changed through privileged onchain administration. Bittensor is progressing from Proof-of-Authority to a nominated Proof-of-Stake system coupled with onchain governance. Development work for both transitions is underway. The current roadmap targets the nominated Proof-of-Stake transition within approximately the next year, and Bittensor co-founder Jacob Steeves published a roadmap in June 2026 targeting full decentralization of the protocol by around December 2027.
(Source: Bittensor FAQ, Governance Overview, Senate, Chain Consensus, Crypto Briefing)
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
The project does not operate a primary Labs or DevCo entity. TAO was fair launched with no premine and no entity received a token allocation at issuance. Core protocol development is conducted by the Rao Foundation, and independent ecosystem companies such as Latent Holdings maintain the Bittensor SDK, documentation, and ecosystem tools including TAO.app. (Source: The Block, TAO Synergies Press Release, Community Links) | Labs | ||
Jacob Steeves | Foundation | Core Developer, Rao Foundation | Co-founded Bittensor in 2019 with Ala Shaabana. Former machine learning engineer on the Google Brain team. Served as CEO of the Opentensor Foundation from its founding until stepping down in February 2026. |
Ala Shaabana | Foundation | Co-Founder, Opentensor Foundation | PhD in computer science from McMaster University. Former postdoctoral fellow at the University of Waterloo and software engineer at VMware and Instacart. Stepped aside from his executive role at the Opentensor Foundation in February 2026 and co-founded Crucible Labs. |
Not publicly disclosed | DAO | Triumvirate member (three seats) | Triumvirate members are Opentensor Foundation employees. The foundation has not publicly disclosed the individual identities of the seat holders. |
Not publicly disclosed | DAO | Senate member | Senate seats are held by the top delegate hotkeys by stake. The individual identities behind Senate hotkeys are not publicly disclosed as a formal roster. |
Blockworks note: The Opentensor Foundation has not publicly disclosed its current executive leadership following the February 2026 departures of Jacob Steeves and Ala Shaabana. The Rao Foundation has not publicly disclosed officers beyond Jacob Steeves. |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
Bittensor's onchain governance system does not own or control intellectual property. The Bittensor codebase, including the Subtensor blockchain and the Bittensor SDK, is open source under the MIT License with copyright held by the Opentensor Foundation and Yuma Rao. Trademark ownership is not publicly disclosed.
(Source: Bittensor SDK Repository, Bittensor SDK README)
(b) Contract/admin powers
The Triumvirate holds the sudo keys for the Bittensor blockchain. This gives the Triumvirate the sole ability to pause and upgrade the blockchain. The majority of the Triumvirate must approve upgrade transactions for them to be executed onchain. Under the network's bicameral governance system, the Triumvirate creates proposals and the Senate approves them. A proposal is executed only after it obtains 50 percent plus one approval from the Senate and a member of the Triumvirate closes the proposal. Triumvirate members are Opentensor Foundation employees, while the Senate is formed from the top delegate hotkeys by stake.
(Source: Governance Overview, Senate)
(c) Locked-token rights (conditional)
Staking TAO grants two forms of additional rights. First, staking TAO into a subnet liquidity pool directs the protocol's emission allocation toward that subnet, giving stakers direct influence over how new TAO issuance is distributed across the network. Second, delegates whose hotkeys rank among the top delegate hotkeys by stake hold Senate seats and vote on Triumvirate proposals. Unstaked TAO carries no emission-direction or governance rights.
(Source: Emission, Governance Overview, Senate)
(d) Value accrual & holder rights
TAO tokenholders have the ability to direct the flow of new TAO emissions to subnets. At a high level, when a TAO holder stakes their TAO into a subnet liquidity pool, the protocol uses this as a signal in its TAO emission distribution algorithm. While the algorithm as a whole is more complex and is subject to change, currently, the amount of TAO staked into a subnet’s liquidity pool is a main contributor to the TAO emission distribution algorithm, which gives TAO holders significant economic rights.
TAO is also the base currency of the network and the denominator of every subnet liquidity pool. This structure positions TAO as the reserve currency of the subnet economy, meaning demand for any subnet's productive capacity ultimately flows through to TAO.
The mechanism works in three steps. First, since a fixed number of subnet tokens are emitted to compensate miners for production, expanding a subnet's productive capacity requires its token to appreciate in USD terms. Second, because subnet tokens are bought with TAO, demand for subnet tokens is, mechanically, demand for TAO. Third, because every pool is denominated in TAO, a rising TAO price effectively lifts the USD value of tokens across all subnets simultaneously, raising the productive capacity of the entire subnet economy at once.
The result is that TAO functions as an index on aggregate subnet demand. Growth in any single subnet strengthens the base currency, and a stronger base currency expands capacity everywhere else.
There is no protocol treasury and no revenue distribution mechanism to tokenholders. All TAO enters circulation through protocol emissions.
(Source: Dynamic TAO Whitepaper, Emission, Understanding Subnets)
(e) Dissolution authority
Bittensor does not operate a DAO legal entity and no dissolution or wind-up mechanism for its onchain governance system is publicly disclosed. The Triumvirate and Senate structure can be modified or removed only through blockchain runtime upgrades, which require majority approval by the Triumvirate.
(Source: Governance Overview)
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The Rao Foundation is the primary foundation for Bittensor and is responsible for core protocol and blockchain development. The Rao Foundation's legal form and jurisdiction of incorporation are not publicly disclosed. The Opentensor Foundation, a separate Ontario, Canada based organization that launched the network in January 2021, continues to operate ecosystem programs and supplies the members of the Triumvirate.
(Source: About, Governance Overview, Bittensor Ecosystem Overview)
(b) IP ownership & control
The Rao Foundation hosts and maintains the core Bittensor repositories, including the Subtensor blockchain code, under its RaoFoundation GitHub organization and publishes the official protocol documentation at bittensor.com. The codebase is open source under the MIT License with copyright held by the Opentensor Foundation and Yuma Rao. Trademark ownership and any subsidiary entities of the Rao Foundation are not publicly disclosed.
(Source: RaoFoundation GitHub, Bittensor Documentation, Bittensor SDK README)
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The Rao Foundation develops the protocol code and operates the network's Proof-of-Authority validator nodes. It holds no unilateral authority over DAO governance, treasury actions, token administration, or reward parameters. There is no protocol treasury. Runtime upgrades that change protocol or reward parameters take effect only after majority approval by the Triumvirate, whose members are Opentensor Foundation employees.
(Source: Chain Consensus, Governance Overview)
(d) Powers over DevCo
The project does not operate a primary DevCo, so the Rao Foundation holds no powers over a DevCo.
(e) Contract/admin powers
The Rao Foundation does not hold pause, upgrade, or governance execution authority. Upgrade authority rests with the Triumvirate, which requires majority approval to execute upgrade transactions onchain.
(Source: Governance Overview)
(f) Current economic arrangements and distribution policies
The Rao Foundation operates a validator, which earns validator rewards. These validator rewards are the funding mechanism for the Rao Foundation. No governance-approved, contractual, or programmatic mechanism directs protocol-controlled resources, fees, or token distributions to the Rao Foundation beyond the validator rewards it earns through ordinary network participation.
(Source: Emission)
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The project does not operate a primary DevCo. TAO was fair launched with no premine and no development company received a token allocation at issuance. Core development is conducted by nonprofit-style foundation entities and independent ecosystem companies. Independent companies contributing to the ecosystem include Latent Holdings, which maintains the Bittensor SDK, documentation, and TAO.app, and Tensora Opco Limited, registered at RAK Digital Assets Oasis in Ras Al Khaimah, United Arab Emirates, which operates the TAO.com wallet product. Neither entity was involved in the issuance of TAO at launch.
(Source: The Block, TAO Synergies Press Release, Tensora Group Contact, TAO.com Terms and Conditions)
(b) IP ownership & control
Not applicable. The project does not operate a primary DevCo.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
Not applicable. The project does not operate a primary DevCo.
(d) Powers over Foundation
Not applicable. The project does not operate a primary DevCo.
(e) Contract/admin powers
Not applicable. The project does not operate a primary DevCo.
(f) Current economic arrangements and distribution policies
Not applicable. The project does not operate a primary DevCo. No mechanism directs protocol-controlled resources, fees, revenue, rewards, or token distributions to any development company.
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
- (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
- (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
- (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — The ticker/market symbol.
- (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
- (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
(a) Launch supply totals
The TAO token was fair launched through a Proof-of-Work mechanism with no premine, no token sale, and no insider allocation. Zero tokens were issued at launch and zero tokens were locked at launch. Issuance began on the Kusanagi network in January 2021. Kusanagi was halted in May 2021 and the network relaunched as Nakamoto in November 2021, carrying forward 546,113 previously mined TAO, approximately 2.6 percent of the 21 million maximum supply. From launch until the first halving on December 15, 2025, the protocol emitted 7,200 TAO daily and distributed it throughout the network. Daily emissions are 3,600 TAO after the halving. (Source: Messari, Taostats Halving, ForkLog)
(b) Recipient categories & use of funds
Prior to the Dynamic TAO upgrade in February 2025, TAO was distributed directly to subnet owners, miners, validators, and TAO stakers. After the Dynamic TAO upgrade, TAO is distributed into subnet liquidity pools, with a portion used as price-neutral liquidity injections and the other portion used to acquire subnet tokens. Within each subnet, emissions are divided across three participant groups. | Recipient Category | Share of Subnet Emissions | Use of Tokens | | ----- | ----- | ----- | | Miners | 41% | Compensation for producing the subnet's digital commodity, such as inference, compute, or storage | | Validators and their stakers | 41% | Compensation for scoring miner output, with stakers receiving a share of validator dividends in proportion to delegated stake | | Subnet owners | 18% | Compensation for designing, operating, and maintaining the subnet and its incentive mechanism | (Source: Emission, Dynamic TAO Whitepaper, Understanding Subnets)
(c) Initial price per token (if applicable)
No fixed price was set. TAO was not sold at a token generation event and no price-discovery offering mechanism was used. All TAO enters circulation through protocol emissions, and price discovery occurred on secondary markets after exchange listings. (Source: Messari, The Block)
(d) Ticker / market symbol
TAO (Source: Bittensor FAQ)
(e) Total supply & supply regime
The TAO token supply and dynamics closely mirror those of BTC. The TAO token has a maximum supply of 21 million and follows a halving schedule triggered by issuance thresholds rather than block counts. The first TAO halving occurred on December 15, 2025 as issued supply crossed the 10.5 million threshold, cutting per-block emissions from 1 TAO to 0.5 TAO and daily emissions from 7,200 TAO to 3,600 TAO. The second halving occurs at 15.75 million TAO issued and the third at 18.375 million. Issued supply is 11,267,496 TAO as of August 24, 2026, and this figure changes continuously with ongoing emissions. (Source: Halving Mechanisms, Taostats Halving, Taostats, ForkLog, Staking Rewards)
(f) Initial vesting / release schedules
No vesting or release schedules exist. No tokens were allocated to any recipient category at launch, so no category is subject to vesting. All TAO enters circulation through protocol emissions on the halving schedule described in item (e). (Source: Messari, Taostats Halving)
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
-
Planned but not yet executed airdrop: Not applicable. The project has no planned airdrop.
-
Executed airdrop: Not applicable. The project has never conducted an airdrop and no per-address distribution data exists.
-
No airdrop planned or conducted: Applicable. Bittensor has never conducted an airdrop and does not plan to execute one. TAO was fair launched with no premine and no ICO, and all supply enters circulation through protocol emissions to network participants.
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Blockworks note: The project has not publicly disclosed any market maker agreements or deals. No native TAO tokens were loaned or allocated to market makers by the project. TAO was fair launched with no premine and no project-controlled treasury allocation, so no reserve of native tokens exists from which market maker allocations or loans could have been made.
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Blockworks note: The project has not publicly disclosed any agreements or deals with centralized or decentralized exchanges. No native TAO tokens were allocated or committed for listings and no listing fees paid in native tokens are publicly disclosed. TAO was fair launched with no premine and no project-controlled treasury allocation, so no reserve of native tokens exists from which listing allocations or native-token listing fees could have been paid. TAO trades on centralized exchanges through third-party listings, and the native onchain venue for TAO is the set of protocol-operated subnet liquidity pools in which TAO is paired against each subnet's alpha token.
(Source: The Block, Dynamic TAO Whitepaper)
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
- (c) Date of sale (at least month & year)
- (d) Number of tokens sold (or % of total supply)
- (e) Vesting schedule
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Blockworks note: No prior fundraising, OTC, or discounted market maker token sales have occurred. Bittensor conducted no token sale, no ICO, and no venture capital fundraising against the TAO token. TAO was fair launched with no premine, and all supply has entered circulation through protocol emissions to miners, validators, stakers, and subnet owners. Investors holding TAO acquired it through mining, network participation, or open market purchases.
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.
(a) Date & component affected
Incident date of 2024-07-02, with the attack beginning at 19:06 UTC and the chain placed in safe mode at 19:41 UTC
Malicious package window: downloads between 2024-05-22 19:14 UTC and 2024-05-29 18:47 UTC
Component: the bittensor Python package on PyPI, version 6.12.2. Client-side/SDK supply chain, not the Subtensor chain code itself. The Bittensor mainnet was the affected chain in that transfers were executed on it.
Exposure was limited to users who ran key-decrypting operations in that window: stake add/remove, wallet transfer, root delegate / undelegate / set_take, and subnet register.
(Source: OTF Community Update, The Block Post-Mortem Coverage)
(b) Exploit vector summary
A supply-chain attack via PyPI. An attacker published a package masquerading as the legitimate Bittensor release (6.12.2). Its code captured unencrypted coldkey material at the moment the user decrypted their wallet. The decrypted bytecode was exfiltrated to an attacker-controlled server. With the coldkeys, the attacker was able to sign unauthorized transfers. No consensus, validator, or protocol bug was involved. The compromise was of user key custody through a poisoned dependency.
(Source: OTF Community Update, Halborn)
(c) Quantified impact
Approximately 32,000 TAO, worth roughly 8 million dollars at the time, was drained from compromised user wallets in the July 2, 2024 attack. Onchain investigator ZachXBT attributed unauthorized transfers exceeding 28 million dollars across 32 TAO holders between May and July 2024 to the same supply-chain compromise, including an 11.2 million dollar wallet drain on June 1, 2024. No protocol funds, treasury assets, or chain-level balances were affected. Losses were confined to individual user wallets whose coldkeys were captured.
(Source: CoinDesk, ZachXBT, Rekt News, Bitget News)
(d) Remediation/response taken
Validators firewalled and placed the chain in safe mode to block node connections and stop further transfers. The malicious package was removed from PyPI. The Opentensor Foundation conducted a code review of the Subtensor and Bittensor GitHub repositories. The foundation coordinated with exchanges, sharing attack details to trace the attacker and attempt fund recovery. Users were given guidance to upgrade their wallet version, create a new wallet, and move funds once the chain resumed. The foundation committed to stronger package verification, more frequent external audits, ISO 27001 compliance work, and expanded monitoring of package activity.
(Source: OTF Community Update, The Block Post-Mortem Coverage)
(e) Current status
Resolved. The chain operated in safe mode from July 2 to July 12, 2024, and normal transaction processing resumed on July 12, 2024. The malicious package was removed from PyPI and no further incidents tied to this vector have occurred. Stolen funds have not been publicly reported as recovered and no user reimbursement program has been publicly disclosed.
(Source: Taostats FAQ, OTF Community Update)
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
-
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
-
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
-
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
-
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
-
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
-
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
-
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
-
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
-
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
-
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
-
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
TAO had no conventional TGE and no token sale, so no TGE completion or token delivery obligations exist to be affected by regulatory change. Evolving regulation does affect current token-access channels. TAO.com support pages state that the iOS app is unavailable in multiple jurisdictions due to local regulations, including the United Kingdom, China, Russia, India, and South Korea, and the FAQ states the in-app ability to buy TAO is not available in all countries.
(Source: App Availability by Country, Frequently Asked Questions (FAQs))
Entity-level regulatory changes matter operationally because blockchain validation is performed on a Proof-of-Authority model with Triumvirate members supplied by the Opentensor Foundation, while TAO.com legal materials identify Tensora OpCo Limited as the operator of TAO.com web and app surfaces and state that certain user information may be required for legal, regulatory, business, and reputational due diligence. Enforcement actions, licensing requirements, or forced structural changes affecting these entities would directly affect validation operations and wallet-product access.
(Source: Bittensor FAQ, Governance Overview, TAO.com Terms and Conditions, TAO.com Privacy Policy)
The project publishes no tax guidance for TAO holders. TAO.com terms state that the Functionalities do not provide legal, financial, investment, or tax advice, so tokenholders must assess their own tax obligations based on applicable law and their own circumstances.
(Source: TAO.com Terms and Conditions)
Publicly disclosed service-level restrictions include 18+ eligibility, sanctions-screening requirements, prohibited-jurisdiction restrictions in the terms, country-level app unavailability, and ongoing United Kingdom approval efforts without a disclosed ETA. TAO.com is not the exclusive means of accessing Bittensor, but legal restrictions can materially limit access to specific wallet and purchase flows for users in restricted jurisdictions.
(Source: TAO.com Terms and Conditions, App Availability by Country, Frequently Asked Questions (FAQs))
(b) Protocol, Technology & Security Risks
The protocol operates security controls such as Commit Reveal, which is designed to make validator weight copying unprofitable by delaying visibility of submitted weights, and MEV Shield, which encrypts sensitive transactions until block inclusion. The official weight-copying page states that many large weight copiers historically used a stake-weighted averaging attack and that copied stale weights can wreck a copier's vtrust and emissions after the concealment period. A published Bittensor security policy defines responsible-disclosure channels, report contents, a 48-hour acknowledgement target, and coordinated fix and embargo handling for confirmed issues.
(Source: The Weight Copying Problem, Commit Reveal, MEV Shield, Security Policy)
These controls have important limits. The wallet docs state the coldkey authorizes TAO transfers, staking, subnet management, governance, and hotkey management, while the coldkey-swap docs state a compromised coldkey can require an onchain announcement, a mandatory waiting period, and possible Triumvirate dispute resolution before a frozen wallet is reset. Official address-poisoning guidance states Bittensor wallets share the same address-poisoning vulnerability class as other long-address blockchains, that transactions are irreversible, and that neither the Opentensor Foundation nor Latent Holdings can intervene after theft, scams, or accidental key loss.
(Source: Wallets, Coldkeys and Hotkeys in Bittensor, Rotate or Swap your Coldkey, Address Poisoning Scams: Protect Your Wallet)
At the wallet-product layer, TAO.com states that the app remains non-custodial, that it does not have access to private keys or recovery phrases, and that it does not currently support cold wallets such as Ledger or Trezor. Those design choices reduce intermediary control but leave tokenholders bearing wallet-operation risk directly.
(Source: Frequently Asked Questions (FAQs))
(c) Token Economics, Unlocks & Incentive Risks
Bittensor's current tokenomics depend on continued net TAO inflows into subnets because the emissions docs state that subnets with negative net flows receive zero emissions under the flow-based model.
(Source: Emission, Understanding Subnets)
TAO and alpha issuance are governed by halving schedules and the Dynamic TAO model makes every token supply approach 21,000,000, so holders remain exposed to changing emission rates and subnet-level alpha dilution even without a traditional unlock calendar. The first TAO halving occurred on December 15, 2025, cutting per-block emissions from 1 TAO to 0.5 TAO.
(Source: Halving Mechanisms, Dynamic TAO Whitepaper, Taostats Halving)
Root staking carries allocation-choice risk because holders can either keep alpha dividends or swap them into TAO, and the TAO.com FAQ states that all in-app staking transactions are automatically routed through the TAO.com validator in support of continued product funding and development.
(Source: Root Claim: Overview, Frequently Asked Questions (FAQs))
The competitive subnet model also creates holder-outcome dependency on third parties. Stake currently assigns weights across subnets, subnet operators can locally impose participation requirements such as KYC or KYB, and subnet operators are incentivized through an 18% emissions cut, so holder outcomes depend on stake allocation behavior and subnet-operator design choices across the network.
(Source: The Bittensor Standard)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.
