Quant QNT

Claim: No public cryptographic inventory of QNT's quantum-vulnerable mechanisms exists.

Coverage basis: No published inventory, threat model, or risk assessment from Quant Network for QNT token, Overledger, or treasury.

Implementation score: 0 · Evidence confidence: None

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

Quantum blocker: No public cryptographic inventory (Readiness & Risk Cap: 10)

Assurance: Quant's official website, GitHub repositories, and published documentation contain no cryptographic inventory, quantum threat model, or risk assessment. The CoinTribune Naoris partnership article (secondary source, unverifiable from primary channels) does not constitute a cryptographic inventory.

The absence of a cryptographic inventory makes it impossible to systematically verify which quantum-vulnerable surfaces exist beyond the obvious ECDSA spend authorization. Treasury key management, Overledger gateway signatures, and Fusion Rollup validator/sequencer authentication are not inventoried.

• https://quant.network/
• https://github.com/quantnetwork/Overledger-Interfaces

Claim: No public evidence record supporting a quantum risk assessment exists.

Coverage basis: No code references, specifications, audits, transaction examples, or reproducible analytics published by Quant for quantum risk assessment.

Implementation score: 0 · Evidence confidence: None

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

Assurance: The EtherAuthority audit (November 2025) is a general smart-contract security audit with no quantum-cryptographic scope. It does not serve as a quantum evidence record.

No quantum-specific audits, specifications, or reproducible analytics have been published for QNT, Overledger cryptographic layers, or treasury contracts.

Claim: QNT spend authorization is entirely ECDSA (secp256k1) via Ethereum L1 inheritance. No PQC or hybrid-PQC path exists.

Coverage basis: QNT is a standard ERC-20 token on Ethereum. All transfers, approvals, and treasury operations require ECDSA-signed Ethereum transactions.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Active production spend authorization remains entirely ECDSA-only (Readiness & Risk Cap: 40)

Assurance: Ethereum's ECDSA dependency is well-evidenced through the verified token contract on Etherscan, the 2019 Overledger whitepaper confirming reliance on standard digital signatures, and the observable on-chain transaction history. Evidence confidence is High.

Per QRI Token Inheritance rule (Section 7.2), QNT inherits Ethereum's quantum risk profile for spend authorization. Ethereum uses ECDSA (secp256k1) with no production PQC or hybrid-PQC support as of June 2026.

• https://etherscan.io/token/0x4a220e6096b25eadb88358cb44068a3248254675
• https://etherscan.io/address/0x4a220e6096b25eadb88358cb44068a3248254675

Claim: QNT inherits Ethereum's EOA model where public keys are exposed on spend, creating long-exposure quantum-vulnerable ownership paths.

Coverage basis: Ethereum EOAs reveal public keys in transaction signatures. Any QNT-holding address that has sent a transaction has an exposed public key.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration path (Readiness & Risk Cap: 55)

Assurance: Ethereum's EOA public-key exposure model is well-documented. All QNT transactions since 2018 have exposed sender public keys on-chain. Addresses that have only received tokens (never sent) have unexposed public keys but cannot spend without exposing them.

As of June 2026, QNT has ~160,000 holders and has been actively traded since 2018. Many holder addresses have sent transactions, exposing their public keys permanently on Ethereum's immutable ledger. These keys are vulnerable to offline quantum attack with no time constraint (harvest now, decrypt later).

• https://etherscan.io/token/0x4a220e6096b25eadb88358cb44068a3248254675

Claim: Consensus authentication is not applicable to an ERC-20 token. QNT has no independent consensus layer.

Coverage basis: QNT is a token contract on Ethereum; consensus is provided by Ethereum's Proof of Stake layer.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://etherscan.io/token/0x4a220e6096b25eadb88358cb44068a3248254675

Claim: State integrity is inherited from Ethereum L1. QNT has no independent state-integrity or data-availability mechanisms.

Coverage basis: QNT token balances and allowances are stored in Ethereum's state trie secured by Ethereum's consensus.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://etherscan.io/token/0x4a220e6096b25eadb88358cb44068a3248254675

Claim: QNT has no privacy or proof layers. No ZK proofs, note encryption, viewing keys, stealth addresses, or shielded state exist for QNT.

Coverage basis: Standard ERC-20 token with transparent balances and transfers.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://etherscan.io/address/0x4a220e6096b25eadb88358cb44068a3248254675

Claim: QNT has no independent P2P network layer. P2P transport is provided by Ethereum.

Coverage basis: ERC-20 tokens do not maintain independent P2P networks.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No evidence of PQ/hybrid wallet support, HSM integration, or quantum-resistant custody workflows for QNT treasury or operator keys.

Coverage basis: Treasury contracts use ECDSA operator addresses. No PQ wallet, HSM, or custody path is documented for QNT.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Treasury operator keys rely on ECDSA; key management practices and multisig configuration are not publicly documented

Assurance: Treasury smart contracts are publicly visible on Etherscan and the archived GitHub repository documents their interaction model. However, the specific multisig configuration, key custody practices, and whether operator addresses have sent transactions (exposing public keys) are not publicly documented. The old treasury repo was archived in February 2026; current Fusion-based treasury mechanics are less documented.

