QuantumCoin Q

Claim: QuantumCoin documents its hybrid PQC architecture using NIST FIPS 203/204/205 across its website, quantum-resistance page, FAQ, and GitHub README. All critical public-key mechanisms (signatures, KEM, consensus auth, P2P) are inventoried.

Coverage basis: PQ-native with no classical ownership namespace; full credit per Section 7.1 and Section 9.1

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Documentation is thorough and references specific code paths. No independent review of the inventory claims.

Inventory covers signatures (ML-DSA, SLH-DSA, Ed25519), KEM (ML-KEM, X25519), consensus authentication, P2P transport, and address format.

• https://quantumcoin.org/quantum-resistance.html
• https://quantumcoin.org/faq.html
• https://github.com/quantumcoinproject/quantum-coin-go
• https://quantumcoin.org/whitepapers/Quantum-Coin-Blockchain-Quantum-Resistance-Whitepaper.pdf

Claim: Open-source code on GitHub, mainnet explorer (quantumscan.com), and technical whitepapers provide a reproducible evidence base. Mainnet blocks, transactions, and account data are publicly visible.

Coverage basis: PQ-native with no classical ownership namespace; full credit per Section 7.1

Implementation score: 1 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Evidence is self-published and has not been independently audited. Mainnet data is publicly accessible and verifiable.

Mainnet explorer shows block height ~4M as of May 2026, 291 validators, ~18.2T circulating supply, and active coin/token transactions with 32-byte addresses.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://quantumscan.com/
• https://quantumcoin.org/whitepapers.html

Claim: All mainnet transactions require hybrid PQC signatures: ML-DSA (FIPS 204) + SLH-DSA (FIPS 205) + Ed25519 in compact or full mode. Verification requires all component signatures to be valid. Default is mandatory hybrid from genesis.

Coverage basis: PQ-native hybrid-PQC mandatory on mainnet

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Hybrid construction is documented and code is public. No independent audit of signature verification logic. Mainnet explorer confirms transactions are processed successfully.

Two modes: Compact (Ed25519+ML-DSA, SLH-DSA key embedded) for most operations; Full (all three) for defense-in-depth. Both modes require at least two cryptographically independent components.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://quantumcoin.org/quantum-resistance.html
• https://quantumcoin.org/faq.html
• https://quantumscan.com/

Claim: QuantumCoin uses 32-byte addresses (66 hex chars including 0x) derived from hybrid PQC public keys. No classical-only ownership path exists. Address format prevents long-exposure quantum-vulnerable paths.

Coverage basis: PQ-native; all accounts use hybrid PQC keys

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: 32-byte address format documented in integration guide and FAQ. Mainnet explorer confirms 32-byte addresses on-chain. No independent review of address derivation from hybrid keys.

32-byte addresses provide additional security against hash collisions vs Ethereum's 20-byte addresses. Public keys are embedded in signatures and transactions.

• https://quantumcoin.org/integration.html
• https://quantumcoin.org/faq.html
• https://quantumscan.com/
• https://github.com/quantumcoinproject/quantum-coin-js-sdk

Claim: Validator consensus messages (Proposal, Acknowledgment, Precommit, Commit) are signed using the same hybrid PQC signature scheme. Proposal packets use Full mode every 4,096 blocks and Compact mode otherwise. All other consensus messages use Compact mode.

Coverage basis: Hybrid-PQC mandatory for validator authentication

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Consensus signature scheme documented in GitHub README. Deposit-weighted pBFT with hybrid PQC signatures. No independent audit. Mainnet blocks with 291 validators observed on explorer.

Compact mode uses Ed25519+ML-DSA (SLH-DSA public key embedded). An attacker would need to break both Ed25519 (quantum-vulnerable) and ML-DSA (post-quantum) simultaneously to forge a Compact-mode consensus message. Full mode every 4096 blocks adds SLH-DSA signature for defense-in-depth.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://quantumcoin.org/consensus.html

Claim: As a fork of go-ethereum, QuantumCoin uses Keccak256 for the state trie. 32-byte addresses reduce collision risk. No KZG/pairing-based commitments identified. Smart contracts are EVM-compatible with Solidity 7.6.

Coverage basis: PQ-native design; hash-based state integrity with enhanced address size

