QANplatform QANX

Claim: QANplatform publishes a cryptographic inventory identifying secp256k1 (EVM compatibility), ML-DSA-65 via QAN XLINK (PQ spend authorization), and a PoR/PoS consensus. The quantum threat to ECDSA-based wallets with at least one outgoing transaction is described in project documentation.

Coverage basis: Public design documentation and threat-model description

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: Inventory exists at the design/documentation level but cannot be independently verified against implementation because the core L1 source code is held in a private GitLab.

Consensus-layer quantum resistance (validator authentication, VRFs, randomness) for the planned PoS MainNet Beta is not documented.

• https://learn.qanplatform.com/technology/technology-features/quantum-resistant-security
• https://learn.qanplatform.com/technology/technology-features
• https://learn.qanplatform.com/technology/technology-features/proof-of-randomness-por-consensus-algorithm

Claim: Evidence base includes two Hacken audits (XLINK November 2025, QVM July 2025), testnet explorer (testnet.qanscan.com), SDK documentation, GitHub peripheral repositories, and public roadmap.

Coverage basis: Component audits, testnet data, and public documentation

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: Audits are component-scoped (XLINK library, QVM), not full integrated L1. No mainnet evidence exists. Core L1 source is private, limiting reproducibility.

Evidence is substantial for the design and testnet phases but zero for production mainnet. Tangem (May 2026) contradicts the project's own TestNet v4 / pending-MainNet status and is treated as marketing.

• https://hacken.io/audits/qanplatform/l1-qanplatform-xlink-nov2025/
• https://hacken.io/audits/qanplatform/l1-qanplatform-xlink-sep2025/
• https://testnet.qanscan.com/
• https://github.com/QANplatform
• https://learn.qanplatform.com/about-us/roadmap

Claim: Production QANX token is an ERC-20/BEP-20 on Ethereum and BSC. All spend authorization uses ECDSA (secp256k1) only. The QAN TestNet supports ML-DSA via XLINK, but this is testnet, not production mainnet.

Coverage basis: ERC-20 token on classical host chains; testnet-only PQ support

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All production QANX spend authorization is ECDSA-only on Ethereum/BSC. No PQ-protected production transaction path exists.

Assurance: ERC-20 token address and its classical-cryptography dependency are verifiable on-chain. Testnet PQ support is documented but not production.

The project's PQ-native L1 design cannot be credited for production protection because the mainnet has not launched. Testnet XLINK PQ signatures demonstrate design capability but do not protect any production value.

• https://etherscan.io/token/0xaaa9214f675316182eaa21c85f0ca99160cc3aaa
• https://bscscan.com/address/0xaaa9214f675316182eaa21c85f0ca99160cc3aaa
• https://docs.qanplatform.com/
• https://learn.qanplatform.com/qanx-token/what-is-qanx.md

Claim: Production QANX token holders use Ethereum/BSC addresses with ECDSA public keys. Any address that has sent a transaction has an exposed public key vulnerable to quantum key-recovery attacks; no PQ migration path exists on host chains.

Coverage basis: Ethereum/BSC account model with classical ECDSA

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All production QANX token holders have long-exposure ECDSA public keys on Ethereum/BSC with no PQ migration path available.

Assurance: Verifiable on-chain. QANX token has thousands of holders on Ethereum/BSC, many with exposed public keys.

The XLINK design would theoretically allow migration of these keys to PQ pairs once mainnet launches, but no production migration path is available today.

• https://etherscan.io/token/0xaaa9214f675316182eaa21c85f0ca99160cc3aaa
• https://learn.qanplatform.com/qanx-token/what-is-qanx.md

Claim: No production L1 mainnet exists. The QAN TestNet uses a consensus mechanism (PoR) whose quantum resistance is not publicly documented. MainNet Beta is planned to launch with Proof-of-Stake; PoR is documented as experimental and deferred.

Coverage basis: No production consensus; testnet consensus quantum properties unverified

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Consensus-layer validator authentication quantum resistance is undocumented. MainNet Beta will use PoS with unspecified signature scheme.

Assurance: PoR documentation explicitly states it is experimental and MainNet Beta will use PoS. Neither consensus mechanism has publicly documented quantum-resistant validator authentication.

