Qubitcoin QTC

Claim: No public cryptographic inventory or quantum threat model has been published by the project.

Coverage basis: The project has not published any document identifying its cryptographic mechanisms, their quantum vulnerability, affected assets, or attack assumptions.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory or quantum threat model has been published. The quantum vulnerability of ECDSA/secp256k1 transaction signatures is not acknowledged in any official documentation.

Assurance: Evidence is strong that no inventory exists: the official website, GitHub README, and blog posts discuss only qPoW mining and quantum simulation. No document addresses cryptographic quantum risk.

The project's official documentation focuses entirely on qPoW (quantum circuit simulation for mining). The word 'quantum' in project materials refers to quantum computing as a computational resource for PoW, not to quantum-resistant cryptography.

• https://superquantum.io/qubitcoin
• https://github.com/super-quantum/qubitcoin
• https://medium.com/@superquantum

Claim: No public evidence record supports a quantum risk assessment because no assessment has been published.

Coverage basis: No code references, specs, audits, transaction examples, or reproducible analytics addressing quantum vulnerability have been published by the project.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No quantum risk assessment or supporting evidence record has been published.

Assurance: The absence of any risk assessment documentation across all official channels (website, GitHub, blog, Bitcointalk ANN) is clearly verifiable.

While evaluators can derive the cryptographic inventory from public source code, the project itself has not performed or published this work.

• https://github.com/super-quantum/qubitcoin
• https://superquantum.io/qubitcoin

Claim: All transaction signatures use classical ECDSA/secp256k1. No PQC or hybrid-PQC signature support exists.

Coverage basis: Qubitcoin is a Bitcoin Core fork. Bitcoin's ECDSA/secp256k1 signature scheme is inherited unchanged. The qubitcoin-coinbin wallet explicitly states signatures are deterministic per RFC 6979 (ECDSA).

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All spend authorization uses ECDSA/secp256k1. Shor's algorithm on a CRQC can recover private keys from exposed public keys, enabling complete theft.

Assurance: Multiple independent primary sources confirm ECDSA-only signatures: the Bitcoin Core inheritance, the qubitcoin-coinbin wallet README (RFC 6979 deterministic ECDSA), and the qubitcoin-electrum wallet (libsecp256k1 dependency). No source code or documentation suggests any PQC signature integration.

The CoinEx academy article (2025-08-08) claiming PQC transaction validation is contradicted by all primary sources and represents confusion with a different project (QBTC by qubitcoin-finance).

• https://github.com/super-quantum/qubitcoin
• https://github.com/super-quantum/qubitcoin-coinbin
• https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp

Claim: Standard Bitcoin address types expose public keys on-spend (P2PKH, P2WPKH) or at-rest (P2PK, reused addresses, P2TR key-path). No PQ/hybrid controls exist to prevent long-exposure quantum-vulnerable ownership paths.

Coverage basis: Qubitcoin inherits Bitcoin's address model: P2PKH, P2WPKH, P2TR (Taproot), Bech32, SegWit. Public keys are revealed during spending for hash-based addresses and are permanently visible for P2PK outputs and key-path Taproot.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Public keys are exposed on-spend for all address types and permanently on-chain for P2PK outputs and reused addresses. Long-exposure quantum-vulnerable value can be attacked offline with no time constraint.

Assurance: The address model is verifiable from the Bitcoin codebase, the qubitcoin-coinbin wallet (supports SegWit, Bech32, HD BIP32), and the mainnet explorer.

P2PKH and P2WPKH addresses provide short-exposure (on-spend) attack windows. P2PK outputs, reused addresses, and P2TR key-path outputs create long-exposure (at-rest) attack surfaces—the most immediate quantum risk profile.

• https://github.com/super-quantum/qubitcoin-coinbin
• https://explorer.superquantum.io/
• https://github.com/super-quantum/qubitcoin

Claim: Qubitcoin uses Proof-of-Work consensus (qPoW + SHA256/SHA3). There are no validator signatures, BLS threshold signatures, VRFs, randomness beacons, or finality signatures.

Coverage basis: As a PoW Bitcoin fork, consensus is achieved through proof-of-work, not through validator authentication. The qPoW mechanism adds quantum circuit simulation to the hashing process but does not introduce validator signatures.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The PoW architecture is clearly documented in the GitHub README and Bitcointalk announcement. The qPoW mechanism (quantum circuit simulation + SHA256/SHA3) is a PoW variant, not a validator signature scheme.