Implementation score: 1 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Exact state trie construction (Keccak256 confirmed) not independently verified but consistent with go-ethereum fork. No evidence of quantum-vulnerable cryptographic commitments. Modified EVM with 32-byte addresses has not been independently audited.

Keccak256 is a hash function not vulnerable to Shor's algorithm. 32-byte addresses provide 256-bit collision resistance vs 160-bit in standard Ethereum. No ZK/pairing-based state commitments identified. Grover's algorithm reduces security from 256-bit to 128-bit, which remains secure.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://quantumcoin.org/faq.html
• https://quantumscan.com/

Claim: QuantumCoin does not implement a native privacy layer, shielded transactions, or ZK proof systems. No Groth16/PLONK pairing-based proofs are used in the base protocol.

Coverage basis: N/A – no privacy layer exists

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: No privacy features observed in documentation, code, or mainnet activity.

• https://quantumcoin.org/
• https://github.com/quantumcoinproject/quantum-coin-go

Claim: All node-to-node sessions use hybrid X25519 + ML-KEM-768 key establishment unconditionally. Node identity is verified via hybrid PQC key pairs. RLPx protocol rewritten for PQC support with TLS 1.3-style key derivation.

Coverage basis: Hybrid-PQC mandatory for all P2P sessions

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Hybrid KEM is unconditional per README. V1 and V2 both use same KEM; V2 switch date (Aug 21, 2026) is a protocol enhancement, not a security upgrade. No independent audit of RLPx handshake or key derivation.

Both V1 (legacy) and V2 (post-Aug-2026) RLPx handshakes use hybrid X25519+ML-KEM-768. Key derivation follows TLS 1.3-style HKDF. Node identity bound to hybrid PQC key pair used for account signatures.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://github.com/quantumcoinproject/quantum-coin-go/blob/main/p2p/rlpx/README.md

Claim: Desktop wallet and CLI wallet support hybrid PQC key generation and transaction signing. Android wallet in beta. No HSM or institutional custody workflows evidenced.

Coverage basis: Basic wallet support exists; institutional custody paths not evidenced

Implementation score: 0.75 · Evidence confidence: Low

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: Desktop and CLI wallets are available but not independently reviewed. No HSM, hardware wallet, or multi-sig institutional custody documentation found. Native on-chain control path is PQ-secure by design, so custody gaps are operational rather than quantum-critical.

Per Section 7.1, lack of exchange custody attestations does not penalize the score where native on-chain control is PQ-safe by construction.

• https://quantumcoin.org/
• https://github.com/quantumcoinproject/quantum-coin-js-sdk

Claim: All native Q coins exist in PQ-hybrid accounts by design. No classical-only ownership namespace exists. 100% of native circulating supply (~18.2T Q) is protected from quantum key-recovery attacks on the QuantumCoin L1. However, unclaimed multi-fork balances on external chains remain quantum-vulnerable.

Coverage basis: PQ-native; complete-by-design coverage for native asset; external claims are separate migration process

Implementation score: 1 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Material long-exposure quantum-vulnerable value exists in unclaimed multi-fork balances on legacy chains with no deprecation policy. Invokes Readiness & Risk Cap at 55.

Assurance: Coverage is design-guaranteed rather than measured via migration analytics. No independent verification that all accounts on mainnet truly use hybrid-PQC (though all transactions visible on explorer use 32-byte addresses consistent with the design). Unclaimed multi-fork balances on external chains represent quantum-vulnerable value-at-risk.

Circulating supply ~18.2-18.3T Q. All native coins exist on the PQ-native chain. Multi-fork unclaimed balances on external chains (BTC, ETH, DOGE) are outside native scope but represent quantum-vulnerable value-at-risk with no deprecation policy.

• https://quantumscan.com/
• https://quantumcoin.org/faq.html
• https://coinmarketcap.com/currencies/quantumcoin/
• https://snapshot.quantumcoin.org/

Claim: All wallets on QuantumCoin mainnet use hybrid PQC keys by protocol requirement. Exchanges, validators, and large holders cannot create classical-only accounts. On-chain control paths are PQ-secure by design.

Coverage basis: PQ-native; all on-chain wallet control paths are hybrid-PQC

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Exchange custody attestations are absent but not required for scoring per PQ-Native Rule. Validator addresses on explorer use 32-byte format consistent with hybrid PQC.