PoR is described as 'verifiable pseudorandomness' but the underlying cryptographic primitives (e.g., VRFs, randomness beacons) and their quantum resistance are not specified.

• https://learn.qanplatform.com/technology/technology-features/proof-of-randomness-por-consensus-algorithm

Claim: No production L1 mainnet exists. State-integrity mechanisms for the planned L1 are not publicly documented at a level that allows quantum-resistance assessment; EVM-compatibility suggests Merkle Patricia Trie-style commitments but quantum-resistant binding properties are unspecified.

Coverage basis: No production state-integrity layer

Implementation score: 0 · Evidence confidence: Low

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

Assurance: No public specification of state commitment scheme, Merkle tree construction, or data-availability mechanism exists for the planned L1.

Cannot be assessed from public evidence without a production mainnet.

Claim: QANplatform does not implement a privacy layer, shielded transactions, ZK proofs, or confidential asset protocols in its current design.

Coverage basis: No privacy layer exists in the architecture

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Claim: No production L1 mainnet exists. P2P layer quantum resistance is not documented; cannot be evaluated as satisfied-by-design because the L1 is not yet in production.

Coverage basis: No production P2P layer

Implementation score: 0 · Evidence confidence: Low

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

Assurance: No public documentation of P2P transport encryption or node identity scheme for the planned L1. Cannot apply satisfied-by-design because there is no production chain.

P2P is not consensus-critical or spend-critical; would normally be evaluated as satisfied-by-design if a PQ-native production chain existed. Not applicable here because no production chain exists.

Claim: No production PQ wallet path exists. QAN XLINK desktop app supports testnet only (Windows, Linux, macOS). MetaMask and Trust Wallet integration for XLINK cross-signing is documented for testnet. No hardware wallet, HSM, or institutional custody solution supports a production QAN PQ path.

Coverage basis: No production PQ wallet/custody support

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No production wallet, custody, or HSM path exists for PQ-protected QANX transactions.

Assurance: XLINK desktop app and MetaMask integration exist for testnet only. No production deployment.

Testnet wallet tooling is a positive migration-readiness signal but does not protect production users.

• https://medium.com/qanplatform/march-milestones-new-qan-xlink-release-testnet-fixes-and-status-page-d5fe3f8b7ddb
• https://medium.com/qanplatform/april-milestones-enterprise-ready-architecture-macos-launch-and-sdk-maturity-5453900fb994

Claim: 100% of QANX production value (~$24M market cap) resides on the ERC-20/BEP-20 token on Ethereum and BSC, secured entirely by classical ECDSA. 0% of production value is PQ-protected. Coverage is <25%.

Coverage basis: ERC-20/BEP-20 token on classical host chains

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 0% of production QANX value-at-risk is PQ-protected. All value is on ECDSA-secured Ethereum and BSC.

Assurance: Token supply, holder count, and contract address are verifiable on-chain. Market cap from CoinGecko.

Maps to score band 1 (<25%) per QRI 9.3.1. Migration of QANX to the native L1 is a future dependency once mainnet launches.

• https://etherscan.io/token/0xaaa9214f675316182eaa21c85f0ca99160cc3aaa
• https://www.coingecko.com/en/coins/qanplatform
• https://learn.qanplatform.com/qanx-token/what-is-qanx.md

Claim: No critical wallets (treasury, exchange, custody, bridge, foundation) have been migrated to PQ protection because no production PQ-secure L1 exists.

Coverage basis: No migration has occurred

Implementation score: 0 · Evidence confidence: High

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

Assurance: No evidence of any critical wallet migration. The QANX deployer address on Ethereum is a standard EOA with classical ECDSA security; the 2022 bridge hack showed its exposure.

Critical wallets cannot be migrated until the native L1 mainnet launches.

• https://claim.qanplatform.com/

Claim: The QANX ERC-20/BEP-20 token contract, its deployer address, the (historical) bridge contract, and all holder addresses are identified on-chain. The 2022 bridge hack resulted in a token migration to a new contract. No deprecation, freeze, or migration to PQ security has occurred for the production token.

Coverage basis: On-chain token and holder identification

Implementation score: 0.25 · Evidence confidence: High

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

Assurance: Token holders and contract addresses are fully verifiable on-chain. The 2022 bridge hack and subsequent token migration are well-documented.