The treasury system uses operator addresses that sign ECDSA transactions to manage payment channels and escrow deposits. The upgradeable proxy pattern means implementation can be changed, but the authorization mechanism (ECDSA from operator EOAs) remains quantum-vulnerable. Quant Network controls the Treasury Proxy; its operator key exposure status is unknown.

• https://github.com/quantnetwork/overledger-treasury-community
• https://etherscan.io/address/0x2ee1f3535325bc596f616f0591d1a1bc85164775

Claim: 0% of QNT value-at-risk is protected from quantum key-recovery attacks. All ~$900M market cap is quantum-vulnerable via Ethereum ECDSA.

Coverage basis: QNT is a standard ERC-20 with no migration mechanism. All circulating QNT (~12M tokens) relies on ECDSA for spend authorization.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path (Readiness & Risk Cap: 55)

Assurance: QNT market cap and circulating supply are publicly available from CoinGecko and Etherscan. All QNT value is on Ethereum mainnet with ECDSA spend authorization. Value-at-risk coverage is verifiably 0%.

Coverage: <25% (Experimental/negligible protection). QNT has no independent migration mechanism. Protection depends entirely on Ethereum's quantum migration, which is still in early research stages (Vitalik Buterin's February 2026 proposal). Approximately 160,000 holder addresses exist. Dormant/unmigratable assets (lost keys, abandoned addresses) cannot be identified or addressed without Ethereum-level protocol changes.

• https://etherscan.io/token/0x4a220e6096b25eadb88358cb44068a3248254675
• https://www.coingecko.com/en/coins/quant

Claim: No critical wallets (treasury, exchanges, custodians, bridges, foundation) are migrated, protected, or verifiably PQ-native for QNT.

Coverage basis: No evidence of any QNT-critical wallet using PQC, hybrid-PQC, or quantum-resistant custody.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: Treasury contract addresses are known but the specific operator key configuration, multisig setup, and custody practices are not publicly documented. Exchange and custodian QNT holdings and their key management practices are not publicly attested. Evidence confidence is Low.

Quant Network treasury proxy contracts are on Ethereum mainnet and use ECDSA operator addresses. The protocol does not prevent creation of classical custody paths, and no PQ-native controls exist for treasury operations. Exchange-held QNT is quantum-vulnerable via exchange Ethereum EOAs.

Claim: No identification, measurement, deprecation, migration, freezing, or proof of non-existence of legacy quantum-vulnerable QNT pools.

Coverage basis: No legacy pool analysis, migration policy, deprecation mechanism, or freeze capability exists for QNT.

Implementation score: 0 · Evidence confidence: None

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

Assurance: No legacy pool analysis, no dormancy assessment, no salvage policy, and no mechanism to freeze or migrate vulnerable QNT has been published by Quant Network.

QNT token contract has no freeze, burn-from-address, or migration function. Lost/abandoned QNT cannot be addressed without Ethereum-level protocol changes. Quant Network has not published any analysis of dormant, exposed-key, or unmigratable QNT holdings.

Claim: No public migration or protection roadmap exists for QNT quantum vulnerability.

Coverage basis: No roadmap, sequencing, activation criteria, or dependencies have been published for QNT quantum migration.

Implementation score: 0 · Evidence confidence: None

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

Assurance: The CoinTribune Naoris partnership article (April 2026) suggests Overledger-level quantum work, but this cannot be verified from primary sources and does not constitute a QNT token migration roadmap. No official Quant Network roadmap addresses QNT quantum vulnerability.

QNT token migration is dependent on Ethereum's quantum roadmap. Ethereum co-founder Vitalik Buterin outlined a proposal in February 2026, but this is Ethereum-level, not QNT-specific. Quant has not published any token-specific migration plan, timeline, or coordination strategy.

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

Coverage basis: No QNT-specific migration tooling, wallet support, or user education materials exist.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Quant's official documentation (quant.network, docs.overledger.dev) contains no references to quantum-safe account creation, PQ wallets, migration prompts, or quantum risk education. Evidence confidence is High for the absence of these features.

QNT uses standard Ethereum wallets (MetaMask, hardware wallets) with no PQ capabilities. No migration prompts, deprecation warnings for ECDSA addresses, or quantum-safe default configurations exist.

• https://quant.network/
• https://docs.overledger.dev/

Claim: No enforcement mechanisms exist for quantum-safe migration. No deprecation, freeze, disabled legacy signing, withdrawal restrictions, or unsafe-path blocking.

Coverage basis: QNT token contract has no admin controls for enforcement. No coordination with exchanges, custodians, bridges, or wallets for quantum-safe migration.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The EtherAuthority audit confirms the QNT token contract has no ownership control (100% decentralized). This prevents any token-level enforcement mechanism. Enforcement would require Ethereum-level protocol changes or a completely new token contract with social coordination for migration.

The decentralized nature of the QNT token contract means there is no admin key that could enforce migration, freeze vulnerable balances, or block unsafe transactions. Any migration would require voluntary user action or Ethereum protocol-level changes. Quant has published no coordination plan with exchanges or custodians.

