Feeless L1 smart-contract and decentralized-compute platform
Qubic QUBIC
Qubic is a high-performance, feeless Layer-1 blockchain with a live mainnet processing over 200M transactions per epoch at sub-second finality. Its entire cryptographic stack—spend authorization, consensus authentication, account identity, and wallet paths—relies exclusively on classical ECC (FourQ elliptic curve with SchnorrQ signatures). The project has publicly documented this ECC dependency and has acknowledged the quantum threat in its technical whitepaper and official documentation, briefly mentioning exploratory interest in NTRU and XMSS. However, no PQC design, prototype, testnet, code, migration mechanism, or hybrid protection exists in any critical layer. The network currently has approximately $75-85M in market capitalization, all of which is quantum-vulnerable. CertiK has conducted a performance evaluation (15.52M TPS) but no cryptographic security audit. Qubic receives a QRI Score of 6, placing it firmly in Stage 1 (Quantum Risk Assessed). The score reflects credit for public cryptographic documentation, open-source code, and acknowledged awareness of quantum risk, offset by the complete absence of production PQC protection, migration planning, or concrete mitigation design.
Roadmap OnlyECC-OnlyQuantum-Vulnerable
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
2.75 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0.47 / 15
Migration Status & Value-at-Risk
0.25 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
2.5 / 5
Critical Quantum Blockers
- Active production spend authorization remains entirely ECC-based (FourQ/SchnorrQ signatures). All user accounts, transaction signatures, and wallet paths are ECC-dependent and vulnerable to quantum key-recovery via Shor's algorithm.
- Consensus-critical authentication (Computor tick signing) is ECC-based (FourQ/SchnorrQ), allowing quantum-enabled consensus forgery and finality compromise.
- No PQC or hybrid-PQC protection is deployed in production, testnet, or prototype form for any critical layer.
- Native asset ownership namespace is classical ECC-only; no migration path from current FourQ-based identities to a quantum-safe scheme exists beyond a roadmap mention.
Key Risks
- All user funds (~$75-85M market cap, ~137.9T circulating QUBIC) are secured by FourQ ECC signatures that are fully vulnerable to Shor's algorithm; a sufficiently capable quantum computer could recover private keys from on-chain public keys and authorize unauthorized transfers.
- The 676 Computors sign ticks using the same FourQ/SchnorrQ ECC scheme; quantum compromise of Computor keys would allow an adversary to forge consensus, finalize fraudulent ticks, and potentially rewrite transaction history.
- Public keys are exposed in account addresses and transactions, creating long-exposure quantum attack surfaces for all active accounts and any account that has ever transacted.
- The Vottun Bridge (QBridge) to Ethereum creates a cross-chain quantum dependency; even if Qubic were to implement PQC, wrapped assets on Ethereum would remain vulnerable to quantum attacks on Ethereum's ECC security.
- No migration path, freeze mechanism, deprecation policy, or upgrade framework exists for transitioning from FourQ-based identities to a quantum-safe scheme.
- The high system requirements for Computor nodes (2TB RAM, AVX-512, bare metal) and extremely tight tick times (~0.4s) may constrain the feasibility of deploying PQC algorithms with larger signatures and slower verification without significant architectural changes.
Assurance Notes
- CertiK conducted a mainnet performance evaluation (TPS benchmark) in early 2025, which confirmed 15.52M TPS but does not cover cryptographic security or quantum resistance.
- The CertiK Skynet page shows 'Code Security 10%' and '0 Audits available' under Code Audit History, indicating no publicly available cryptographic security audit for the core protocol.
- A mobile wallet audit by an independent firm is available (November 2025), and a MetaMask Snap audit (Sayfer, September 2024) exists, but neither addresses quantum-cryptographic safety of the core signature scheme.
- The technical whitepaper (v2, repository created March 2026) is marked as a draft and is under active development; the '06-identity-and-crypto.md' section documents FourQ/K12 usage but does not contain a quantum threat assessment.
- The Vottun Bridge (QBridge) to Ethereum creates a cross-chain dependency on Ethereum's ECC security model.
- No performance or resource-impact analysis for potential PQC algorithms (NTRU, XMSS) has been published, despite Qubic's sub-second tick times and high-throughput requirements.
Non-Scoring Caveats
- The CertiK performance evaluation (TPS benchmark) is publicly available and confirms 15.52M TPS, but this does not address cryptographic security or quantum resistance.
- Qubic's high throughput (15.5M TPS verified) and sub-second finality (0.4s per tick) create tight constraints for any future PQC migration; larger PQC signatures and slower verification times may impact network performance, but this is a future operational concern rather than a current quantum vulnerability.
- The Vottun Bridge (QBridge) enables wrapped QUBIC (wQubic) as an ERC-20 token on Ethereum, creating indirect quantum exposure through Ethereum's ECC security model for bridged assets.
- Exploratory mention of NTRU and XMSS in official documentation is not backed by a published design, prototype, testnet, code, or timeline.
- P2P node identity cryptography details are not explicitly documented; the evidence indicates FourQ-based identity, which is quantum-vulnerable for P2P authentication, but this does not directly enable asset theft or consensus compromise.
- No formal quantum-specific disclosure, incident-response, or governance process exists, though a CertiK-hosted bug bounty program is active.
- The bug bounty program includes 'Bad/incorrect usage of cryptography primitives' as a major severity issue, providing a general vulnerability disclosure channel but not specific to quantum threats.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Qubic has publicly documented its use of FourQ ECC, K12 hashing, and SchnorrQ signatures via the official blog post 'Qubic crypto details' (Dec 2023) and the technical whitepaper '06-identity-and-crypto.md'. The whitepaper and official documentation acknowledge the quantum threat and mention exploring NTRU and XMSS.
Coverage basis: Public documentation and source code analysis
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The cryptographic inventory is credible and based on official sources. However, the quantum threat model component is limited to a brief acknowledgement and algorithm name-drops (NTRU, XMSS) without attack assumptions, affected asset analysis, or quantified risk assessment. The whitepaper is a draft and the security-model section was not reviewed.
The cryptographic inventory documents ECC usage well. The quantum threat model is weak—no formal analysis, no attack window classification, no value-at-risk quantification. This limits the Implementation Score to 0.50 (between 'public design/draft' and 'prototype' level).
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: Qubic provides open-source C++ core node code, Go libraries, TypeScript libraries, C# (.NET) libraries, wallet source code, and official documentation referencing FourQ and K12 usage.
Coverage basis: Open-source repositories and documentation
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Code is publicly available and verifiable. Audits for quantum-specific cryptographic scope are absent; existing CertiK audit is performance-focused and the code-security audit report is not publicly linked. The mobile wallet audit exists but does not cover core protocol cryptography.
Strong open-source evidence for implementation verification, but no independent cryptographic audit. Evidence confidence is Medium due to audit gaps.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: Transaction signatures use SchnorrQ on the FourQ elliptic curve. This is classical ECC with no PQC or hybrid component.
Coverage basis: Source code analysis and official documentation
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely ECC-based (FourQ/SchnorrQ). All user transactions are signed with classical ECC signatures that are fully vulnerable to Shor's algorithm.
Assurance: The ECC-only nature of spend authorization is confirmed across multiple primary sources (official documentation, source code, library implementations) with High confidence.
FourQ provides ~128 bits of classical security but zero quantum security. Public keys are exposed in account identities and transaction data. No PQ or hybrid signature path exists.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: Public keys are derived from a 55-character seed via double K12 hashing and FourQ ecc_mul_fixed, then embedded in account addresses/identities. This exposes classical ECC public keys on-chain.
Coverage basis: Source code analysis and official documentation
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Account identities expose FourQ ECC public keys, creating long-exposure quantum attack surfaces. No PQ/hybrid key-derivation or address scheme exists.
Assurance: Key derivation and public key exposure are well-documented. Long-exposure vulnerability confirmed by design.
Public keys are embedded in account identities and visible in all transaction data, creating permanent at-rest attack surfaces for any account that has ever been active.
Production Cryptographic Protection
Consensus-critical authentication (validator signatures, block certificates)
Claim: Computors (validators) sign network ticks using the same FourQ/SchnorrQ ECC scheme. Consensus requires 451/676 signatures for finality.
Coverage basis: Secondary architectural analysis and official documentation inference
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus-critical tick signing by Computors is ECC-based (FourQ/SchnorrQ). Quantum compromise of Computor keys enables consensus forgery and finality compromise.
Assurance: Evidence confidence is Medium for the exact signature mechanism used in consensus voting; the official consensus documentation does not specify the signature algorithm, but secondary sources (BlockandCapital) and the Go library documentation indicate SchnorrQ on FourQ is used for all cryptographic operations including Computor signing.
Compromise of a supermajority (55+%) of Computor private keys via quantum attack would allow an adversary to forge consensus, finalize fraudulent ticks, and rewrite transaction history.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: Qubic uses K12 (KangarooTwelve) hashing for key derivation and likely for state commitments. K12 is a SHA-3-derived hash function with no known quantum vulnerabilities beyond Grover's quadratic speedup.
Coverage basis: Protocol design inference
Implementation score: 0.75 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Evidence confidence is Low because the exact state commitment mechanism (e.g., Merkle tree hash function, accumulator design, supply-binding mechanism) has not been independently verified from code or documentation for quantum safety. The assumption that all state hashing uses K12 is reasonable but not explicitly confirmed for every commitment path.
K12 is generally considered quantum-safe for hashing purposes (Grover's algorithm provides only O(√N) speedup). If all state commitments rely on K12 hashing, this layer would be quantum-safe by design. However, without explicit code-level verification of the commitment scheme, the Implementation Score is capped at 0.75 (optional/design-level).
Production Cryptographic Protection
Privacy and proof layers
Claim: Qubic does not have a native privacy layer, ZK proofs, shielded transactions, or confidential asset mechanisms in production.
Coverage basis: Protocol architecture review
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Marked N/A per QRI architecture-specific guidance; Qubic does not implement a privacy layer.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: Node identity and P2P communication rely on FourQ-based public-key cryptography, as documented in the technical whitepaper and library implementations.
Coverage basis: Protocol documentation and library analysis
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Exact P2P authentication mechanisms are not fully documented in primary sources. Evidence confidence is Medium based on secondary sources and the universal use of FourQ across all Qubic cryptographic operations.
P2P node identity is ECC-based. While this is a quantum vulnerability, it is not directly asset-theft-critical in the same way as spend authorization. Quantum-enabled P2P impersonation could facilitate eclipse attacks or transaction censorship but does not directly enable fund theft.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: All wallet implementations (mobile, web, CLI, .NET, Go, Rust libraries) use FourQ/SchnorrQ ECC for key generation, signing, and verification. No PQ/hybrid wallet path exists.
Coverage basis: Source code and documentation review
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No wallet, custody, or signing workflow supports PQ or hybrid-PQC signatures. All signing paths are ECC-only.
Assurance: Mobile wallet has an independent audit (November 2025) but it does not cover quantum-cryptographic safety. No hardware wallet, HSM, or institutional custody integration for Qubic exists.
The Qubic.NET library provides C# implementations of FourQ, SchnorrQ, and K12 for cross-platform wallet development, confirming ECC-only wallet paths across ecosystems.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery
Claim: All ~$75-85M market cap (137.9T circulating QUBIC) is secured exclusively by FourQ ECC signatures. 0% of value is protected by PQC or hybrid-PQC mechanisms.
Coverage basis: Market data and cryptographic analysis
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 100% of circulating value ($75-85M) is quantum-vulnerable with no migration, freeze, or protection path.
Assurance: Market cap data from CoinMarketCap and CoinGecko as of late May 2026. All accounts use FourQ ECC; no PQC-protected accounts exist.
Coverage is effectively 0%. Implementation Score of 0.05 reflects the <25% coverage tier (score of 1 out of 20 = 0.05).
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) are protected by PQC or hybrid-PQC mechanisms. All use ECC-based accounts.
Coverage basis: Protocol design and absence of evidence for any PQ wallet paths
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Qubic is not PQ-native; all accounts from genesis use ECC. No exchange, custody, or treasury migration to PQ accounts has been reported or is possible under current protocol design.
The Vottun Bridge (QBridge) uses a 2-of-3 multisig governance model on Ethereum; the signer keys for this bridge are Ethereum ECC keys and thus also quantum-vulnerable.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts identified and addressed
Claim: The project acknowledges that all accounts use FourQ ECC, but no specific identification, deprecation, freeze, or migration policy exists for quantum-vulnerable accounts.
Coverage basis: Documentation review
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The cryptographic inventory acknowledges ECC usage, which implicitly identifies all accounts as quantum-vulnerable. However, no structured inventory of vulnerable pools, no deprecation timeline, and no freeze/burn/migration policy exists.
Implementation Score of 0.25 reflects that the vulnerability is acknowledged at a high level (design/proposal stage) but no concrete remediation steps have been taken.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: The Qubic whitepaper and official documentation mention 'exploring algorithms like lattice-based cryptography (e.g., NTRU) or hash-based signatures (e.g., XMSS)' but provide no roadmap, sequencing, activation criteria, timelines, or dependencies.
Coverage basis: Documentation review
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Evidence confidence is Low because the PQ exploration claim is a brief statement in documentation with no supporting design, specification, or timeline. The Qubic roadmap page does not mention post-quantum cryptography.
Implementation Score of 0.25 reflects a public design/draft-level acknowledgement without a concrete roadmap.
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
Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, warnings, education, or migration prompts exist in any Qubic wallet, node software, or documentation.
Coverage basis: Documentation, source code, and wallet analysis
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: High evidence confidence: all wallet paths, documentation, and libraries are ECC-only with no PQ support.
No migration accessibility whatsoever. Users cannot create PQ accounts, cannot sign with PQ keys, and receive no quantum-risk warnings.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms, deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, mandatory migration after deadline
Claim: No enforcement mechanisms, deprecation policies, freeze capabilities, legacy signing restrictions, withdrawal restrictions, unsafe-path blocking, or mandatory migration deadlines exist.
Coverage basis: Documentation and protocol analysis
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: High evidence confidence: no migration enforcement mechanism exists in the protocol design, governance framework, or documentation.
Qubic has a governance framework (GQMPROP, CCF, computor voting) that could theoretically be used to enact migration policies, but no such proposal has been made or designed.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: Qubic has a CertiK-hosted bug bounty program covering blockchain, web, and mobile vulnerabilities, but no quantum-specific incident-response playbook or disclosure process exists.
Coverage basis: Bug bounty program documentation
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: A bug bounty program exists with a maximum payout of $100,000 and covers 'Bad/incorrect usage of cryptography primitives' as a major severity issue. This provides a general vulnerability disclosure channel but is not specific to quantum threats. No quantum-specific IR playbook or governance process is documented.
Implementation Score of 0.50 reflects that a usable disclosure channel exists (bug bounty with defined scope and rewards), but no quantum-specific preparedness has been demonstrated.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: Qubic uses no PQC or hybrid-PQC algorithms in production, testnet, or prototype. All active cryptography is classical ECC (FourQ/SchnorrQ).
Coverage basis: Protocol analysis
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No NIST-standardized or standards-track PQC algorithm is deployed in any capacity.
Assurance: High evidence confidence: the complete absence of PQC is verified across all code repositories and documentation.
NTRU and XMSS are mentioned as exploratory in documentation, but are not NIST-standardized PQC algorithms (XMSS is NIST-standardized for stateful hash-based signatures, NTRU is a NIST finalist). Regardless, neither is deployed or in development.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: CertiK has conducted a performance evaluation for Qubic (15.52M TPS test) and the Skynet page shows 'Final Report Delivered on 4/24/2025', but this appears to be for performance testing, not cryptographic security. No quantum-cryptographic audit has been identified.
Coverage basis: CertiK Skynet and audit documentation
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: The CertiK performance evaluation is publicly available and confirms 15.52M TPS but does not address cryptographic security. The CertiK Skynet page shows 'Code Security 10%' and '0 Audits available' under Code Audit History. The mobile wallet audit (November 2025) and MetaMask Snap audit (Sayfer, September 2024) cover wallet-specific vulnerabilities but not core protocol quantum-cryptographic safety.
Implementation Score of 0.25 reflects that some general security auditing has been conducted but none addresses quantum-cryptographic scope. Audit freshness, scope mismatch, and lack of public reports limit confidence to Low.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Qubic core node (C++), CLI tools, wallet applications, and cryptographic libraries (Go, TypeScript, C#, Rust) are publicly available on GitHub under open-source licenses.
Coverage basis: GitHub repository analysis
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: All core cryptographic implementations are open source and available in multiple languages (C++, C#, Go, TypeScript, Rust). The C++ core node has 30 contributors and 159 releases, indicating active development and reproducibility.
Strong open-source posture with multi-language implementations. The core node requires specialized bare-metal hardware (2TB RAM, UEFI) which limits casual reproducibility, but the protocol logic and cryptography are fully inspectable.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: No documentation exists describing how Qubic's cryptographic parameters could be upgraded to PQC algorithms, how key migration would work, or how protocol changes are deployed.
Coverage basis: Documentation review
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Qubic has an epoch-based upgrade mechanism (weekly epoch transitions with 5-10 minute maintenance windows) and is developing 'seamless updates' for rolling upgrades. However, no cryptographic agility documentation exists for transitioning signature schemes, key formats, or address derivation.
The absence of documented parameter agility means the path to upgrading from FourQ to any PQC scheme is undefined and unvalidated.
Algorithm & Implementation Assurance
Stateful-signature safety (where applicable), side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks
Claim: No stateful PQC signatures (e.g., XMSS/LMS) are used in production. This subfactor relates to risks that would arise if stateful hash-based signatures were deployed.
Coverage basis: Protocol analysis
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Marked N/A for the current production scope. If XMSS (mentioned as exploratory) were to be deployed, this subfactor would become highly applicable due to state-management risks inherent in hash-based signature schemes.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No performance or resource-impact analysis for PQC algorithms (NTRU, XMSS, or any other) has been published. Qubic's extreme throughput (15.5M TPS) and sub-second finality (0.4s tick times) create significant performance constraints for any future PQC deployment.
Coverage basis: Documentation review
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: CertiK has conducted a mainnet TPS benchmark confirming 15.52M TPS peak performance. This benchmark uses the existing ECC scheme. No PQC performance simulation, bandwidth analysis, or tick-time impact study has been conducted. The 4,096 transactions-per-tick parameter (scaled from 1,024 in May 2026) and 2,048-byte max input size suggest the system is optimized for small, fast transactions; PQC signatures (typically 800 bytes to several KB) could significantly impact throughput and tick timing.
This is treated as a note-only caveat because the absence of PQ performance analysis does not create or preserve a current quantum-vulnerable path; it is a forward-looking operational concern. However, it represents a significant risk for any future migration given Qubic's extreme performance requirements.
Report metadata