The project has identified the vulnerable production surface (ERC-20/BEP-20 on classical chains) and ran a claim process for the post-hack token migration. No quantum-specific deprecation, freeze, or migration mechanism exists for production.

• https://etherscan.io/token/0xaaa9214f675316182eaa21c85f0ca99160cc3aaa
• https://claim.qanplatform.com/
• https://decrypt.co/111658/quantum-resistant-blockchain-qanplatform-suffers-bridge-hack-for-over-1-million
• https://learn.qanplatform.com/disclaimers/disclaimer/validation

Claim: QANplatform has published a roadmap showing MainNet launch as the migration target, with XLINK as the migration mechanism. QVM and XLINK audits are completed; Integration Audit is in progress. A May 2026 strategic update announced a controlled architectural rebase onto Ethereum's official implementation.

Coverage basis: Published roadmap and strategic updates

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Roadmap is high-level with no specific MainNet launch date. The May 2026 rebasing announcement introduces architectural uncertainty. Integration Audit still in progress.

Roadmap provides directional guidance but lacks concrete activation criteria, sequenced dependencies with dates, or binding governance commitments. Treated as a roadmap/proposal per QRI 6.2 (0.25).

• https://learn.qanplatform.com/about-us/roadmap
• https://medium.com/qanplatform/strategic-update-qanplatform-integrates-with-government-and-enterprise-solutions-0bb58eb259ca
• https://www.youtube.com/watch?v=7ifQTeVm0bw