SHA256 is considered quantum-resistant for preimage resistance (Grover's algorithm provides O(2^128) for 256-bit hash, still infeasible). SHA3 is similarly quantum-safe.

• https://github.com/super-quantum/qubitcoin
• https://bitcointalk.org/index.php?topic=5538348

Claim: State integrity relies on SHA256 Merkle tree commitments (quantum-safe) and ECDSA-based script authorization (quantum-vulnerable). No KZG/pairing-based commitments or bridge verification exist.

Coverage basis: SHA256 Merkle tree provides quantum-safe state commitment (Grover's algorithm gives O(2^128) preimage security). Script authorization uses ECDSA/secp256k1 signature verification, which is quantum-vulnerable. Supply is enforced by consensus rules (block subsidy schedule), not cryptographic commitment.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: ECDSA-based script authorization allows quantum-enabled forgery of state transitions. A quantum attacker can forge signatures to spend any UTXO.

Assurance: SHA256 quantum safety for commitment schemes is well-established. The ECDSA vulnerability in script authorization is inherited from Bitcoin and is verifiable from source code.

The SHA256 commitment structure (Merkle tree, block hash chain) is genuinely quantum-safe, earning partial credit. However, script authorization via ECDSA signature verification creates a quantum-vulnerable state-validation path that overlaps with the spend-authorization vulnerability.

• https://github.com/super-quantum/qubitcoin
• https://github.com/bitcoin/bitcoin/blob/master/src/pubkey.cpp

Claim: Qubitcoin has no privacy layer, no shielded transactions, no ZK proofs, no note encryption, and no stealth address protocol beyond basic Bitcoin-style functionality.

Coverage basis: Qubitcoin is a transparent Bitcoin fork. No privacy-specific cryptographic mechanisms exist.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The absence of any privacy layer is verifiable from the codebase and documentation.

• https://github.com/super-quantum/qubitcoin
• https://superquantum.io/qubitcoin

Claim: P2P networking uses Bitcoin's classical P2P protocol. Node identity and peer authentication rely on classical cryptography.

Coverage basis: The P2P layer is inherited from Bitcoin Core. It uses classical cryptographic mechanisms for transport and node identity.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: P2P compromise in a PoW chain does not directly enable asset theft, signature forgery, or consensus corruption. It is primarily a denial-of-service and eclipse-attack vector. The subfactor is scored but does not create a quantum-critical blocker for asset security.

While the P2P layer is not quantum-safe, the primary quantum threat to asset security is in spend authorization, not P2P transport. P2P attacks could enable transaction censorship or network disruption but not private key recovery.

• https://github.com/super-quantum/qubitcoin

Claim: All official wallets (qubitcoin-coinbin web wallet, qubitcoin-electrum desktop wallet) use ECDSA/secp256k1 exclusively. No PQ/hybrid signing path exists in any wallet or custody workflow.

Coverage basis: The qubitcoin-coinbin wallet explicitly states deterministic ECDSA signatures per RFC 6979. The qubitcoin-electrum wallet depends on libsecp256k1. No wallet supports PQC signatures.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All official wallets use ECDSA exclusively. No PQ/hybrid signing path exists. Users cannot protect funds even if they want to.

Assurance: Wallet code is publicly available on GitHub and clearly shows ECDSA-only signature support.

The qubitcoin-coinbin wallet supports standard Bitcoin features: Multisig, Stealth, HD (BIP32), SegWit, Bech32—all built on ECDSA/secp256k1 key material.

• https://github.com/super-quantum/qubitcoin-coinbin
• https://github.com/super-quantum/qubitcoin-electrum
• https://superquantum.io/qubitcoin

Claim: Approximately 0% of on-chain value is protected from quantum key-recovery attacks. All QTC is held in ECDSA/secp256k1-secured addresses.

Coverage basis: No PQC address format, no hybrid signature scheme, and no migration has occurred. All circulating supply (~2.23M QTC self-reported, ~$3M market cap per CoinMarketCap) is in quantum-vulnerable addresses.

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 100% of on-chain value is quantum-vulnerable with no migration path. Coverage is effectively 0%.

Assurance: Coverage cannot be precisely measured through the block explorer alone, but the absence of any PQC address format or migration mechanism makes 0% protection the only reasonable estimate. Market cap and supply figures are from CoinMarketCap (self-reported).

Per 9.3.1 coverage thresholds, <25% coverage earns a score of 1 out of 20 for this subfactor (Implementation Score = 0.05). The project has no PQC protection whatsoever.

• https://explorer.superquantum.io/
• https://coinmarketcap.com/currencies/superquantum-qubitcoin/
• https://github.com/super-quantum/qubitcoin

Claim: No critical wallets have migrated to PQC or are protected. All wallets—including any treasury, exchange, or foundation-controlled addresses—use ECDSA/secp256k1.

Coverage basis: No evidence of any PQ-protected wallet, treasury, custodian, or exchange address exists. The protocol provides no mechanism for PQ wallet creation.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No critical wallets are quantum-protected. Treasury, exchange, and large-holder addresses are as vulnerable as any user address.

Assurance: The absence of any PQ wallet infrastructure is clearly verifiable. However, specific treasury/foundation addresses are not publicly identified, so large-holder exposure is inferred from the protocol design rather than measured directly.

The project does not publicly identify treasury, foundation, or team-controlled addresses. All addresses on the network use the same ECDSA-based security model.

• https://github.com/super-quantum/qubitcoin-coinbin
• https://github.com/super-quantum/qubitcoin-electrum

Claim: No legacy vulnerable pools have been identified, measured, deprecated, or addressed. All UTXOs are quantum-vulnerable by default, and no mechanism exists to distinguish or handle them.

Coverage basis: The project has not published any analysis of quantum-vulnerable UTXOs, address reuse patterns, or exposed public keys. No deprecation, freeze, or migration mechanism exists.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No identification, measurement, or deprecation of quantum-vulnerable UTXOs has occurred. P2PK outputs and reused addresses with exposed public keys cannot be distinguished or protected.

Assurance: The Bitcoin-style UTXO model means P2PK outputs and reused-address UTXOs have permanently exposed public keys. The project has not attempted to inventory or address these.

Even if the project were to add PQC signature support in the future, legacy UTXOs with exposed public keys (P2PK, reused addresses) would remain quantum-vulnerable without a specific deprecation, burn, or migration policy.

• https://explorer.superquantum.io/
• https://github.com/super-quantum/qubitcoin

Claim: No public PQC migration or quantum-protection roadmap exists. The project's roadmap focuses on quantum simulation improvements (Superdense Consensus, rmsynth) and does not address transaction signature migration.

Coverage basis: The published roadmap (Bitcointalk ANN, GitHub) mentions Superdense Consensus, quantum simulator optimization, and custom wallets. No PQC signature migration is mentioned.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQC migration roadmap exists. The project's roadmap addresses quantum simulation for PoW, not quantum-resistant transaction signatures.

Assurance: The absence of any PQC migration content across all official channels is clearly verifiable.

The project's 'quantum' focus is on using quantum computing as a computational resource (quantum simulation for PoW), not on defending against quantum attacks on cryptography.

• https://bitcointalk.org/index.php?topic=5538348
• https://github.com/super-quantum/qubitcoin
• https://superquantum.io/qubitcoin

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user warnings, education, or migration prompts exist.

Coverage basis: All wallet software (qubitcoin-coinbin, qubitcoin-electrum, qubitcoin-cli) supports only classical ECDSA address creation and signing. No PQ options exist.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQ account creation, wallet support, or user-facing migration tools exist. Users cannot opt in to quantum-safe transaction signing.

Assurance: Wallet code publicly available confirms ECDSA-only support.

Users are given no warnings about quantum vulnerability. The 'quantum' branding may create a false sense of security.

• https://github.com/super-quantum/qubitcoin-coinbin
• https://github.com/super-quantum/qubitcoin-electrum
• https://superquantum.io/qubitcoin

Claim: No migration enforcement mechanisms exist. Legacy ECDSA signing is the only available path. No coordination with exchanges, custodians, or bridges has been evidenced.

Coverage basis: No deprecation schedule, freeze mechanism, legacy-signing disablement, withdrawal restrictions, or unsafe-path blocking exists. No exchange or custody coordination has been documented.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No enforcement mechanisms exist. ECDSA-only signing is the default and only path with no restrictions.

Assurance: The absence of any enforcement mechanism is clearly verifiable from the codebase and documentation.

• https://github.com/super-quantum/qubitcoin
• https://superquantum.io/qubitcoin

Claim: No quantum-specific emergency disclosure, incident-response, or governance process has been published.

Coverage basis: The project's SECURITY.md and documentation contain no quantum-specific incident response procedures. No security contact or disclosure process for quantum vulnerabilities is identified.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: While the absence of a quantum-specific incident-response playbook is notable, it does not independently create a quantum-attack path. The primary blockers are the absence of PQC signatures and migration infrastructure.

The SECURITY.md file in the repository is the standard Bitcoin Core security policy and does not address quantum-specific threats.

• https://github.com/super-quantum/qubitcoin/blob/master/SECURITY.md

Claim: No NIST-standardized or broadly reviewed PQC algorithms are used. The only signature scheme is ECDSA/secp256k1, which is quantum-vulnerable.

Coverage basis: The codebase contains no references to ML-DSA (FIPS 204), SLH-DSA (FIPS 205), FN-DSA (Falcon), or any other PQC algorithm. Only ECDSA/secp256k1 is implemented.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No NIST-standardized PQC algorithms are used. ECDSA/secp256k1 is the only signature scheme.

Assurance: The absence of any PQC algorithm is clearly verifiable from the source code across all repositories.

SHA256 (used for mining and state commitments) is quantum-safe for preimage resistance but does not address the signature vulnerability.

• https://github.com/super-quantum/qubitcoin
• https://github.com/super-quantum/qubitcoin-coinbin
• https://github.com/super-quantum/qubitcoin-electrum

Claim: No independent cryptographic or implementation audit has been performed for any component of Qubitcoin.

Coverage basis: CertiK confirms the project has not been audited by CertiK or any third party. No audit reports are linked from the project website, GitHub, or any secondary source.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The absence of any audit is confirmed by CertiK's project insight page, which shows 'Not Audited By CertiK' and '3rd Party Audit: No'. Even if an audit existed, it would only cover the current classical implementation, not any future PQC migration.

The qPoW mining component has not been independently reviewed for correctness or security. The cryptographic components inherited from Bitcoin Core have undergone extensive community review over many years, but the Qubitcoin-specific modifications (qPoW) have not been independently audited.

• https://skynet.certik.com/projects/superquantum-qubitcoin

Claim: The Qubitcoin codebase is open-source (MIT License) on GitHub, but there is no PQC implementation to be open-source or reproducible.

Coverage basis: The code is publicly available on GitHub under MIT License. However, the quantum-critical scope (PQC signature implementation) does not exist to be open-source.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: The classical codebase is open-source, which is positive for transparency. However, the subfactor concerns the quantum-critical (PQC) implementation, which does not exist.

The classical ECDSA implementation inherited from Bitcoin Core is open-source and has undergone years of community review, but this does not constitute a PQC implementation.

• https://github.com/super-quantum/qubitcoin

Claim: No parameter agility or PQC upgrade path is documented. There is no discussion of how the protocol would transition to new cryptographic algorithms.

Coverage basis: No documentation addresses cryptographic agility, algorithm upgrade procedures, or transition planning for quantum-resistant signatures.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No parameter agility or cryptographic upgrade path is documented. The protocol has no mechanism for transitioning to PQC signatures.

Assurance: The absence of any upgrade-path documentation is clearly verifiable.

The Superdense Consensus multi-task PoW architecture could theoretically support adding new cryptographic tasks, but this is not documented as a PQC migration path and does not address signature scheme migration.

• https://github.com/super-quantum/qubitcoin
• https://superquantum.io/qubitcoin

Claim: No stateful signature schemes (XMSS, LMS, SPHINCS+) are used. The only signature scheme is stateless ECDSA.

Coverage basis: Qubitcoin uses only stateless ECDSA/secp256k1 signatures. Stateful signature safety considerations are not applicable.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The exclusive use of stateless ECDSA is confirmed by source code analysis.

If the project were to adopt XMSS/LMS in a future PQC migration, stateful-signature safety would become an important consideration.

• https://github.com/super-quantum/qubitcoin

Claim: No performance or resource-impact analysis exists for PQC signature schemes in the Qubitcoin context.

Coverage basis: No documentation, benchmarks, or analysis addresses the impact of PQC signature sizes, verification costs, block validation overhead, mempool policy changes, or archival growth.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The absence of any PQC performance analysis is clearly verifiable. This is scored because no PQC implementation exists, making performance analysis moot. If PQC were implemented, this would become a critical assurance factor given the large signature sizes of ML-DSA (3,293 bytes) and SLH-DSA.

PQC signatures like ML-DSA-65 produce ~3,293-byte signatures (vs ECDSA's ~71 bytes). In a UTXO blockchain, this would significantly impact transaction size, block capacity, mempool memory, and archival storage. No analysis of these impacts exists.