• https://etherscan.io/address/0x4a220e6096b25eadb88358cb44068a3248254675
• https://etherauthority.io/quant-token-smart-contract-audit/

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

Coverage basis: No quantum vulnerability disclosure process, incident-response playbook, or emergency governance mechanism exists.

Implementation score: 0 · Evidence confidence: None

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

Assurance: No quantum-specific incident-response documentation, security contact for quantum vulnerabilities, or emergency governance process exists. This is classified as an assurance-only caveat per Section 7.4 because it does not independently create a quantum-attack path; the attack path already exists via ECDSA vulnerability.

While the absence of an incident-response process is noted, it does not independently reduce the QRI Score because the quantum vulnerability exists regardless of response preparedness. This is reported in Assurance & Review Notes.

Claim: QNT uses no PQC or hybrid-PQC algorithms. All cryptography is Ethereum's classical ECDSA (secp256k1).

Coverage basis: No PQC algorithms are implemented or used in the QNT token contract, treasury, or Overledger (in verifiable production scope).

Implementation score: 0 · Evidence confidence: High

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

Assurance: The 2019 Overledger whitepaper confirms reliance on standard digital signatures and public-key cryptography. The token contract contains no custom cryptographic primitives. Evidence confidence is High for the absence of PQC algorithms.

No NIST-standardized PQC algorithms (ML-KEM, ML-DSA, SLH-DSA, FN-DSA, or LMS/XMSS) are used in any verifiable QNT or Overledger production component as of June 2026.

• https://etherscan.io/address/0x4a220e6096b25eadb88358cb44068a3248254675
• https://uploads-ssl.webflow.com/6006946fee85fda61f666256/60211c93f1cc59419c779c42_Quant_Overledger_Whitepaper_Sep_2019.pdf

Claim: No independent quantum-cryptographic audit exists for QNT. The EtherAuthority audit (November 2025) is a general smart-contract audit with no quantum scope.

Coverage basis: EtherAuthority audit covers smart-contract security (overflow, access control) but does not evaluate quantum resistance, PQC implementation, or cryptographic algorithm security.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The EtherAuthority audit (November 2025, current) found 0 critical/high/medium/low issues and 7 very low-level issues. The audit scope covers standard smart-contract security (overflow, access control, ERC-20 compliance) but has zero quantum-cryptographic scope. Since there is no PQC implementation to audit, the absence of a quantum-specific audit does not independently reduce the QRI Score (Section 7.4). This is an assurance-only caveat.

A quantum-cryptographic audit would require a PQC implementation to audit. Since QNT has no PQC implementation, the absence of such an audit is expected but noted. The existing audit confirms the token contract is well-implemented for its classical security scope.

• https://etherauthority.io/quant-token-smart-contract-audit/

Claim: QNT token contract is verified open-source on Etherscan, but there is no PQC implementation to be open-source or reproducible.

Coverage basis: Token contract source code is verified on Etherscan (Solidity, compiler 0.5.17+commit.d19bba13). No PQC implementation exists to evaluate for openness.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: The QNT token contract is verifiably open-source on Etherscan. The treasury contracts are also verifiable via proxy implementation addresses. However, there is no PQC implementation for which openness would be meaningful. The subfactor scores 0 because there is no PQ implementation to be open-source, not because the existing code is closed.

This subfactor is scored 0.00 because there is no PQC implementation. The existing classical code is open-source and verifiable, which is good general practice but irrelevant to quantum readiness.

• https://etherscan.io/address/0x4a220e6096b25eadb88358cb44068a3248254675#code

Claim: No parameter agility or upgrade path for quantum-resistant cryptography is documented for QNT.

Coverage basis: QNT token contract is immutable (no ownership). Treasury uses upgradeable proxies but no quantum-specific upgrade path is documented.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: The QNT token contract has no admin/upgrade mechanism, making any quantum migration dependent on Ethereum protocol changes or social coordination for a new token contract. Treasury proxy contracts are upgradeable but no quantum-specific upgrade path or parameter agility plan exists. Evidence confidence is Low.

The immutable token contract means algorithm agility cannot be added at the token level. Treasury proxies could theoretically be upgraded for PQ signatures, but no such plan exists. Parameter agility for hypothetical future PQC migration is not addressed in any Quant documentation.

Claim: No stateful PQC signatures (XMSS/LMS) are used in QNT or associated infrastructure. Not applicable to current production scope.

Coverage basis: QNT uses only stateless ECDSA via Ethereum. No stateful PQ signatures are implemented or planned.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No performance or resource-impact analysis exists for PQC deployment in QNT or Overledger. Not applicable to current production scope.

Coverage basis: No PQC implementation exists to analyze for performance impact on block validation, gas fees, mempool policy, archival growth, or node hardware.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

If QNT or Overledger were to adopt PQC signatures, a performance analysis would be needed given Ethereum's gas constraints and the larger signature sizes of NIST PQC algorithms (ML-DSA signatures are ~2.4-4.6 KB vs ECDSA's ~65 bytes).