Claim: QAN XLINK desktop app is available on Windows, Linux, and macOS for testnet use. SDKs exist for multiple languages (Go, JavaScript, C#, Java, Bash, etc.). TestNet documentation covers smart contract deployment. No production migration tooling exists.

Coverage basis: Testnet tooling only

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: Testnet tooling is extensive and cross-platform. No production deployment exists, so migration accessibility for real users is zero.

The XLINK desktop app and multi-language SDKs are positive indicators of migration readiness but they only serve the testnet. Production users cannot migrate because there is no production PQ system to migrate to.

• https://medium.com/qanplatform/april-milestones-enterprise-ready-architecture-macos-launch-and-sdk-maturity-5453900fb994
• https://docs.qanplatform.com/
• https://github.com/QANplatform

Claim: No mainnet exists, so no enforcement mechanisms are active. Exchange, custody, bridge, and wallet coordination for PQ migration has not begun.

Coverage basis: No production enforcement

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: No evidence of exchange, custody, or bridge coordination for PQ migration. The ERC-20 token trades on centralized exchanges (Gate, MEXC, etc.) with no PQ withdrawal path.

Migration enforcement is not applicable until mainnet launches.

Claim: QANplatform demonstrated incident-response capability during the 2022 bridge hack with a token migration and compensation program (claim.qanplatform.com). No quantum-specific incident-response playbook or governance process is publicly documented.

Coverage basis: General incident-response history; no quantum-specific IR

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The 2022 bridge hack response demonstrates general operational incident capability. Per QRI v3.1 §7.4 Note-Only Caveat Rule, the absence of a formal quantum-specific IR playbook does not reduce the QRI Score unless it leaves a current quantum-vulnerable path unresolved.

General IR capability demonstrated historically; quantum-specific IR is an assurance note rather than a score-reducing issue.

• https://claim.qanplatform.com/
• https://medium.com/qanplatform/qanx-bridge-wallet-disclosure-analysis-72b78a7b7a1c

Claim: QANplatform uses ML-DSA (FIPS 204, CRYSTALS-Dilithium), the NIST primary recommendation for post-quantum signatures. Implemented in Go via the QAN XLINK cross-signer and documented as ML-DSA-65.

Coverage basis: NIST-standardized ML-DSA (FIPS 204)

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA is NIST FIPS 204 standardized. The Hacken audit confirms the use of ML-DSA-65 in the XLINK library. Algorithm choice is appropriate for the use case.

Choice of NIST-standardized ML-DSA well before NIST's official finalization (August 2024) demonstrates early and appropriate algorithm selection.

• https://learn.qanplatform.com/technology/technology-features/quantum-resistant-security
• https://hacken.io/audits/qanplatform/l1-qanplatform-xlink-nov2025/

Claim: Hacken audited the QAN XLINK cryptographic protocol (Go) in November 2025: 31 findings, 29 resolved, 2 accepted. Covers Link/Renew/Relink payloads, validation, and key management for binding secp256k1 to ML-DSA-65 keys. QVM was audited separately by Hacken in July 2025.

Coverage basis: Hacken audit of XLINK library (November 2025) and QVM (July 2025)

Implementation score: 0.75 · Evidence confidence: High

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

Assurance: Audits are ~7 months and ~11 months old (stale but relevant). Scope is limited to the XLINK library and QVM, not the full integrated L1. The May 2026 architectural rebase may affect applicability to the eventual production system. 2 XLINK findings were accepted rather than resolved.

Per QRI v3.1 §6.4, stale-but-relevant audit does not by itself reduce the QRI Score; it caps confidence at Medium. The two accepted findings should be reviewed for quantum-security implications.

• https://hacken.io/audits/qanplatform/l1-qanplatform-xlink-nov2025/
• https://hacken.io/audits/qanplatform/l1-qanplatform-xlink-sep2025/
• https://thequantuminsider.com/2025/11/20/qan-xlink-hacken-audit/

Claim: Core L1 protocol source code is in a private GitLab and not publicly available. Peripheral components (ERC-20 token contract, bridge contracts, SDKs, documentation) are open source on GitHub. The project states core code will be open-sourced after MainNet launch.

Coverage basis: Partial open source; core protocol closed

Implementation score: 0.25 · Evidence confidence: Medium

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

Quantum blocker: Core L1 protocol source code is not publicly available. Quantum-critical claims cannot be independently verified through code review or reproducible builds.

Assurance: Project FAQ explicitly states code is in a private GitLab for IP protection and will be open-sourced after MainNet launch. Token contracts, SDKs, and docs are open. This is a deliberate business decision, not a technical limitation.

The private codebase is a significant limitation for QRI evaluation. Without access to the core protocol implementation, the actual integration of ML-DSA, key management, signature verification, and consensus authentication cannot be independently assessed.

• https://github.com/QANplatform
• https://qanplatform.com/en/developers

Claim: The May 2026 architectural rebase to Ethereum's official implementation indicates a planned upgrade path. QANplatform is a member of the Linux Foundation's Post-Quantum Cryptography Alliance. Specific parameter agility (e.g., ML-DSA parameter set upgrade, algorithm swap) is not documented.

Coverage basis: Rebasing plan and PQ Alliance membership

Implementation score: 0.5 · Evidence confidence: Low

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

Assurance: The rebasing plan is directional but lacks technical detail on parameter agility. PQ Alliance membership is a positive signal but not a substitute for documented upgrade procedures.

ML-DSA parameter sets (44, 65, 87) provide some inherent agility. The rebasing to Ethereum may improve or complicate future algorithm upgrades depending on how tightly the implementation couples to specific Ethereum conventions.

• https://medium.com/qanplatform/strategic-update-qanplatform-integrates-with-government-and-enterprise-solutions-0bb58eb259ca
• https://qanplatform.com/

Claim: ML-DSA (CRYSTALS-Dilithium) is a stateless signature scheme. Stateful-signature concerns (anti-reuse controls, signing-state discipline) that apply to XMSS/LMS do not apply to ML-DSA.

Coverage basis: ML-DSA is stateless by design

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA's stateless property is inherent to the NIST standard. No additional implementation controls are needed for state management.

Genuine advantage of choosing ML-DSA over stateful hash-based schemes for blockchain applications; eliminates an entire class of implementation risks.

• https://csrc.nist.gov/pubs/fips/204/final

Claim: No public performance benchmarks for ML-DSA signature generation, verification, key sizes, or resource impact within the QAN blockchain context (block validation time, gas/fee impact, mempool sizing, archival storage growth) have been published. Project website references 1,600+ TPS for the public blockchain but does not isolate ML-DSA verification cost.

Coverage basis: No public benchmarks

Implementation score: 0 · Evidence confidence: None

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

Assurance: ML-DSA signatures are ~2.4 KB and public keys ~1.3 KB, significantly larger than ECDSA. Without benchmarks, the impact on block propagation, storage, and validation times cannot be assessed. Per QRI v3.1 Note-Only Caveat Rule, this is treated as confidence-only because it does not create a current quantum-vulnerable path.

Performance data will be critical for assessing whether the PQ path is practically deployable at scale once the mainnet launches.