AI network token
Artificial Superintelligence Alliance FET
The Artificial Superintelligence Alliance (FET) operates its production mainnet (fetchhub-4) on a standard Cosmos SDK / CometBFT stack using secp256k1 and ed25519 cryptography across all critical layers: spend authorization, consensus authentication, P2P node identity, and wallet/custody paths. No post-quantum or hybrid cryptographic protection exists on the current production mainnet. CEO Ben Goertzel has publicly articulated a quantum-oriented vision for the upcoming ASI:Chain (a separate L1 blockchain, currently in closed DevNet beta, with mainnet targeted late 2026/early 2027), describing a modular encryption layer supporting lattice-based and hash-based PQC schemes. However, the ASI:Chain DevNet wallet generator uses secp256k1, no PQC is demonstrable in any public DevNet artifact, no formal specification or algorithm selection has been published, and no independent audit exists. The project receives credit for Stage 2 (Mitigation / Development) due to the existence of ASI:Chain design work, active DevNet, and strong public leadership awareness of quantum threats. The QRI Score of 9/100 reflects a very low factor score (9.06) constrained by the absence of a public cryptographic inventory for the current mainnet (Readiness & Risk Cap: 10), with all production value-at-risk quantum-vulnerable and no current migration path. The score indicates that while mitigation engineering is underway for a future separate chain, current production users have no quantum protection whatsoever.
Roadmap OnlyECC-Only ProductionMitigation / DevelopmentPQ-Aware Leadership
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
2.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0.75 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
2.81 / 35
Security Assessment & Evidence Preparedness
2 / 5
Critical Quantum Blockers
- No public cryptographic inventory for the current production mainnet (fetchhub-4) has been published — quantum-critical properties cannot be systematically verified from public documentation.
- All production spend authorization (transaction signatures) uses secp256k1 and ed25519 — fully vulnerable to Shor's algorithm on a cryptographically relevant quantum computer (CRQC).
- All consensus authentication (validator signatures) uses secp256k1/ed25519 via CometBFT/Tendermint — quantum compromise enables consensus manipulation and finality reversal.
- Material long-exposure quantum-vulnerable value (all native FET balances, validator keys, staking delegations, treasury/exchange custody keys) exists with no migration, freeze, deprecation, burn, or recovery path on the current mainnet.
Key Risks
- All native FET balances on the Fetch.ai mainnet (fetchhub-4) are secured by secp256k1/ed25519 keys, which are fully breakable by a cryptographically relevant quantum computer (CRQC) running Shor's algorithm.
- Validator consensus authentication uses Ed25519/secp256k1; a quantum adversary who compromises validator keys could forge consensus votes, manipulate finality, and halt the chain.
- Long-exposure public keys from historical transactions are permanently recorded on-chain and harvestable now for later decryption (harvest-now, decrypt-later / HNDL attack).
- No freeze, burn, deprecation, or migration mechanism exists for quantum-vulnerable accounts on the current mainnet; all legacy balances remain fully exposed.
- ASI:Chain is a separate blockchain, not a fetchhub-4 upgrade — no documented path exists for FET holders to achieve quantum-safe custody without relying on an unspecified future cross-chain migration whose mechanics are undefined.
- The project's quantum readiness posture depends entirely on a future chain (ASI:Chain) whose PQC implementation is not yet verifiable, audited, or deployed even in testnet, and whose DevNet wallet generator uses secp256k1.
- Bridged FET representations on Ethereum, BSC, and Cardano inherit the quantum vulnerabilities of those host chains, compounding exposure for holders using those representations.
- No public cryptographic inventory exists for the current mainnet, making it impossible to systematically verify all quantum-critical attack surfaces from public documentation.
Assurance Notes
- No independent cryptographic audit of quantum-critical implementation exists for the Fetch.ai mainnet (fetchhub-4) or for ASI:Chain.
- ASI:Chain is a separate L1 blockchain (RChain/CBC Casper lineage, MeTTa smart contract language) currently in closed DevNet beta; its wallet generator uses secp256k1, and no PQC implementation is demonstrable in any public DevNet artifact as of the evaluation date.
- ASI:Chain MainNet is targeted for late 2026 or early 2027 per CoinMarketCap and multiple community sources. The relationship between current FET and ASI:Chain token economics and migration mechanics is undefined.
- CEO Ben Goertzel's public statements (April 2026 BeInCrypto interview, Substack post) describe a modular encryption layer for ASI:Chain supporting 'lattice-based and hash-based schemes' — these are broad family-level descriptions, not a specific algorithm selection, formal specification, or testable implementation.
- No formal quantum-specific incident-response playbook, emergency disclosure process, or governance proposal for quantum vulnerabilities has been published.
- The Autheo third-party integration claiming 'post-quantum sovereign identity' is an opt-in overlay with no evidence of default or mandatory protocol-level protection for FET spend authorization or consensus.
- LayerQu v3.1.0 (methodology ratified 2026-05-01) independently rates Fetch.ai as Migration Stage 0 (Unaware), QRI 22/100. This QRI evaluation assigns Stage 2 because ASI:Chain dev/test work goes beyond pure unawareness, but the low QRI score is consistent with LayerQu's finding that no current production PQC exists.
Non-Scoring Caveats
- ASI:Chain is a separate L1 blockchain under active development (DevNet live, TestNet in progress, MainNet targeted late 2026/early 2027), not a hard fork or upgrade of the current fetchhub-4 mainnet. Migration mechanics from fetchhub-4 to ASI:Chain are undocumented.
- FET exists as ERC-20 and BSC-wrapped tokens on chains that are themselves quantum-vulnerable; bridge security inherits host-chain classical cryptography and bridge signer sets are not evaluated here.
- ASI:Chain's claimed quantum-oriented design and modular PQC encryption layer are based on CEO media interviews (April 2026) and a Substack post; no formal specification, public code repository with PQC modules, or testnet transaction evidence verifying PQC primitive selection was found.
- The ASI:Chain roadmap lists 'Third Party Audits' and 'Performance benchmarking' as 'Not Started' under MainNet V1, confirming that PQC algorithm assurance cannot be independently verified for the future chain either.
- LayerQu v3.1.0 independently scores Fetch.ai as Migration Stage 0 (Unaware), QRI 22/100, which is directionally consistent with this report's finding of no current production PQC protection.
- No formal performance/resource benchmark exists for any claimed lattice-based or hash-based PQC scheme on ASI:Chain.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: CEO Ben Goertzel has publicly discussed quantum threats in detail (April 2026 BeInCrypto interview, Substack post) and referenced Google's quantum paper. A March 2025 mainnet upgrade blog post confirms secp256k1 and ed25519 usage. However, no formal, structured cryptographic inventory document covering all critical quantum-vulnerable surfaces on the current mainnet has been published.
Coverage basis: Public acknowledgment via CEO media statements + implicit inventory via blog post confirming specific cryptographic primitives
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory — quantum-critical properties cannot be systematically verified from public documentation
Assurance: CEO statements are media interviews, not formal technical assessments. The blog post confirms specific primitives (secp256k1, ed25519) but does not constitute a comprehensive inventory of all quantum-vulnerable surfaces.
Project demonstrates strong leadership awareness of quantum threats but lacks the structured cryptographic inventory expected for higher preparedness scores.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: Evidence includes the March 2025 mainnet upgrade blog post confirming secp256k1/ed25519, fetchd source code dependencies, CEO media interviews and Substack post, and the ASI:Chain DevNet documentation. No consolidated evidence record or formal risk assessment document exists.
Coverage basis: Scattered public sources across media, blog, code, and DevNet docs — no consolidated evidence record
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: confidence-only
Assurance: Evidence is distributed across media, blog, and code — no single consolidated risk assessment or evidence document exists. CEO Substack post provides the most detailed technical discussion but remains marketing-adjacent.
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: All transaction signatures on fetchhub-4 use secp256k1 or ed25519 — fully quantum-vulnerable. Confirmed by official mainnet upgrade documentation (v0.14.1) explicitly referencing secp256k1 and ed25519 key import support.
Coverage basis: ECC-only, no PQ/hybrid path
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All production spend authorization is ECC-only (secp256k1/ed25519) — fully breakable by Shor's algorithm on a CRQC
Assurance: Confirmed by official Fetch.ai blog post (March 2025) and fetchhub-4 upgrade documentation explicitly mentioning secp256k1 and ed25519 key import. Cosmos SDK defaults well-established.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths or supports PQ/hybrid controls
Claim: Standard Cosmos SDK bech32 addresses (fetch1...) with public keys exposed on transaction broadcast. Public keys are permanently recorded on-chain once an account signs a transaction. No PQ key derivation, address format, or long-exposure mitigation exists.
Coverage basis: ECC-only account model with long-exposure public keys
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Long-exposure public keys permanently visible on-chain with no PQ mitigation
All historical transaction public keys are permanently exposed on-chain, making them harvestable for future quantum decryption.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable, including validator signatures, VRFs, randomness beacons, threshold signatures, or block certificates
Claim: Validator consensus signatures use Ed25519/secp256k1 via CometBFT/Tendermint — fully quantum-vulnerable. Official docs confirm standard validator signing with private-key cryptographic signatures.
Coverage basis: ECC-only validator consensus authentication
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Validator consensus signatures are ECC-only — quantum compromise enables finality reversal and chain manipulation
Assurance: Cosmos SDK with CometBFT consensus defaults to Ed25519 for validator keys. Official Fetch.ai validator docs confirm standard cryptographic signing.
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable, including commitments, nullifiers, accumulators, script authorization, supply-binding mechanisms, KZG/pairing-based commitments, and bridge verification
Claim: Cosmos SDK uses SHA-256 based IAVL Merkle trees for state commitments, which are quantum-safe (Grover provides only quadratic speedup, yielding 128-bit security). However, IBC bridge verification relies on classical signatures from counterparty chains, and cross-chain state binding is not quantum-hardened.
Coverage basis: Hash-based state commitments are quantum-safe; cross-chain bridge verification is classical
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: SHA-256 Merkle trees provide adequate quantum resistance (128-bit security against Grover). IBC light client verification depends on counterparty chain classical signatures, creating a cross-chain quantum dependency.
No pairing-based or KZG commitments identified in fetchd. Core state integrity is hash-based and quantum-safe, but cross-chain verification inherits classical vulnerabilities.
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable, including ZK proof assumptions, note encryption, viewing keys, stealth addresses, and shielded state
Claim: Fetch.ai mainnet has no shielded transactions, ZK proofs, privacy layer, or stealth addresses.
Coverage basis: Not applicable — no privacy or proof layer exists
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: CometBFT P2P layer uses classical cryptographic identity (Ed25519 node keys) and standard TLS. No PQC or hybrid protection for node identity or transport.
Coverage basis: ECC-only P2P node identity and transport
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: P2P identity is not directly spend-authorization-critical, but node impersonation could enable eclipse attacks. Scored as applicable per QRI spec for PoS chains.
Lower-criticality layer compared to spend authorization and consensus; quantum vulnerability here is a secondary concern.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path or are protected by native satisfied-by-design controls
Claim: ASI Alliance Wallet (Keplr fork), CosmPy, and Ledger hardware wallet support all use standard Cosmos SDK classical key management (secp256k1/ed25519). No PQ signature support exists in any wallet or custody workflow.
Coverage basis: ECC-only wallet/custody paths
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All wallet and custody paths are ECC-only
Assurance: Fetch.ai GitHub organization shows standard Cosmos ecosystem tooling (Keplr fork, CosmPy). No PQ wallet support identified in any public repository.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks across all attack windows
Claim: 0% of native FET value-at-risk on fetchhub-4 is protected by PQC or hybrid-PQC. All native FET balances, staking delegations, and treasury/exchange holdings are secured by quantum-vulnerable ECC keys.
Coverage basis: No migration; <25% coverage — negligible/zero protection
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 100% of production value-at-risk is quantum-vulnerable with no migration path
Assurance: Coverage estimate based on absence of any PQC protection on mainnet. Exact FET distribution between native Cosmos and bridged representations not quantified but all paths are ECC-only.
Score of 1/20 (implementation score 0.05) reflects <25% coverage threshold per QRI Section 9.3.1.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native, including treasuries, exchanges, custodians, bridges, foundations, and major protocols
Claim: No evidence of any treasury, exchange, custodian, bridge, foundation, or protocol-controlled wallet being migrated to PQ-safe controls on the current mainnet.
Coverage basis: No critical wallets migrated
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No evidence of any PQ-safe wallet or custody path in production. ASI Alliance Wallet is a Keplr fork using classical key management.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No public identification, measurement, deprecation, freeze, burn, or policy mechanism for quantum-vulnerable accounts or dormant holdings exists on the current mainnet.
Coverage basis: No legacy identification or mitigation program
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No on-chain analytics, deprecation proposals, vulnerability dashboards, or dormant-account policies identified.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: ASI:Chain is announced as a quantum-oriented L1 with a modular PQC encryption layer; DevNet is live, TestNet in progress, MainNet targeted late 2026/early 2027. However, this is a separate future chain, not a migration plan for the current fetchhub-4 mainnet. Migration mechanics from fetchhub-4 to ASI:Chain are undocumented.
Coverage basis: Roadmap/design for a separate future chain — not current mainnet migration
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Claims are from CEO interviews and community sources. No formal specification, public code repository with PQC modules, or testnet transaction evidence verifying PQC primitive selection was found. ASI:Chain roadmap lists 'Third Party Audits' and 'Performance benchmarking' as 'Not Started' under MainNet V1.
Score reflects existence of a public roadmap with PQC design intentions and active DevNet, but the roadmap does not address the current production system's vulnerabilities.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts are available, default, strongly preferred, mandatory, or complete by design
Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education materials, or migration prompts exist on the current mainnet.
Coverage basis: No migration accessibility on current production
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms exist and exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback into vulnerable systems
Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, mandatory migration deadline) exist on the current mainnet. No exchange, custody, bridge, or wallet coordination for quantum migration has been documented.
Coverage basis: No enforcement mechanisms
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No formal quantum-specific incident-response process, vulnerability disclosure program, or emergency governance framework has been published. Standard Cosmos SDK governance exists for protocol upgrades but no quantum-specific process is documented.
Coverage basis: No quantum-specific IR process
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Standard Cosmos SDK governance exists for protocol upgrades, but no quantum-specific emergency process is documented. This is an assurance-only caveat that does not by itself create a quantum-enabled attack path.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: No PQC algorithms in production. CEO has stated that ASI:Chain's modular encryption layer will support 'lattice-based and hash-based schemes' — these align with NIST-standardized PQC families (ML-DSA/FIPS 204, SLH-DSA/FIPS 205). However, no specific algorithm selection is documented, no PQC code exists in any public repository, and the DevNet wallet generator uses secp256k1.
Coverage basis: Family-level design mention only; no specific algorithm selection, code, or test vectors
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Claim based solely on CEO media interview. No specification, code, test vectors, or implementation exists to verify the claim. 'Lattice-based and hash-based' is a broad family description, not a specific algorithm selection.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope; audit freshness and scope fit are reflected in Confidence
Claim: No independent PQC audit exists for either the current mainnet or ASI:Chain. ASI:Chain roadmap lists 'Third Party Audits' as 'Not Started' under MainNet V1.
Coverage basis: No audit exists
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: No PQC audit is possible because no PQC implementation exists. This is an assurance-only caveat that limits Confidence to Low.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Fetch.ai mainnet code (fetchd) is open-source (Apache-2.0) on GitHub. ASI:Chain is also open-source. However, no PQC implementation exists in either repository to evaluate for quantum-critical reproducibility.
Coverage basis: Open-source codebases exist; no PQC implementation to evaluate
Implementation score: 0.5 · Evidence confidence: High
Issue classification: none · Score treatment: confidence-only
Assurance: Both fetchd and ASI:Chain are open-source with permissive licenses. Score reflects open-source availability; PQC-specific implementations do not exist to evaluate.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: CEO claims ASI:Chain's modular encryption layer allows PQC primitives to be 'plugged in without redesigning the chain or requiring a hard fork.' This is an explicit parameter-agility design claim. However, no specification or implementation exists to verify it, and the DevNet wallet uses secp256k1.
Coverage basis: Design-level claim of modular PQC support; unverified
Implementation score: 0.5 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Claim is unverifiable from public evidence — no specification or implementation exists. The fact that ASI:Chain DevNet wallet uses secp256k1 suggests modular PQC is not yet operational even in DevNet.
Algorithm & Implementation Assurance
Stateful-signature safety (where applicable), side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered
Claim: No stateful PQC signature schemes (XMSS, LMS, or similar) are deployed or planned for deployment on any current production or test network.
Coverage basis: Not applicable — no stateful PQC signatures deployed or planned
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment, block validation, gas/fee markets, mempool policy, archival growth, or validator/node hardware requirements
Claim: CEO acknowledged that computational overhead of PQC is 'a real engineering challenge but not an architectural one.' No formal performance analysis, benchmark, or resource-impact study exists. ASI:Chain roadmap lists 'Performance benchmarking' as 'Not Started.'
Coverage basis: Informal acknowledgment only; no formal analysis
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Informal acknowledgment only. No benchmarks, gas/fee impact analysis, block-size analysis, or validator hardware requirements published. ASI:Chain roadmap lists 'Performance benchmarking' as 'Not Started.'
Report metadata