291 active validators on mainnet, all using 32-byte addresses. No evidence of any classical-only account existing on-chain.

• https://quantumscan.com/
• https://quantumcoin.org/integration.html

Claim: No legacy vulnerable native pools exist on QuantumCoin. The chain launched with hybrid-PQC from genesis. However, unclaimed multi-fork balances on external chains (BTC, ETH, DOGE) are identified but not deprecated.

Coverage basis: PQ-native; no legacy vulnerable pools exist on QuantumCoin by design; external claims are separate

Implementation score: 0.5 · Evidence confidence: Medium

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

Quantum blocker: Unclaimed multi-fork balances on legacy chains remain quantum-vulnerable with no deprecation, freeze, or burn policy.

Assurance: Design-level guarantee for native chain. No independent verification that genesis accounts and all subsequent accounts are hybrid-PQC, but explorer confirms 32-byte address format universally. Multi-fork balances are identified but no deprecation policy exists.

Multi-fork balances from BTC/ETH/DOGE are pre-claim allocations; once claimed, they become native PQ-hybrid Q coins. Pre-claim vulnerability exists on external chains. Snapshot portal mentions a cut-off time but it is not yet specified.

• https://quantumcoin.org/faq.html
• https://quantumscan.com/
• https://github.com/quantumcoinproject/quantum-coin-go
• https://snapshot.quantumcoin.org/

Claim: No ECC-to-PQC migration roadmap is needed because the native asset never had a classical ownership namespace. The multi-fork allocation is documented but lacks detailed sequencing, activation criteria, and dependencies for complete migration.

Coverage basis: Satisfied by design for PQ-native asset; external migration has basic documentation

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: SigAlgSwitchBlock and KemSwitchTime parameters exist in defaults/config.go for algorithm agility. These are PQ-to-PQ enhancements, not ECC-to-PQC migration. Multi-fork allocation documented but lacks detailed migration timeline.

Scored 0.75 because while native asset migration is satisfied by design, the multi-fork migration roadmap lacks sequencing, activation criteria, and completion criteria.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://quantumcoin.org/quantum-resistance.html
• https://quantumcoin.org/whitepapers.html

Claim: All account creation is PQ-hybrid by default. No classical-only account creation path exists. Desktop, CLI, and Android (beta) wallets support hybrid PQC. However, the multi-fork claim process requires classical Ethereum signatures.

Coverage basis: PQ-native for native asset; external migration uses classical signatures

Implementation score: 0.5 · Evidence confidence: Medium

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

Quantum blocker: Migration claim process uses classical Ethereum signatures, creating a quantum-vulnerable path for unmigrated value.

Assurance: Native account creation is PQ-hybrid mandatory. However, the multi-fork claim process requires users to sign with their Ethereum wallet (classical ECDSA), creating a quantum-vulnerable path during migration.

Scored 0.5 because while native account creation is PQ-native, the external migration process uses quantum-vulnerable classical signatures.

• https://quantumcoin.org/
• https://github.com/quantumcoinproject/quantum-coin-js-sdk
• https://quantumcoin.org/getting-coins-for-tokens-cli-wallet.html

Claim: Enforcement is inherent for native asset: classical-only accounts cannot be created on QuantumCoin mainnet. However, no enforcement mechanism or deadline exists for multi-fork balance claims.

Coverage basis: Satisfied by design for PQ-native asset; external migration lacks enforcement

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: Protocol-level enforcement for native asset: hybrid PQC signatures are mandatory for all transactions. However, no enforcement mechanism, deadline, deprecation policy, or coordination with exchanges/custodians documented for multi-fork migration.

Scored 0.5 because native asset enforcement is satisfied by design, but external migration enforcement is absent with no deprecation timeline.

• https://quantumcoin.org/integration.html
• https://github.com/quantumcoinproject/quantum-coin-go
• https://snapshot.quantumcoin.org/

Claim: No formal quantum-specific incident-response playbook, vulnerability disclosure process, or emergency governance mechanism is publicly documented.

Coverage basis: No formal process documented

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Per Note-Only Caveat Rule, absence of a formal quantum-specific incident-response playbook is an assurance-only caveat that does not reduce the QRI Score unless it leaves a current quantum-vulnerable path unresolved. No such path is identified. Community Discord/Telegram channels exist but are not formal incident-response mechanisms.

