Bittensor PyPI Supply Chain

On July 2, 2024 at 19:06 UTC, attackers began draining TAO tokens from Bittensor wallets across the network. By the time the Opentensor Foundation detected the abnormal transfer volume 20 minutes later and placed validators behind a firewall, approximately 32,000 TAO (~$8 million) had been stolen. The attack vector wasn't on Bittensor itself — it was in a malicious PyPI package that had impersonated the legitimate bittensor SDK between May 22 and May 29.

What happened

Bittensor users — node operators, validators, miners — interact with the network through the official bittensor Python SDK, distributed on PyPI. Between May 22 and May 29, 2024, an attacker uploaded a malicious version of the package, bittensor==6.12.2, which masqueraded as a legitimate release.

The malicious package contained code that activated during specific operations: when a user decrypted their coldkey to stake, unstake, transfer, delegate, or undelegate, the package would exfiltrate the decrypted bytecode to a remote server controlled by the attacker.

The compromise was silent and asynchronous: users who downloaded the trojan version unknowingly accumulated risk for weeks until the attacker activated the harvested coldkeys on July 2 and began draining the network.

Aftermath

• The Opentensor Foundation detected the abnormal transfer volume at 19:26 UTC.
• At 19:41 UTC, validators were placed behind a firewall in "safe mode" — preventing nodes from connecting to the chain, halting transactions, and giving the foundation time to investigate.
• The malicious package was removed from PyPI within hours.
• TAO fell roughly 15% on the day to around $230.
• Affected users — those who had downloaded the trojan version and performed key operations — absorbed real losses; the foundation announced support for affected users but could not undo the on-chain transfers.

Why it matters

Bittensor's incident is the textbook supply-chain attack on a blockchain SDK. The compromise was not in the protocol, the keys, the consensus, or the smart contracts — it was in the trusted distribution channel through which users obtain the software that handles their keys. The class of attack has been hitting open-source software for years (event-stream, ua-parser-js, multiple Solana JS packages) but Bittensor's incident was an unusually clean demonstration of how directly the same attack maps onto blockchain custody.

The defensive answers are documented and uneven in adoption:

• Pin package versions in production deployment scripts; never pip install bittensor without a version lock.
• Use cryptographic signing of releases (Sigstore, GPG-signed packages, npm provenance) and verify signatures before installation.
• Decrypt coldkeys in isolated environments — air-gapped signers or HSMs — so that even a compromised SDK cannot exfiltrate them.

The Opentensor Foundation's 35-minute response — from detection to firewall — is one of the faster public incident responses on record, and meaningfully limited the loss. The damage was constrained more by the foundation's reflexes than by the protocol's design.