AI network token
Bittensor TAO
Bittensor (TAO) is a Substrate-based blockchain using sr25519 (Schnorr signatures over Curve25519) for all spend authorization, consensus authentication, and node identity. All coldkey and hotkey public keys are long-exposure on-chain. The Opentensor Foundation has not published a post-quantum cryptographic inventory, quantum threat model, or migration roadmap. The MEV Shield pallet uses NIST-standardized ML-KEM-768 for transaction encryption against front-running, demonstrating quantum-awareness, but this does not protect asset ownership from quantum key-recovery attacks. Ecosystem subnets perform quantum computing research, but this is application-layer activity that does not confer quantum resistance to the TAO token or Subtensor protocol. The project inherits the Substrate/Polkadot cryptographic roadmap and would likely depend on upstream PQ signature support. QRI Score of 10 reflects Stage 1 (Quantum Risk Assessed) status capped by the absence of a public cryptographic inventory: quantum risk is implicitly acknowledged through MEV Shield design and ecosystem activity, but no meaningful production protection exists, and no formal risk assessment or migration plan has been published.
ECC-Only SignaturesLong-Exposure Vulnerable KeysNo Public Migration RoadmapPartial Protection
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
5.56 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0.75 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
5.25 / 35
Security Assessment & Evidence Preparedness
0 / 5
Critical Quantum Blockers
- Active production spend authorization is entirely sr25519 (Schnorr/EdDSA over Curve25519). All coldkey and hotkey signatures are quantum-vulnerable to Shor's algorithm.
- No public post-quantum cryptographic inventory or quantum threat model has been published by the Opentensor Foundation.
- No public post-quantum migration roadmap, prototype, testnet, or proposal exists for the Subtensor base layer.
- All on-chain public keys are long-exposure (visible on-chain indefinitely), enabling offline quantum key-recovery attacks with no time constraint.
- Consensus authentication (Aura block production via sr25519, GRANDPA finality via ed25519) is entirely ECC-based and quantum-vulnerable.
Key Risks
- All TAO holdings (coldkeys and hotkeys) are secured by sr25519 signatures vulnerable to Shor's algorithm. A cryptographically relevant quantum computer could recover private keys from on-chain public keys and steal funds with no prior warning.
- Coldkeys control staked TAO and high-value operations. Their public keys are permanently exposed on-chain, creating indefinite attack windows.
- Consensus (Aura + GRANDPA) relies entirely on classical signatures. A quantum-enabled validator could potentially forge blocks or disrupt finality.
- The project has no published migration path, leaving users with no guidance on how or when their assets might be protected.
- Dependence on upstream Substrate/Polkadot PQ development creates timeline uncertainty beyond Bittensor's direct control.
- The EVM compatibility layer (EVM pallet) introduces additional ECDSA/secp256k1 attack surface for smart-contract interactions.
Assurance Notes
- No independent cryptographic audit of Subtensor's signature, consensus, or key-generation primitives has been publicly identified as of June 2026.
- The MEV Shield pallet (runtime v361+) uses NIST-standardized ML-KEM-768 (FIPS 203) for transaction encryption, demonstrating awareness of post-quantum threats, but this protects only transaction privacy against MEV, not spend-authorization or key-ownership against quantum key-recovery attacks.
- Bittensor inherits the Substrate/Polkadot cryptographic roadmap. Polkadot has active RFC discussions on post-quantum primitives, but no production PQ signature support exists in Substrate as of the evaluation date.
- The ecosystem hosts quantum computing subnets (SN48 Quantum Compute, SN63 Enigma) that simulate quantum algorithms and test post-quantum cryptography, but these are application-layer services that do not confer quantum resistance to the TAO token or the Subtensor base layer.
- No formal quantum-specific incident-response playbook exists, though the project has demonstrated general incident-response capability (July 2024 safe-mode activation, March 2026 bittensor-wallet compromise response).
- A supply-chain attack on bittensor-wallet v4.0.2 (March 2026) compromised private keys through a PyPI backdoor. This is a classical software-supply-chain issue, not a quantum vulnerability, but underscores the importance of wallet and key-management security.
Non-Scoring Caveats
- The MEV Shield's use of ML-KEM-768 is a positive signal of cryptographic awareness but protects transaction privacy from MEV, not asset ownership from quantum key recovery. It is scored as a partial credit in the privacy subfactor but does not improve the Production Cryptographic Protection score for spend authorization or consensus.
- Quantum computing subnets (SN48, SN63) are ecosystem-level research infrastructure. They do not constitute protocol-level quantum protection and are recorded as operational/product caveats.
- The March 2026 bittensor-wallet v4.0.2 supply-chain compromise is a classical security incident unrelated to quantum readiness; it is noted for operational context only.
- Bittensor's Substrate architecture enables forkless runtime upgrades, which is favorable for future PQ migration agility, but this is a future capability, not current protection.
Evidence record
Claims and Caveats
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: Bittensor uses EdDSA (sr25519) for coldkey and hotkey signatures on all transactions including transfers, staking, and subnet operations.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All spend authorization is sr25519-only, fully vulnerable to Shor's algorithm.
Assurance: No independent cryptographic audit of signature implementation. Official docs and open-source code consistently confirm sr25519 usage.
Both coldkeys (high-value: transfers, staking) and hotkeys (day-to-day operations) use sr25519. No PQ or hybrid signature option exists.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: SS58 addresses encode public keys and are stored permanently on-chain. Coldkey public keys are exposed in staking, registration, and transfer transactions.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All public keys are long-exposure on-chain, enabling offline quantum key-recovery with no time constraint.
No address-hashing scheme (like P2PKH in Bitcoin) that hides public key until spend. SS58 addresses directly encode the public key. All staking operations expose coldkey public keys permanently.
Production Cryptographic Protection
Consensus-critical authentication (validator signatures, VRFs, block certificates)
Claim: Subtensor uses Aura (sr25519) for block production and GRANDPA (ed25519) for finality, both standard Substrate consensus mechanisms.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus finality and block production rely entirely on quantum-vulnerable ECC signatures.
Standard Substrate Aura+GRANDPA consensus. Validator identities are sr25519/ed25519 keypairs. A quantum-enabled validator could forge blocks or disrupt finality.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: Substrate's storage trie uses Blake2b-256 for merklization. No KZG commitments, pairings, or quantum-vulnerable state-binding mechanisms identified in the core protocol.
Coverage basis: PQ/hybrid usage
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: No formal quantum-specific analysis of state-integrity mechanisms has been published. The hash-based design is inherently quantum-safe (Blake2b-256 provides ~128-bit security against Grover's algorithm), but this has not been independently reviewed for the Bittensor/Subtensor implementation.
Substrate's base trie uses Blake2b-256, which is quantum-safe for preimage resistance. No quantum-vulnerable state-binding primitives (KZG, pairings) are used in the core protocol. Scored at 0.75 (not 1.00) due to absence of formal analysis or documentation confirming quantum safety of the state-integrity layer.
Production Cryptographic Protection
Privacy and proof layers
Claim: MEV Shield (MevShield pallet, runtime v361+) uses ML-KEM-768 (FIPS 203) + XChaCha20-Poly1305 for encrypted transaction submission to prevent front-running.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: MEV Shield uses NIST-standardized PQ cryptography (ML-KEM-768) but only for transaction encryption, not for spend authorization. The inner transactions are still signed with sr25519. This protects against MEV front-running, not against quantum key recovery.
MEV Shield is a positive signal of PQ awareness but provides no protection for asset ownership against quantum attacks. It is opt-in and coldkey-only. Scored at 0.25 (design/prototype-level PQ privacy feature, not a general privacy layer). Bittensor has no shielded pools or ZK proof systems in the core protocol.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: Substrate/libp2p networking uses ed25519/sr25519 for node identity and peer authentication.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Node identity keys are consensus-critical (used for Aura block production and GRANDPA finality); quantum-vulnerable.
P2P node identity cannot be marked satisfied-by-design because validator node keys are directly used for consensus authentication (Aura, GRANDPA), which is a critical applicable layer.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: Bittensor wallets use sr25519 keypairs. No PQ or hybrid wallet support exists. No hardware wallet with PQ support is available for TAO.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ wallet, custody, or HSM path exists for TAO.
Assurance: A cold-storage hardware wallet was announced in May 2026 but uses classical cryptography. The bittensor-wallet v4.0.2 supply-chain compromise (March 2026) highlights key-management risks independent of quantum threats.
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Bittensor has not published a formal cryptographic inventory or quantum threat model. Cryptographic primitives are documented in various locations but not compiled into a quantum-risk assessment.
Coverage basis: native
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No formal public cryptographic inventory or quantum threat model exists from the Opentensor Foundation.
Assurance: Cryptographic primitives can be inferred from public documentation and source code, but no single authoritative inventory document exists. The MEV Shield documentation discusses quantum threats in passing, but this does not constitute a project-wide assessment.
Bittensor is not PQ-native (launched with classical sr25519 signatures). The project does not qualify for the PQ-native exemption in Section 9.1.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: No public evidence record (code references, specs, audits, transaction examples, reproducible analytics) specific to quantum risk has been compiled by the project.
Coverage basis: native
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Third-party community analysis exists (abittensorjourney.com, April 2026) but is not an official project publication.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: 0% of TAO circulating supply is protected from quantum key-recovery attacks. All ~9M+ TAO in circulation is held in sr25519-based accounts with long-exposure public keys.
Coverage basis: migrated value
Implementation score: 0.05 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: <25% of value-at-risk is protected; effectively 0%.
Assurance: Exact circulating supply and stake distribution can be verified on-chain via taostats.io and tao.app. No privacy-preserving features obscure balance measurement. Coverage is 0% — no PQ-protected accounts exist.
All TAO addresses use SS58 encoding of sr25519 public keys. All staked TAO (coldkeys) has permanently exposed public keys on-chain. The project has no mechanism to measure or track quantum-vulnerable value separately from total value because all value is vulnerable.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, foundations, bridges) use PQ or hybrid protection. All use sr25519 coldkeys.
Coverage basis: migrated value
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No critical wallet migration has occurred or is possible.
Assurance: Foundation and large-validator coldkey addresses are visible on-chain via taostats.io. All use standard sr25519 accounts.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts identified and deprecated
Claim: No legacy vulnerable pools have been identified, measured, or deprecated by the project because all accounts are vulnerable and no migration framework exists.
Coverage basis: migrated value
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The project has no mechanism to identify, tag, or deprecate quantum-vulnerable accounts distinct from all accounts, because every account is vulnerable.
This subfactor is applicable because legacy vulnerable value exists. The score is 0 because no work has been done.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap
Claim: Bittensor has no public post-quantum migration roadmap. Community searches of OpenDev calls, Discord, and official channels through April 2026 found zero official mentions of quantum migration planning.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No public roadmap or migration plan exists.
Assurance: Absence confirmed by community research: 8 weeks of OpenDev call notes, 90 days of Discord history, and official announcements page all show no quantum migration discussion. Polkadot (upstream) has active RFC discussions on PQ primitives.
Bittensor is not PQ-native (launched with classical signatures). A migration roadmap is applicable and expected.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
Claim: No PQ or hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, or education exists for the TAO native asset.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ account creation, wallet, or transaction path exists.
All wallet software (btcli, bittensor SDK, bittensor-wallet, Crucible Wallet) uses sr25519 exclusively.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination
Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, mandatory migration deadline) exist.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
No enforcement mechanisms are applicable because no migration path exists to enforce.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum vulnerabilities
Claim: Bittensor has demonstrated general incident-response capability (July 2024 safe mode, PyPI compromise response) but has no quantum-specific incident-response process.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: General security processes exist (SECURITY.md, safe-mode pallet, Senate governance), but no quantum-specific playbook, disclosure process, or emergency upgrade path for quantum vulnerabilities has been published. This is an assurance caveat, not score-reducing, because the absence of a quantum-specific IR plan does not create a current quantum attack path — it affects response readiness if an attack materializes.
Scored at 0.25 for having general security infrastructure (safe mode, security contact, demonstrated response capability) that would be relevant in a quantum incident, even though no quantum-specific planning has been done.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: MEV Shield uses ML-KEM-768 (FIPS 203, NIST-standardized) for transaction encryption. Core signature scheme is sr25519 (non-PQ, not NIST PQC).
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: ML-KEM-768 is a NIST-standardized (FIPS 203) post-quantum KEM. However, it is used only for MEV-protection transaction encryption, not for spend authorization, consensus, or key ownership. The core quantum-critical signature scheme (sr25519) is not NIST PQC.
Partial credit (0.25) for having NIST PQ algorithms in a production pallet, but the critical layers (signatures, consensus) remain entirely classical.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit
Claim: No independent cryptographic audit of Subtensor's signature, consensus, or key-generation primitives has been publicly identified.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: The Opentensor Foundation announced plans for increased security audits in July 2024 but no cryptographic audit results have been published. dApp-level audits (Taoshi by Hacken) exist but do not cover protocol-level signature or consensus cryptography. This is an assurance caveat for the current classical implementation; it is not independently score-reducing for quantum readiness because no PQ implementation exists to audit.
Score is 0.00 because there is no PQ implementation to audit, and no classical cryptographic audit exists either. The absence of audit does not independently reduce the QRI Score beyond what the lack of PQ implementation already captures.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Subtensor is fully open-source (Rust, GitHub) under MIT/Unlicense. The codebase is publicly buildable and verifiable.
Coverage basis: PQ/hybrid usage
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Full source code available. Build instructions documented. 70+ contributors. Regular releases (v3.3.13-393 as of March 2026).
Full credit: the entire Subtensor node, runtime, and pallets are open-source and reproducible.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path
Claim: Substrate's forkless runtime upgrade mechanism (native to the framework) enables cryptographic agility, but no PQ-specific upgrade path or parameter agility plan has been documented for Bittensor.
Coverage basis: PQ/hybrid usage
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Substrate's WASM-based runtime upgrade mechanism is favorable for future PQ migration agility. Bittensor has adopted a predictable weekly release cycle as of 2026. However, no PQ-specific parameter agility plan (e.g., how signature scheme transitions would be managed) has been published.
Partial credit for the Substrate forkless upgrade capability, which is a real architectural advantage. Not full credit because no PQ-specific agility plan exists.
Algorithm & Implementation Assurance
Stateful-signature safety (XMSS/LMS anti-reuse controls, state management)
Claim: Bittensor does not use stateful hash-based signatures (XMSS/LMS). This subfactor is not applicable to the current implementation.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Algorithm & Implementation Assurance
Performance and resource-impact analysis
Claim: No performance or resource-impact analysis for PQ signature/verification has been published because no PQ signature scheme has been implemented or proposed.
Coverage basis: PQ/hybrid usage
Implementation score: 0 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: No PQ signature implementation exists to benchmark. This is not independently score-reducing because the absence of a benchmark does not create a quantum attack path; it would become relevant when a PQ signature scheme is proposed.
Report metadata