Score of 0.25 reflects basic community communication channels and public GitHub issue tracker; no structured quantum-specific IR process.

• https://quantumcoin.org/
• https://github.com/quantumcoinproject/quantum-coin-go

Claim: Uses finalized NIST standards: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and ML-KEM (FIPS 203) in hybrid mode with Ed25519 (FIPS 186-5) and X25519.

Coverage basis: NIST-standardized algorithms in hybrid construction

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Algorithm selection is well-documented and references specific NIST FIPS standards. This subfactor scores on algorithm choice, not implementation correctness.

Hybrid construction follows NIST/ANSSI/BSI transition guidance. Compact and Full modes documented with algorithm IDs in crypto/crypto.go.

• https://quantumcoin.org/quantum-resistance.html
• https://quantumcoin.org/faq.html
• https://github.com/quantumcoinproject/quantum-coin-go

Claim: No independent audit of the hybrid PQC implementation, CIRCL fork, consensus modifications, P2P protocol, or modified EVM has been identified in public sources.

Coverage basis: No independent audit exists

Implementation score: 0 · Evidence confidence: None

Issue classification: quantum-critical uncertainty · Score treatment: confidence-only

Assurance: Open-source code is publicly available for review but has not been independently audited. Mainnet operation demonstrates functional correctness but not cryptographic correctness. Audit tooling (hybridparser) is provided for independent verification.

Multiple web searches for 'QuantumCoin audit', 'QuantumCoin security review', and related terms returned no independent audit reports. The project's GitHub, website, and third-party sources (CoinMarketCap, CoinGecko) do not reference any audit.

Claim: Full node implementation is open-source on GitHub (quantum-coin-go), forked from go-ethereum with public CIRCL library fork. SDK, documentation, and wallet code are also public.

Coverage basis: Public GitHub repository with buildable Go code

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Repository is active with 14k+ commits. Code is publicly accessible and buildable. CIRCL fork dependency is specified in go.mod.

• https://github.com/quantumcoinproject/quantum-coin-go
• https://github.com/quantumcoinproject/quantum-coin-js-sdk
• https://pkg.go.dev/github.com/quantumcoinproject/quantum-coin-go

Claim: Algorithm switch parameters (SigAlgSwitchBlock, KemSwitchTime) are documented in defaults/config.go. Multiple algorithm IDs are defined for signature scheme transitions. RLPx V1→V2 upgrade path is specified.

Coverage basis: Documented upgrade parameters in source code

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Upgrade parameters exist but no formal agility framework or governance process for algorithm transitions is documented. SigAlgSwitchBlock enables NIST-aligned algorithm IDs post-switch.

Scored 0.75 rather than 1.00 because parameter agility is code-level rather than documented in a formal upgrade governance specification.

• https://github.com/quantumcoinproject/quantum-coin-go/blob/main/defaults/config.go
• https://github.com/quantumcoinproject/quantum-coin-go/blob/main/crypto/crypto.go

Claim: ML-DSA and SLH-DSA are stateless schemes. Ed25519 is deterministic. No XMSS/LMS-style stateful signatures are used. No formal side-channel or fault-injection analysis is published.

Coverage basis: Stateless signature schemes eliminate state-management risk

Implementation score: 0.75 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Algorithm choice (stateless ML-DSA/SLH-DSA) avoids stateful-signature pitfalls. No side-channel or fault-injection analysis of the Go implementation or CIRCL fork has been published. No HSM or hardware-wallet security analysis exists.

Scored 0.75 because stateless scheme selection inherently reduces risk, but no implementation-level side-channel or fault-injection review exists.

Claim: Gas pricing varies by signature scheme. Block gas limit is 300M. Qualitative acknowledgment that PQC signatures are larger. No formal benchmark or resource-impact analysis published.

Coverage basis: Basic gas pricing consideration; no formal benchmark

Implementation score: 0.5 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Per Note-Only Caveat Rule, lack of formal benchmark does not reduce QRI Score unless resource constraints prevent safe use of the PQ/hybrid path. Mainnet operates with ~20-24s block times and 291 validators, suggesting resource adequacy.

Scored 0.50 for basic gas-pricing awareness and block-size considerations. No formal performance analysis, worst-case block validation timing, or node hardware requirements study published.

• https://quantumcoin.org/faq.html
• https://github.com/quantumcoinproject/quantum-coin-go