# Blockchain Quantum Readiness Index: expanded LLM context > A consolidated, human-readable snapshot of the Quantum Readiness Index methodology and every published project assessment. Complete structured report data remains available through each linked JSON resource. QRI reports are pre-release, AI-assisted assessments. Treat the evaluation date, review status, evidence confidence, evaluated scope, and critical quantum blockers as integral parts of each result. Scores measure current quantum-attack readiness, not market quality, adoption, decentralization, or general project merit. ## Methodology at a glance QRI scores blockchain projects from 0 to 100 across five categories: security assessment and evidence preparedness (10 points), production cryptographic protection (35), migration status and value-at-risk (25), migration mechanism, governance and ecosystem coordination (15), and algorithm and implementation assurance (15). The final score is the minimum of the factor score, stage cap, and readiness-and-risk cap. Stage 0 means Not Assessed; Stage 1 means Quantum Risk Assessed; Stage 2 means Mitigation / Development; Stage 3 means Migration Live; and Stage 4 means Migration Complete / Quantum-Ready. Evidence confidence is reported separately from the score. - [Complete QRI methodology](https://qrindex.org/methodology/): Scoring model, evidence handling, readiness stages, confidence, assurance, and report status. - [Compact projects API](https://qrindex.org/api/projects.json): Machine-readable score and stage index for all projects. - [Concise LLM index](https://qrindex.org/llms.txt): Compact resource map and direct links to complete report JSON. ## A7A5 (A7A5) - Project page: https://qrindex.org/projects/a7a5/ - Complete report JSON: https://qrindex.org/projects/a7a5/report.json - Official project website: https://a7a5.io/ - Project type: stablecoin - Evaluated network: Ethereum, TRON - Evaluated scope: Token (ERC-20 on Ethereum at 0x6fA0BE17e4beA2fCfA22ef89BF8ac9aab0AB0fc9; TRC-20 on TRON at TLeVfrdym8RoJreJ23dAGyfJDygRtiWKBZ). Standard smart-contract token with no custom cryptographic or cross-chain dependency layer. - QRI score: 1/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Token Inheritance: Ethereum, Token Inheritance: TRON, Classical ECC Only, Centralized Admin Keys ### Summary A7A5 is a Russian ruble-backed stablecoin deployed as a standard ERC-20 token on Ethereum and TRC-20 token on TRON. Under QRI Section 7.2 (Token Inheritance), A7A5 inherits the base-layer quantum-readiness scores of Ethereum and TRON — both of which remain entirely ECDSA/BLS-dependent in production as of June 2026 and have no live post-quantum protection. The project has published zero quantum-specific work: no cryptographic inventory, no threat model, no risk assessment, no PQC migration plan, and no quantum-aware governance. The token's admin functions (mint, burn, pause, blacklist, destroyBlackFunds, fee updates) are controlled by ECDSA-based multisigs (3-of-5 and 5-of-5) on both chains — a quantum compromise of any quorum threshold would enable unlimited supply manipulation and user fund freezes. Approximately $500M in market cap and $110B+ in cumulative transaction volume are exposed with no migration, freeze, or recovery path. The QRI Score is 1 out of 100, reflecting negligible quantum readiness and complete absence of project-level quantum awareness. The project is at Stage 0 (Unassessed / No Evidence). ### Critical quantum blockers - No public cryptographic inventory exists — the full quantum attack surface cannot be independently verified. - All user spend authorization is ECDSA-only, inherited from host chains (Ethereum secp256k1 ECDSA, TRON ECDSA). A quantum adversary can derive private keys from exposed public keys of any account that has ever sent a transaction. - Admin multisig keys (Owner 3-of-5, Accountant 3-of-5, Compliance 5-of-5) rely on standard ECDSA on both Ethereum and TRON. Quantum compromise of any quorum threshold enables unlimited token minting, burning, freezing, fee manipulation, and supply destruction via destroyBlackFunds. - No quantum risk assessment, cryptographic threat model, PQC migration plan, or quantum-aware governance process has been published by the project. - Material long-exposure quantum-vulnerable value exists (~$500M market cap, $110B+ cumulative volume) with no migration, freeze, deprecation, burn, recovery, or policy path. ### Principal risks - Quantum-enabled admin-key compromise: An adversary with a cryptographically relevant quantum computer who obtains the public keys of 3-of-5 Owner/Accountant signers (or 5-of-5 Compliance signers) can forge multisig transactions to mint unlimited tokens, burn any holder's funds, freeze any address, destroy blacklisted funds, or manipulate transfer fees. The destroyBlackFunds function has already been used post-sanctions to burn and re-mint $405M in tokens, demonstrating the real-world power of these keys. - Host-chain inheritance: All A7A5 user transactions rely on Ethereum secp256k1 ECDSA and TRON ECDSA. Any account that has ever sent a transaction has an exposed public key on-chain, creating a long-exposure attack surface. Neither Ethereum nor TRON has production PQ protection as of June 2026. - Supply-integrity failure: The rebase mechanism (balance derived from shares × _totalLiquidity / _totalSupply) means that admin-key compromise can silently inflate or deflate all holder balances through distributeInterest or direct mint/burn operations. - No recovery path: There is no documented mechanism for users or the protocol to recover from a quantum-enabled admin-key compromise. The project has no quantum incident-response plan, no migration mechanism, and no governance process for cryptographic emergencies. - Concentration risk: The extreme token concentration (top 10 addresses hold >98% of Ethereum supply) means a quantum attack on a small number of admin or whale keys could capture nearly all token value. - Cross-chain exposure: A7A5 operates on both Ethereum and TRON with a wrapped variant (wA7A5). A quantum break on either host chain compromises the token on that chain, and the wrapped representation creates additional bridge/custody risk. ## Aave (AAVE) - Project page: https://qrindex.org/projects/aave/ - Complete report JSON: https://qrindex.org/projects/aave/report.json - Official project website: https://www.coingecko.com/en/coins/aave - Project type: DeFi protocol token - Evaluated network: Ethereum (primary), Polygon, Arbitrum, Avalanche, Base, Optimism, BNB, Aptos, and additional EVM networks (19+ deployments) - Evaluated scope: Aave protocol smart contracts (V3/V4), AAVE ERC-20 governance token, governance multisigs, oracle dependencies, and cross-chain deployments - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-11 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Quantum Vulnerable, Governance Exposure Critical, Inherits Host-Chain Risk, ERC-1271 Compatible, Classical-Only, No Quantum Roadmap ### Summary Aave is a production DeFi lending protocol with approximately $10B+ in TVL across 19+ networks and no quantum readiness whatsoever. The protocol inherits Ethereum's ECDSA-based security model for all user operations and relies on ECDSA multisigs for all governance, emergency, and risk-management functions. Aave has published no quantum risk assessment, no cryptographic inventory, no PQC migration roadmap, and deploys no post-quantum or hybrid cryptography. Extensive classical security audits (345+ cumulative days of review for V4) confirm strong classical security but provide zero quantum assurance. Third-party analyses (PQBeat Stage 1, StablePQC, Google Quantum AI March 2026) independently confirm Aave's governance keys are among the highest-value quantum-exposed targets on Ethereum. The protocol's ERC-1271 compatibility means it could theoretically accept PQ smart accounts in the future, but this provides no current protection. QRI Score of 1 reflects minimal baseline credit for having identifiable value-at-risk combined with the complete absence of quantum security assessment, protection, migration mechanisms, or algorithm assurance. ### Critical quantum blockers - All spend authorization is ECC-only: Aave inherits Ethereum's secp256k1 ECDSA for all user transactions (supply, borrow, withdraw, repay, liquidate) across all EVM deployments. No PQC or hybrid-PQC path exists for any user operation. - Governance multisigs are entirely ECDSA-based: Protocol Emergency Guardian (4/7 multisig across 19 networks), Risk Stewards (1-of-1), Governance Emergency Guardian (5/9), GHO Stewards (3/4), and Rewards Multisig (3/4) all use standard ECDSA keys with public keys permanently exposed on-chain. - No public cryptographic inventory or quantum threat model has been published by Aave or the Aave DAO. - Oracle dependency: Aave relies on Chainlink price feeds secured by ECDSA oracle operator keys. Quantum-forged oracle prices could trigger cascading liquidations. - Long-exposure public keys: All Aave governance signers, large depositors, and protocol-controlled addresses that have transacted have permanently exposed ECDSA public keys on-chain — harvestable now for future quantum decryption. - Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path. ### Principal risks - Governance compromise is the most severe quantum risk: The Protocol Emergency Guardian (4/7 multisig) can pause markets, freeze reserves, and execute emergency actions across all 19 Aave deployments. All signer public keys are permanently exposed on-chain. Third-party estimates place Aave's governance-controlled TVL at ~$10B+. - Risk Steward single point of failure: The 1-of-1 Risk Steward multisig (Chaos Labs) controls supply caps, borrow caps, and collateral risk parameters. Compromise of this single ECDSA key could manipulate lending parameters to enable protocol draining. - Oracle manipulation via quantum key recovery: Aave relies on Chainlink price feeds signed by ECDSA oracle operators. Quantum-forged oracle prices could artificially deflate collateral values or inflate debt values, triggering mass liquidations. This attack requires no direct interaction with Aave's contracts. - Cross-chain cascade risk: With 19 network deployments sharing the same governance infrastructure, a quantum compromise on one network's Guardian deployment could provide a template or access path to others. The V4 Cross-Chain Liquidity Layer introduces additional cross-chain dependencies secured by classical bridges. - Long-exposure harvest attack surface: Every Aave governance signer, protocol-controlled address, and large depositor that has ever transacted has permanently exposed their ECDSA public key on-chain. These keys are harvestable today for future quantum decryption. - No migration path exists: Even if Ethereum implements PQ accounts, Aave's governance multisigs, oracle integrations, and cross-chain infrastructure have no documented plan for key rotation or cryptographic upgrade. - Aave cannot migrate independently of Ethereum: As a smart-contract protocol without its own consensus layer, Aave's user-facing quantum security is entirely dependent on Ethereum's PQC migration timeline (EF targets 2029 for L1 upgrades). Aave has no influence over this timeline and has not begun preparation for the post-Ethereum-upgrade migration of its own infrastructure. ## Abelian (ABEL) - Project page: https://qrindex.org/projects/abelian/ - Complete report JSON: https://qrindex.org/projects/abelian/report.json - Official project website: https://www.pqabelian.io - Project type: Post-quantum privacy-preserving L1 chain - Evaluated network: Abelian Layer 1 production mainnet - Evaluated scope: Native ABEL asset and Abelian Layer 1 only, including spend authorization, address and key exposure, PoW consensus applicability, state integrity, privacy proofs, P2P identity, native wallets, and native-asset migration status. QDay Layer 2, external bridges, EVM wrappers, and other non-native representations are excluded. - QRI score: 75/100 - Readiness stage: 4 (Migration Complete / Quantum-Ready) - Evidence confidence: Medium - Evaluation date: 2026-08-20 - Review status: draft - User urgency: [No Action Needed] for native on-chain ABEL; [Monitor for Updates] on independent cryptographic review and separately scoped L2 or bridge exposure. - Readiness tags: PQ-Native, PQ-Resistant, PoW, UTXO, Privacy-Preserving, Bespoke Cryptography, Native Asset Scope ### Summary Abelian is assessed as a PQ-native production Layer 1 for native ABEL. Public code and official documentation consistently indicate mandatory lattice-based ownership, transaction, commitment, and privacy mechanisms, with no identified classical native ownership namespace or legacy native balance pool. Native ECC-to-PQC migration is therefore complete by design within this scope, and the PoW L1 has no applicable validator-signature layer. Confidence is Medium because current mainnet artifacts are not supplied and the project-specific quantum-critical constructions lack an evidenced independent cryptographic review. QDay Layer 2, bridges, wrappers, and non-native ABEL representations are not covered. ### Critical quantum blockers - Production protection materially depends on project-specific lattice authorization, commitment, and privacy constructions for which no in-scope independent cryptographic audit or serious public cryptographic review is supplied. - The cryptographic soundness and current production use of every quantum-critical bespoke path are not independently established by the supplied mainnet artifacts or review record. ### Principal risks - A structural flaw in the project-specific lattice authorization, commitment, ring-signature, or zero-knowledge constructions could compromise ownership, supply binding, or privacy across the native L1. - The supplied record does not independently demonstrate through current mainnet artifacts that every production transaction variant uses only the documented post-quantum paths. - The announced node and wallet audit does not establish independent cryptographic soundness for the bespoke quantum-critical constructions. - QDay Layer 2, bridges, and wrapped ABEL may have different cryptographic dependencies and require separate assessment; their quantum status is unresolved rather than presumed vulnerable. ## Algorand (ALGO) - Project page: https://qrindex.org/projects/algorand/ - Complete report JSON: https://qrindex.org/projects/algorand/report.json - Official project website: https://www.algorand.com - Project type: Pure PoS smart-contract platform - Evaluated network: mainnet - Evaluated scope: Algorand mainnet native asset (ALGO) and base protocol layers - QRI score: 46.5/100 - Readiness stage: 3 (Migration Live) - Evidence confidence: Medium - Evaluation date: 2026-08-17 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Partial Protection, Hybrid-PQ, PQ-Recoverable ### Summary Algorand is in an active transition phase (Stage 3: Migration Live). State proofs have been secured with Falcon-1024 signatures since 2022, and a native Falcon-1024 account upgrade (v5.0.0) has passed consensus and is in cooldown for mainnet activation. However, as of the evaluation date, default spend authorization remains entirely Ed25519-based, and the consensus layer (VRF and validator signatures) is completely classical. All circulating value is held in quantum-vulnerable accounts, and no independent cryptographic audit of the PQ implementation is documented. These gaps result in multiple material caps that limit the final QRI stage and score. ### Critical quantum blockers - Consensus authentication (VRF and validator signatures) remains entirely classical (Ed25519/ECVRF), creating a quantum-critical vulnerability for network finality. - Active production spend authorization defaults to Ed25519; native Falcon-1024 accounts are in v5.0.0 cooldown and not yet activated on mainnet as of 2026-08-17. - Material long-exposure quantum-vulnerable value exists in legacy Ed25519 accounts with no evidenced deprecation, freeze, or burn policy for unmigratable balances. ### Principal risks - Consensus layer (VRF/sortition) remains entirely classical and quantum-vulnerable. - All circulating supply is held in quantum-vulnerable Ed25519 accounts until native Falcon accounts activate and users migrate. - Default account creation will remain classical even after the native Falcon upgrade, perpetuating the vulnerable surface. - Absence of independent audit for the Falcon implementation introduces unverified cryptography risk. - No forced migration, freeze, or deprecation mechanism for legacy Ed25519 accounts has been proposed or implemented. ## Aptos (APT) - Project page: https://qrindex.org/projects/aptos/ - Complete report JSON: https://qrindex.org/projects/aptos/report.json - Official project website: https://www.coingecko.com/en/coins/aptos - Project type: blockchain network - Evaluated network: Aptos Mainnet - Evaluated scope: Native asset (APT), base-layer accounts, consensus, ZKP/privacy layers, encrypted mempool - QRI score: 20/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-12 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ECC-Only Production ### Summary Aptos is a Move-based PoS L1 blockchain that relies entirely on classical cryptography in production: Ed25519 for user transaction signatures, BLS12-381 for validator consensus authentication and per-epoch threshold encryption, and Groth16/BN254 for zero-knowledge proof verification. All active production cryptographic primitives are quantum-vulnerable to Shor's algorithm. AIP-137, authored by Aptos Labs Head of Cryptography Alin Tomescu and accepted by governance in early 2026, proposes adding SLH-DSA-SHA2-128s (FIPS 205, NIST-standardized hash-based PQ signature) as an optional post-quantum account signature scheme. The implementation code has been merged into aptos-core v1.41.5 (PRs #18293, #18300) behind feature flag 107, with unit tests, e2e smoke tests, and feature-gated gas pricing. However, the feature flag is NOT enabled on mainnet—no user can create or use a PQ account, and 0% of signing traffic or value-at-risk is protected. The Aptos account model provides a strong structural advantage: public keys are stored as account metadata with mutable authentication keys, allowing users to rotate to a PQ key without moving assets. This makes migration architecturally straightforward once the PQ scheme is activated. However, consensus (BLS12-381), ZKP verifiers (Groth16/BN254), Bulletproofs, and KZG commitments have no PQ migration proposals or implementation timelines. QRI Score of 20 reflects Stage 2 (Mitigation/Development): a well-designed PQ proposal exists with merged code and accepted governance, but no production users are materially protected against quantum attacks as of the evaluation date. The score is capped at 40 by both the Stage 2 cap and the Readiness & Risk Cap for active production spend authorization remaining entirely ECC-only. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519/ECDSA-only on mainnet. SLH-DSA-SHA2-128s code (AIP-137) is merged but feature flag 107 is NOT enabled. No user can create or use a PQ account. All APT is held in quantum-vulnerable classical accounts. - Validator consensus authentication uses BLS12-381 multi-signatures and threshold encryption with no PQ alternative proposed or implemented. A quantum adversary could forge validator signatures and compromise consensus finality. - ZKP verifiers use Groth16/BN254 (quantum-vulnerable pairings). Bulletproofs range proofs and KZG commitments (encrypted mempool) are also quantum-vulnerable. No PQ migration proposal exists for any of these layers. ### Principal risks - All native APT and token value on Aptos mainnet is held in Ed25519/ECDSA accounts that are vulnerable to offline quantum key-recovery attacks. A sufficiently capable CRQC could derive private keys from exposed public keys and drain all classical accounts with no time constraint. - Validator consensus finality can be compromised by forging BLS12-381 multi-signatures, enabling a quantum adversary to finalize fraudulent blocks or prevent honest finality. - ZKP-based features (Keyless accounts via Groth16/BN254, Confidential Assets via Bulletproofs) and encrypted mempool (KZG commitments) rely on quantum-vulnerable pairing assumptions. A quantum adversary could forge ZK proofs to create counterfeit assets or decrypt mempool transactions. - No migration, freeze, deprecation, or burn mechanism exists for quantum-vulnerable legacy accounts. If a CRQC emerges before migration is complete, all exposed classical value could be stolen with no protocol-level recourse. - The AIP-137 SLH-DSA implementation has no independent cryptographic audit. The dependency on RustCrypto slh-dsa v0.2.0-rc.4 (community-maintained, pre-release) introduces supply-chain and implementation-correctness risk. - CLI, indexer, and developer documentation gaps mean that even if feature flag 107 were enabled today, practical user migration tooling would be incomplete. ## Arbitrum (ARB) - Project page: https://qrindex.org/projects/arbitrum/ - Complete report JSON: https://qrindex.org/projects/arbitrum/report.json - Official project website: https://www.coingecko.com/en/coins/arbitrum - Project type: L2 network token - Evaluated network: Arbitrum One (Ethereum L2 Optimistic Rollup) - Evaluated scope: Arbitrum One optimistic rollup (Nitro/BoLD), ARB token, canonical bridge to Ethereum L1, AnyTrust DAC (Arbitrum Nova), sequencer, and L1 settlement dependency - QRI score: 4.19/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-08-12 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ECC-only spend authorization, BLS12-381 AnyTrust DAC, L1 bridge/settlement dependency, No project-authored quantum risk assessment, No PQC deployment, Crypto-agility surfaces present but unused for PQ, External assessment only ### Summary Arbitrum is an optimistic Ethereum L2 rollup whose entire production cryptographic stack is classical: ECDSA secp256k1 for EOAs, the centralized sequencer/batch-poster, and DAS store requests; BLS12-381 for AnyTrust DAC (Nova); and Ethereum L1 for bridge escrow, batch settlement, and BoLD fraud-proof arbitration. Offchain Labs has published no quantum risk assessment, cryptographic inventory, or migration roadmap, and no PQC primitive is deployed anywhere in the Nitro stack. The community has flagged quantum exposure in a forum technical overview, and external evaluators have produced independent assessments, but these are not project-authored. Architectural crypto-agility surfaces exist (EIP-7702, ERC-4337, Stylus WASM precompiles) but are latent and unused for quantum defense. The resulting Factor Score of 4.19 is capped by the absence of a public cryptographic inventory (Readiness & Risk Cap 10), yielding a QRI Score of 4.19 at Stage 1 (Quantum Risk Assessed). Arbitrum's quantum readiness is fundamentally inherited from and bounded by Ethereum L1's own classical migration timeline. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published by Offchain Labs or the Arbitrum Foundation (Readiness & Risk Cap: 10). - Active production spend authorization is entirely ECDSA secp256k1 (EOAs) with no PQC or hybrid path on mainnet (Readiness & Risk Cap: 40). - The canonical Arbitrum-to-Ethereum bridge and rollup settlement depend on Ethereum L1, which remains ECDSA/classical, permitting unrestricted two-way flow of value into a non-PQ-secure system (Readiness & Risk Cap: 50). - AnyTrust data availability (Arbitrum Nova) uses BLS12-381 threshold signatures, which are vulnerable to Shor's algorithm. - Bridge escrow and governance are controlled by upgradeable proxy contracts under ECDSA multisigs (Arbitrum DAO + Security Council), which could be compromised independently of individual user key exposure. ### Principal risks - All EOAs that have sent a transaction on Arbitrum One have exposed secp256k1 public keys on-chain, creating a long-exposure, offline-attackable surface with no mitigation, freeze, or recovery path. - The sequencer's ECDSA batch-poster key and DAS store-request signing key are single-signer classical keys; compromise would permit batch forgery/censorship until BoLD dispute resolution, which itself relies on ECDSA on Ethereum. - Arbitrum Nova's AnyTrust DAC uses BLS12-381 threshold signatures, which Shor's algorithm breaks; DAC key compromise could undermine data availability and force chain recovery. - The canonical bridge escrow and its upgrade authority are controlled by ECDSA multisigs (Security Council + DAO); a quantum-capable adversary compromising those keys could drain bridged assets independently of individual user-level key exposure. - Rollup finality and fraud-proof arbitration settle on Ethereum L1, so even a hypothetical L2-level PQC deployment would remain capped by Ethereum's classical ECDSA settlement and bridge. - No value-at-risk measurement exists for dormant/unmigratable exposed-key holdings vs. bridge-locked assets, making precise coverage unattestable and leaving all known pools unprotected. - Arbitrum cannot independently achieve quantum readiness; it must depend on Ethereum L1's PQC migration, which targets core infrastructure by approximately 2029 but has no guaranteed timeline. ## Artificial Superintelligence Alliance (FET) - Project page: https://qrindex.org/projects/fetch-ai/ - Complete report JSON: https://qrindex.org/projects/fetch-ai/report.json - Official project website: https://www.coingecko.com/en/coins/fetch-ai - Project type: AI network token - Evaluated network: Fetch.ai Mainnet (fetchhub-4, Cosmos SDK / CometBFT) - Evaluated scope: Native FET token on the Fetch.ai Cosmos SDK mainnet (fetchhub-4). ERC-20 and BSC bridged FET representations are noted as out-of-scope bridge/host-chain dependencies. Future ASI:Chain (separate L1, DevNet/TestNet) is noted as roadmap context only. - QRI score: 9/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Low - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Only Production, Mitigation / Development, PQ-Aware Leadership ### Summary The Artificial Superintelligence Alliance (FET) operates its production mainnet (fetchhub-4) on a standard Cosmos SDK / CometBFT stack using secp256k1 and ed25519 cryptography across all critical layers: spend authorization, consensus authentication, P2P node identity, and wallet/custody paths. No post-quantum or hybrid cryptographic protection exists on the current production mainnet. CEO Ben Goertzel has publicly articulated a quantum-oriented vision for the upcoming ASI:Chain (a separate L1 blockchain, currently in closed DevNet beta, with mainnet targeted late 2026/early 2027), describing a modular encryption layer supporting lattice-based and hash-based PQC schemes. However, the ASI:Chain DevNet wallet generator uses secp256k1, no PQC is demonstrable in any public DevNet artifact, no formal specification or algorithm selection has been published, and no independent audit exists. The project receives credit for Stage 2 (Mitigation / Development) due to the existence of ASI:Chain design work, active DevNet, and strong public leadership awareness of quantum threats. The QRI Score of 9/100 reflects a very low factor score (9.06) constrained by the absence of a public cryptographic inventory for the current mainnet (Readiness & Risk Cap: 10), with all production value-at-risk quantum-vulnerable and no current migration path. The score indicates that while mitigation engineering is underway for a future separate chain, current production users have no quantum protection whatsoever. ### Critical quantum blockers - No public cryptographic inventory for the current production mainnet (fetchhub-4) has been published — quantum-critical properties cannot be systematically verified from public documentation. - All production spend authorization (transaction signatures) uses secp256k1 and ed25519 — fully vulnerable to Shor's algorithm on a cryptographically relevant quantum computer (CRQC). - All consensus authentication (validator signatures) uses secp256k1/ed25519 via CometBFT/Tendermint — quantum compromise enables consensus manipulation and finality reversal. - Material long-exposure quantum-vulnerable value (all native FET balances, validator keys, staking delegations, treasury/exchange custody keys) exists with no migration, freeze, deprecation, burn, or recovery path on the current mainnet. ### Principal risks - All native FET balances on the Fetch.ai mainnet (fetchhub-4) are secured by secp256k1/ed25519 keys, which are fully breakable by a cryptographically relevant quantum computer (CRQC) running Shor's algorithm. - Validator consensus authentication uses Ed25519/secp256k1; a quantum adversary who compromises validator keys could forge consensus votes, manipulate finality, and halt the chain. - Long-exposure public keys from historical transactions are permanently recorded on-chain and harvestable now for later decryption (harvest-now, decrypt-later / HNDL attack). - No freeze, burn, deprecation, or migration mechanism exists for quantum-vulnerable accounts on the current mainnet; all legacy balances remain fully exposed. - ASI:Chain is a separate blockchain, not a fetchhub-4 upgrade — no documented path exists for FET holders to achieve quantum-safe custody without relying on an unspecified future cross-chain migration whose mechanics are undefined. - The project's quantum readiness posture depends entirely on a future chain (ASI:Chain) whose PQC implementation is not yet verifiable, audited, or deployed even in testnet, and whose DevNet wallet generator uses secp256k1. - Bridged FET representations on Ethereum, BSC, and Cardano inherit the quantum vulnerabilities of those host chains, compounding exposure for holders using those representations. - No public cryptographic inventory exists for the current mainnet, making it impossible to systematically verify all quantum-critical attack surfaces from public documentation. ## Aster (ASTER) - Project page: https://qrindex.org/projects/aster-2/ - Complete report JSON: https://qrindex.org/projects/aster-2/report.json - Official project website: https://www.coingecko.com/en/coins/aster-2 - Project type: cryptoasset - Evaluated network: Aster Chain (L1) + Multi-chain (BEP-20, ERC-20, etc.) - Evaluated scope: Native asset (ASTER) on Aster Chain L1 and multi-chain token representations - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Very Low - Evaluation date: 2026-08-17 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Partial Protection ### Summary Aster (ASTER) is a privacy-focused L1 blockchain with a multi-chain token presence, launched in 2026. The project uses classical PoSA consensus, ECDSA/EdDSA spend authorization, and ZK-based privacy features with no evidence of post-quantum cryptography implementation, design, or roadmap. Core chain contracts are closed-source, preventing independent verification of cryptographic primitives, signature algorithms, or ZK proof systems. Validator-signed bridges connect Aster Chain to quantum-vulnerable host chains without restrictions. No audits, cryptographic inventories, threat models, or quantum-readiness plans have been published. The project receives a Stage 1 (Quantum Risk Assessed) rating with Very Low confidence due to the complete absence of post-quantum cryptography evidence and the closed-source nature of critical implementations. All critical layers (spend authorization, consensus, privacy, bridges) remain quantum-vulnerable by default. ### Critical quantum blockers - No evidence of post-quantum cryptography implementation, design, or roadmap for any critical layer (spend authorization, consensus, privacy, bridges). - Closed-source core implementation prevents verification of cryptographic primitives and quantum-vulnerability status. - Classical PoSA consensus and validator-signed bridges are quantum-vulnerable by default with no disclosed mitigation. - Privacy layer (ZK proofs, stealth addresses) likely relies on classical ECC/pairing assumptions with no PQ alternatives evidenced. - No public cryptographic inventory or quantum threat model exists. ### Principal risks - All user funds on Aster Chain are secured by quantum-vulnerable ECDSA/EdDSA signatures. - Validator signatures and bridge verification are quantum-vulnerable, risking consensus security and cross-chain asset integrity. - Privacy features (ZK-encrypted orders, stealth addresses) likely depend on classical pairing-based cryptography, creating long-exposure structural risk. - Closed-source core implementation prevents independent verification of cryptographic primitives and quantum vulnerability surface. - Multi-chain token presence on BNB Chain, Ethereum, Solana, and Arbitrum inherits quantum vulnerabilities of those host chains. - No migration path, freeze mechanism, or deprecation policy for quantum-vulnerable accounts or long-exposure balances. - Lack of quantum-specific incident-response plan or emergency governance process for quantum-related vulnerabilities. ## Audiera (BEAT) - Project page: https://qrindex.org/projects/audiera/ - Complete report JSON: https://qrindex.org/projects/audiera/report.json - Official project website: https://audiera.fi/ - Project type: AI network token - Evaluated network: BNB Smart Chain (BSC) - Evaluated scope: BEP-20 token (0xcf3232b85b43bca90e51d38cc06cc8bb8c8a3e36) inheriting BNB Chain L1 security, plus token-specific admin/governance keys - QRI score: 14/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Inherits L1 Score: BNB Chain, Roadmap Only, Classical ECC Only ### Summary Audiera (BEAT) is a standard BEP-20 token on BNB Smart Chain with no custom cryptographic implementations. Per QRI Section 7.2, it inherits the base-layer QRI posture of BNB Chain. As of June 2026, BNB Chain mainnet relies entirely on classical ECDSA (secp256k1) for transaction signatures and BLS12-381 for validator consensus — both quantum-vulnerable. BNB Chain has published a research report (May 2026) and produced a closed draft prototype (GitHub PR #3660, April–May 2026) exploring migration to ML-DSA-44 and pqSTARK, but no testnet or mainnet deployment exists. The prototype confirms 40% throughput reduction under PQ load. BEAT's ~$503M market cap (~288M circulating supply) is fully exposed to quantum key-recovery attacks on both user EOAs and token admin/owner keys. QRI Score = 14 (Stage 1, Factor Score 14.42, capped at 20 by Stage 1 cap, binding minimum = 14). ### Critical quantum blockers - Active production spend authorization on BNB Chain mainnet remains entirely ECDSA (secp256k1) — quantum-vulnerable to Shor's algorithm. All BEAT token transfers, approvals, and interactions are secured only by classical ECC. - BEAT token admin/owner keys secured by BNB Chain classical ECC. Quantum-enabled key recovery of the owner address would allow unauthorized ownership transfer, potentially enabling token minting, freezing, or other administrative actions. - BNB Chain consensus validator signatures remain BLS12-381 — quantum-vulnerable. A quantum compromise of BSC consensus could enable chain reorganization affecting all tokens including BEAT. - No production PQ or hybrid-PQ protection deployed on BNB Chain mainnet. BNB Chain's PQ work remains at the research-report and closed-draft-prototype stage with no testnet or mainnet deployment timeline. ### Principal risks - All BEAT token transfers, approvals, and holdings are secured exclusively by BNB Chain's ECDSA (secp256k1) signatures. A cryptographically relevant quantum computer running Shor's algorithm could recover private keys from publicly exposed public keys, enabling theft of all BEAT held in transacted EOAs and long-exposure addresses. - BEAT token contract owner address (Ownable pattern) is secured by classical ECC. Quantum compromise would allow the attacker to call transferOwnership() and gain full administrative control over the token contract — potentially enabling minting, burning, pausing, or freezing of user funds. - BNB Chain's BLS12-381 validator signatures are permanently stored on-chain, enabling harvest-now-decrypt-later attacks. A future quantum adversary could retroactively forge validator attestations, potentially compromising consensus finality for historical blocks. - The BNB Chain PQ migration research is explicitly described as 'research and evaluation, not a response to any immediate security threat.' No testnet fork, mainnet activation date, or production deployment commitment exists. The 40% throughput penalty documented in bench tests indicates significant engineering challenges remain. - No Audiera-specific quantum risk assessment, cryptographic inventory, migration plan, or incident-response process has been published. The project's quantum readiness depends entirely on BNB Chain's L1 migration trajectory, over which Audiera has no direct control. ## Avalanche (AVAX) - Project page: https://qrindex.org/projects/avalanche-2/ - Complete report JSON: https://qrindex.org/projects/avalanche-2/report.json - Official project website: https://www.coingecko.com/en/coins/avalanche-2 - Project type: blockchain network - Evaluated network: Avalanche Mainnet - Evaluated scope: Native asset (AVAX), consensus, P2P, bridge, and C-Chain EVM layer - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-08-19 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Not Assessed ### Summary Avalanche relies entirely on classical cryptography across all critical layers. Spend authorization uses ECDSA (secp256k1), consensus and Avalanche Warp Messaging (AWM) use BLS12-381, and the Avalanche Bridge relies on ECDSA/TLS. The C-Chain's EVM compatibility means public keys are permanently exposed after the first transaction, creating a growing pool of long-exposure quantum-vulnerable value. While the fast finality of the network reduces the short-exposure attack window, there is currently no formal PQC migration roadmap, prototype, or deployed mitigation. No public cryptographic inventory or quantum threat model exists. The project is classified as Stage 1 (Quantum Risk Assessed) only because the threat is acknowledged in broader ecosystem discussions, but no meaningful production protection or migration mechanism is in place. ### Critical quantum blockers - Active production spend authorization remains entirely ECC (secp256k1 ECDSA) with no PQC or hybrid-PQC path. - Consensus authentication relies on BLS12-381, which is quantum-vulnerable. - No public cryptographic inventory, quantum threat model, or migration roadmap exists. - Material long-exposure quantum-vulnerable value exists on C-Chain (transacted EOAs) with no migration, freeze, or recovery path. ### Principal risks - Quantum-enabled theft of long-exposure C-Chain EOAs and reused addresses. - Quantum-enabled forgery of transactions via ECDSA key recovery. - Quantum-enabled consensus compromise via BLS12-381 validator signature forgery. - Quantum-enabled bridge compromise via classical signer set or verification layer. - No migration path for dormant or unmigratable quantum-vulnerable value. ## Beldex (BDX) - Project page: https://qrindex.org/projects/beldex/ - Complete report JSON: https://qrindex.org/projects/beldex/report.json - Official project website: https://www.coingecko.com/en/coins/beldex - Project type: DeFi protocol token - Evaluated network: Beldex mainnet - Evaluated scope: Native BDX asset, Beldex blockchain, cross-chain bridge dependencies (BSC, Ethereum, Solana, Arbitrum, Base) - QRI score: 3.5/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Classical ECC, Privacy Chain, Ed25519-Only, Quantum Risk Assessed ### Summary Beldex (BDX) is a Monero/CryptoNote‑fork privacy blockchain operating a PoS masternode consensus with classical elliptic curve cryptography across all critical layers. As of June 2026, spend authorization uses Ed25519/EdDSA, privacy is provided via ring signatures, stealth addresses, RingCT, and Bulletproofs++ — all of which rely on the hardness of the elliptic curve discrete logarithm problem and are fully vulnerable to Shor's algorithm. The project has acknowledged quantum risk in blog posts and roadmap items, with PQC research scheduled to begin Q2 2026, a lattice‑based cryptography POC planned for Q3 2026, and a quantum‑safe hardfork targeted for Q1 2027. However, no PQC implementation, prototype, testnet, technical specification, or migration tooling exists as of the evaluation date. The entire circulating supply, treasury holdings (~1.74B BDX ecosystem wallet, ~214.5M BDX seed/VC wallet), exchange balances, and cross‑chain bridged value remain exposed to long‑exposure quantum key‑recovery attacks with no migration, freeze, or deprecation mechanism in place. The project scores 3.5/100, placing it at Stage 1 (Quantum Risk Assessed) with a 'Roadmap Only' tag. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519/EdDSA-only — fully vulnerable to Shor's algorithm key recovery - All privacy layers (ring signatures, stealth addresses, RingCT, Bulletproofs++) rely on elliptic curve cryptography vulnerable to quantum attack - Consensus-critical masternode authentication uses classical ECC signatures - No PQC implementation, prototype, testnet, or credible mitigation design exists — only roadmap items for future research - Material long-exposure quantum-vulnerable value (treasury wallets, exchange holdings, circulating supply) exists with no migration, freeze, deprecation, burn, recovery, or policy path ### Principal risks - All BDX spend authorization relies on Ed25519, which is breakable by a sufficiently powerful quantum computer using Shor's algorithm, enabling theft of any funds whose public key is exposed. - Ring signatures and stealth addresses provide privacy only under classical computational assumptions; a quantum adversary could deanonymize transactions and link stealth addresses to spend keys. - RingCT and Bulletproofs++ range proofs rely on Pedersen commitments and elliptic curve operations vulnerable to quantum attack, potentially compromising supply integrity. - Masternode consensus authentication uses classical signatures, enabling a quantum adversary to forge validator participation and potentially compromise block production and finality. - Large treasury wallets with published view keys represent concentrated long‑exposure value‑at‑risk with no announced migration or protection timeline. - Cross‑chain BDX deployments on BSC, Ethereum, Arbitrum, Base, Near, Hyperliquid, and Solana expand the quantum‑vulnerable surface across multiple classical ECC ecosystems. - The 'harvest now, decrypt later' threat applies to BChat encrypted messages and any data encrypted with classical ECC that could be stored for future quantum decryption. - No migration mechanism, user tooling, exchange coordination, or emergency governance process exists for a quantum transition, making future migration execution highly uncertain. ## BFUSD (BFUSD) - Project page: https://qrindex.org/projects/bfusd/ - Complete report JSON: https://qrindex.org/projects/bfusd/report.json - Official project website: https://www.coingecko.com/en/coins/bfusd - Project type: stablecoin - Evaluated network: None (Centralized Binance Platform Asset) - Evaluated scope: Centralized exchange-internal reward-bearing margin asset. No blockchain, no on-chain contract, no public-key cryptography, no consensus, no P2P network. - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: None - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Centralized Asset, No Blockchain, Non-Custodial-Withdrawal-Unavailable ### Summary BFUSD is a centralized, internal reward-bearing margin asset on the Binance exchange platform. It is not a blockchain token — it has no smart contract, no on-chain address, no public-key cryptography, no consensus mechanism, no P2P network, and cannot be withdrawn to external wallets. All blockchain-specific QRI subfactors are genuinely N/A by architecture. The QRI framework, designed for blockchain projects, does not meaningfully apply. The Factor Score is 0 because no blockchain cryptographic layers exist to evaluate. The Stage 0 cap of 5 and the 'No evidence of blockchain quantum readiness' Readiness & Risk Cap of 0 both bind, yielding a final QRI Score of 0. Quantum risk to the ~$1.37B in BFUSD value is entirely inherited from Binance's centralized Web2 infrastructure — which currently relies on classical cryptography with no public PQC migration roadmap — but this centralized-infrastructure risk is outside the QRI's blockchain scope. Users should monitor Binance for any PQC infrastructure upgrades and for any future on-chain deployment of BFUSD, which would require a full QRI re-evaluation. ### Critical quantum blockers - No critical quantum blocker analysis returned. ### Principal risks - CENTRALIZED INFRASTRUCTURE QUANTUM RISK (out of QRI scope): Binance's internal systems protecting BFUSD balances — including TLS termination, HSM key management, database encryption, and user authentication — rely on classical cryptography (RSA, ECC) with no publicly disclosed PQC migration plan. A cryptographically relevant quantum computer could theoretically compromise these centralized systems, though the attack surface is entirely different from blockchain key-recovery attacks. - FUTURE ON-CHAIN DEPLOYMENT RISK: If Binance deploys BFUSD as an on-chain token (BEP-20, ERC-20, etc.), it would immediately inherit all standard blockchain quantum vulnerabilities (ECC spend authorization, exposed public keys, bridge dependencies) unless launched with PQ/hybrid-PQC controls from genesis. - PLATFORM CONCENTRATION RISK: All BFUSD value (~$1.37B) is custodied within a single centralized entity. Any compromise of Binance's infrastructure — quantum or classical — could affect all BFUSD holders simultaneously. - EVIDENCE TRANSPARENCY RISK: Binance has published no cryptographic inventory, no threat model, no PQC roadmap, and no independent audit of the infrastructure protecting BFUSD. The quantum-readiness posture of the underlying centralized systems is entirely opaque to external evaluation. - CONFUSION RISK: BitFi's 'bfUSD' is a separate ERC-4626 stablecoin on Ethereum with different architecture, issuer, and risk profile. Users should not conflate the two projects. ## Bitcoin (BTC) - Project page: https://qrindex.org/projects/bitcoin/ - Complete report JSON: https://qrindex.org/projects/bitcoin/report.json - Official project website: https://bitcoin.org - Project type: PoW chain - Evaluated network: Bitcoin mainnet - Evaluated scope: Native asset (BTC), production mainnet scope, PoW/UTXO chain - QRI score: 19.98/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-16 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Partial Protection, Roadmap Only ### Summary Bitcoin's production mainnet spend authorization remains entirely ECDSA and BIP-340 Schnorr over secp256k1 — both quantum-vulnerable ECC — with no post-quantum or hybrid signature support as of 2026-08-16. Draft consensus proposals (BIP-360 P2MR, BIP-361 Legacy Signature Sunset) and prototype work (Blockstream SHRINCS on Liquid sidechain, Falcon-512 demo fork, BTQ ML-DSA canary network) exist but none are activated on mainnet. Over 34% of supply has revealed public keys on-chain (BIP-361) and approximately 1.6 million BTC sits in P2PK outputs with permanently exposed keys (CoinShares), creating material long-exposure value-at-risk with no live migration, freeze, or deprecation path. Bitcoin's consensus and state integrity layers are hash-based (SHA-256) and quantum-resistant by design, but active spend authorization is entirely ECC-dependent. The Bitcoin Security Consortium (formed July 2026) demonstrates institutional coordination for PQ R&D. QRI Score = 20.0 (Stage 2: Mitigation/Development), capped at 40 by ECC-only production spend authorization. Users should monitor BIP-360/361 and PQ signature developments; no migration action is possible on mainnet today. ### Critical quantum blockers - Active production spend authorization remains entirely ECC-only (ECDSA and BIP-340 Schnorr over secp256k1) with no PQC or hybrid-PQC support on mainnet. Readiness & Risk Cap: 40. - Material long-exposure quantum-vulnerable value exists (~1.6M BTC in P2PK outputs with permanently exposed public keys per CoinShares; >34% of supply with revealed public keys on-chain per BIP-361) with no live migration, freeze, deprecation, burn, or recovery path. Readiness & Risk Cap: 55 (subsumed by the 40 cap). ### Principal risks - All Bitcoin transaction signatures (ECDSA and Schnorr over secp256k1) are quantum-vulnerable — a CRQC can recover private keys from exposed public keys and forge signatures, enabling theft of coins. - Approximately 1.6 million BTC in legacy P2PK outputs have permanently exposed public keys (long-exposure, offline-attackable with no time constraint once a CRQC exists). - Over 34% of all bitcoin have revealed a public key on-chain (P2PK, reused P2PKH/P2WPKH, P2TR key-path outputs) — these UTXOs are vulnerable to long-range quantum attacks. - P2TR (Taproot) key-path outputs store the tweaked public key directly on-chain, representing a quantum-exposure regression compared to hash-protected P2PKH/P2WPKH addresses. - No mainnet migration path is available to users today; users cannot opt into PQ-protected addresses or signatures on Bitcoin mainnet. - Unmigratable/lost coins (e.g., Satoshi-era ~1M BTC P2PK stash) lack a consensus policy for freeze, burn, or deprecation — these coins would be permanently vulnerable in a post-CRQC world. - BIP-361 requires a 'TBD Post Quantum Signature BIP' that does not yet exist — the full migration mechanism is incomplete even at the proposal level. - Bitcoin's soft-fork governance model introduces significant timeline uncertainty; Taproot took ~22 months from BIP to activation for an uncontroversial upgrade. ## Bitcoin Cash (BCH) - Project page: https://qrindex.org/projects/bitcoin-cash/ - Complete report JSON: https://qrindex.org/projects/bitcoin-cash/report.json - Official project website: https://bitcoincash.org - Project type: PoW chain - Evaluated network: mainnet - Evaluated scope: Native asset (BCH) on Bitcoin Cash PoW UTXO chain - QRI score: 40.88/100 - Readiness stage: 3 (Migration Live) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Partial Protection, PQ-Recoverable, Opt-in PQ Path Available ### Summary Bitcoin Cash (BCH) is a PoW UTXO chain that activated the 'Layla' / CashVM upgrade on May 15, 2026, introducing VM primitives (Loops, Functions, Bitwise, P2S) that enable efficient opt-in post-quantum vaults via Quantumroot. Quantumroot uses LM-OTS (RFC 8554, NIST SP 800-208) based on SHA-256, providing 256-bit classical and 128-bit quantum security. It was tested on Chipnet from November 2025 and is now live on mainnet. However, default spend authorization remains entirely ECDSA/Schnorr (secp256k1), and nearly all BCH value is held in classical addresses. Legacy P2PK outputs with exposed public keys and reused P2PKH addresses represent material long-exposure quantum-vulnerable value with no active migration, freeze, or enforced recovery mechanism. The challenge-based transition protocol proposed on Bitcoin Cash Research (April 2026) is a research design, not an active policy. Quantumroot has no independent audit. QRI Score of 41 reflects Stage 3 (Migration Live) with an opt-in PQ path available but default vulnerability, negligible migration coverage, and long-exposure vulnerable value capping readiness. ### Critical quantum blockers - Default spend authorization remains entirely ECDSA/Schnorr (secp256k1) on mainnet. Quantumroot provides an opt-in LM-OTS path but is not default, mandatory, or enforced. - Material long-exposure quantum-vulnerable value exists: legacy P2PK outputs with exposed public keys (inherited from pre-fork Bitcoin UTXO set) and reused P2PKH addresses have no active migration, freeze, deprecation, burn, or enforced recovery mechanism. The challenge-based transition protocol is a research proposal only. - Users can still create new quantum-vulnerable accounts by default using standard P2PKH wallets; no warnings, deprecation prompts, or restrictions prevent creation of ECDSA-only addresses. ### Principal risks - Quantum-critical: Default spend authorization is ECDSA/Schnorr-only. A CRQC running Shor's algorithm could derive private keys from public keys revealed during transaction broadcast (short-exposure) or already exposed on-chain (long-exposure). - Quantum-critical: Legacy P2PK outputs (inherited from pre-fork Bitcoin) have public keys permanently exposed on-chain. These can be attacked offline with no time constraint once a CRQC exists. BCH has no active mechanism to freeze, migrate, or burn these. - Quantum-critical: Reused P2PKH addresses have exposed public keys. Any remaining balance at a reused address is long-exposure vulnerable. No protocol-level deprecation or warning mechanism exists. - Quantum-critical uncertainty: The exact percentage of BCH supply held in quantum-exposed addresses (P2PK + reused P2PKH) is not publicly measured or attested. BTC data suggests ~30% exposure; BCH-specific data is absent. This makes migration coverage unverifiable. - Assurance: Quantumroot has no independent cryptographic audit. The developer acknowledged in July 2025 that the template 'has not yet been reviewed by anyone else.' Planned audits are not yet completed. - Operational: LM-OTS is stateful. Key reuse would catastrophically break security. Wallet implementations must maintain strict signing-state discipline. No formal evaluation of state-management safety in production wallets exists. - Operational: Quantumroot mainnet deployment is less than one month old (activated May 15, 2026). Production reliability, adoption, and operational patterns are unestablished. - Operational: No formal governance timeline exists for deprecating ECDSA, enforcing migration, or activating the challenge-based transition protocol at the consensus level. ## Bitget Token (BGB) - Project page: https://qrindex.org/projects/bitget-token/ - Complete report JSON: https://qrindex.org/projects/bitget-token/report.json - Official project website: https://www.coingecko.com/en/coins/bitget-token - Project type: exchange token - Evaluated network: Ethereum (ERC-20) / Morph Chain (Ethereum L2, native gas & governance token) - Evaluated scope: BGB as an ERC-20 token on Ethereum mainnet, including its role as native gas and governance token on Morph chain. Evaluated under Token Inheritance Rule (7.2) with token-specific admin/custody layers scored independently. - QRI score: 5/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance: Ethereum L1, Exchange Token, Quantum Risk Acknowledged, Morph Ecosystem, No Quantum-Specific Audit ### Summary Bitget Token (BGB) is a standard ERC-20 token on Ethereum that also serves as the native gas and governance token on Morph chain (Ethereum L2). Under QRI Token Inheritance Rule (7.2), BGB inherits Ethereum's quantum-vulnerable posture: all spend authorization is ECDSA-only, all Ethereum EOAs that have transacted have exposed public keys, and no production PQC protection exists on either host chain. BGB's own ERC-20 contract is minimal and non-upgradeable with no admin functions, which limits token-specific contract-level attack surface, but large value pools are concentrated in classical ECDSA multisig custody wallets controlled by Bitget exchange and the Morph Foundation. Bitget has published general educational content acknowledging quantum threats (Stage 1 awareness), but no BGB-specific cryptographic inventory, quantum risk assessment, PQC deployment, or migration plan exists. The QRI Score of 5 reflects the lowest Stage 1 readiness with no meaningful quantum protection in production. The score is constrained by the Factor Score (5.28), which is lower than both the Stage 1 cap (20) and the Readiness & Risk Cap (10, triggered by absence of public cryptographic inventory). ### Critical quantum blockers - All BGB spend authorization on Ethereum relies on ECDSA (secp256k1), which is vulnerable to Shor's algorithm. Active production spend authorization remains entirely ECC-only. - Bitget exchange holds a significant portion of BGB supply in classical ECDSA multisig cold storage, and the Morph Foundation treasury (220M BGB) relies on classical ECDSA signatures — material long-exposure quantum-vulnerable value pools with no migration path. - No public cryptographic inventory exists for BGB, its host chains, or its custody infrastructure. - Morph chain consensus, bridge infrastructure (Chainlink CCIP), and sequencer operations inherit Ethereum's quantum-vulnerable cryptographic assumptions with no independent PQC mitigation. ### Principal risks - HOST-CHAIN INHERITANCE: BGB inherits Ethereum L1's quantum vulnerability. All BGB transfers require ECDSA signatures on secp256k1, which Shor's algorithm can break. Ethereum has no production PQC protection as of June 2026 (LayerQu QRI: 25/100, Stage 2). - LONG-EXPOSURE PUBLIC KEYS: Every Ethereum EOA that has sent a BGB transaction has exposed its public key on-chain. These represent offline-attackable quantum targets with no time constraint ('harvest now, decrypt later'). BGB has ~21.8K on-chain holders, many with transacted balances. - EXCHANGE CUSTODY CONCENTRATION: Bitget exchange holds a significant portion of BGB supply in cold storage using classical ECDSA multisig wallets. A quantum compromise of these custody keys could enable theft of exchange-held BGB reserves. - MORPH FOUNDATION TREASURY: The Morph Foundation holds 220M BGB (released at 2% monthly cap) in treasury wallets secured by classical cryptography, representing a long-duration, high-value quantum target. - MORPH CHAIN DEPENDENCY: BGB is the native gas and governance token of Morph chain. Morph is an Ethereum L2 with no published quantum security posture, no PQC roadmap, and no quantum risk assessment. Any quantum attack on Morph's sequencer, bridge (Chainlink CCIP), or consensus would directly impact BGB utility and value. - CROSS-CHAIN BRIDGE RISK: BGB uses Chainlink CCIP for cross-chain transfers between Ethereum and Morph. While CCIP provides classical security guarantees, its quantum resistance is unassessed. - NO MIGRATION PATH: There is no published plan, mechanism, or timeline for migrating BGB holders, exchange custody, or Morph chain operations to quantum-safe cryptography. - DORMANT/UNMIGRATABLE HOLDINGS: A portion of BGB supply is held in dormant or inaccessible addresses. With no freeze, burn, or salvage policy for quantum-vulnerable unmigratable value, these holdings would remain perpetually vulnerable. ## Bittensor (TAO) - Project page: https://qrindex.org/projects/bittensor/ - Complete report JSON: https://qrindex.org/projects/bittensor/report.json - Official project website: https://www.coingecko.com/en/coins/bittensor - Project type: AI network token - Evaluated network: mainnet (finney) - Evaluated scope: native asset TAO on Subtensor blockchain - QRI score: 10/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: ECC-Only Signatures, Long-Exposure Vulnerable Keys, No Public Migration Roadmap, Partial Protection ### Summary Bittensor (TAO) is a Substrate-based blockchain using sr25519 (Schnorr signatures over Curve25519) for all spend authorization, consensus authentication, and node identity. All coldkey and hotkey public keys are long-exposure on-chain. The Opentensor Foundation has not published a post-quantum cryptographic inventory, quantum threat model, or migration roadmap. The MEV Shield pallet uses NIST-standardized ML-KEM-768 for transaction encryption against front-running, demonstrating quantum-awareness, but this does not protect asset ownership from quantum key-recovery attacks. Ecosystem subnets perform quantum computing research, but this is application-layer activity that does not confer quantum resistance to the TAO token or Subtensor protocol. The project inherits the Substrate/Polkadot cryptographic roadmap and would likely depend on upstream PQ signature support. QRI Score of 10 reflects Stage 1 (Quantum Risk Assessed) status capped by the absence of a public cryptographic inventory: quantum risk is implicitly acknowledged through MEV Shield design and ecosystem activity, but no meaningful production protection exists, and no formal risk assessment or migration plan has been published. ### Critical quantum blockers - Active production spend authorization is entirely sr25519 (Schnorr/EdDSA over Curve25519). All coldkey and hotkey signatures are quantum-vulnerable to Shor's algorithm. - No public post-quantum cryptographic inventory or quantum threat model has been published by the Opentensor Foundation. - No public post-quantum migration roadmap, prototype, testnet, or proposal exists for the Subtensor base layer. - All on-chain public keys are long-exposure (visible on-chain indefinitely), enabling offline quantum key-recovery attacks with no time constraint. - Consensus authentication (Aura block production via sr25519, GRANDPA finality via ed25519) is entirely ECC-based and quantum-vulnerable. ### Principal risks - All TAO holdings (coldkeys and hotkeys) are secured by sr25519 signatures vulnerable to Shor's algorithm. A cryptographically relevant quantum computer could recover private keys from on-chain public keys and steal funds with no prior warning. - Coldkeys control staked TAO and high-value operations. Their public keys are permanently exposed on-chain, creating indefinite attack windows. - Consensus (Aura + GRANDPA) relies entirely on classical signatures. A quantum-enabled validator could potentially forge blocks or disrupt finality. - The project has no published migration path, leaving users with no guidance on how or when their assets might be protected. - Dependence on upstream Substrate/Polkadot PQ development creates timeline uncertainty beyond Bittensor's direct control. - The EVM compatibility layer (EVM pallet) introduces additional ECDSA/secp256k1 attack surface for smart-contract interactions. ## BlackRock USD Institutional Digital Liquidity Fund (BUIDL) - Project page: https://qrindex.org/projects/blackrock-usd-institutional-digital-liquidity-fund/ - Complete report JSON: https://qrindex.org/projects/blackrock-usd-institutional-digital-liquidity-fund/report.json - Official project website: https://www.coingecko.com/en/coins/blackrock-usd-institutional-digital-liquidity-fund - Project type: stablecoin - Evaluated network: Multi-chain (Ethereum, Solana, Aptos, Avalanche, BNB Chain, OP Mainnet, Arbitrum, Polygon) - Evaluated scope: Tokenized RWA fund (standard ERC-20 and equivalent tokens on multiple L1s/L2s via Securitize); inherits host-chain QRI plus token-specific admin/governance, oracle, and bridge dependencies - QRI score: 4.83/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance: Inherits L1 Score (Ethereum, Solana, Avalanche, Optimism, Arbitrum, Polygon, BNB Chain, Aptos), Not Assessed (by project): No public cryptographic inventory or quantum threat model published by BlackRock or Securitize, Quantum-Vulnerable: All critical layers rely on classical ECDSA/Ed25519/Schnorr cryptography, No PQC Roadmap: No post-quantum migration plan, prototype, testnet, or mainnet work exists ### Summary BUIDL is a tokenized money market fund issued by BlackRock and administered by Securitize, deployed as standard ERC-20 and equivalent tokens across nine blockchain networks. It has no native blockchain protocol or custom cryptographic implementation. Per the QRI Token Inheritance rule (Section 7.2), BUIDL shares the base-layer QRI score of its host chains — all of which rely entirely on quantum-vulnerable classical cryptography (ECDSA, Ed25519, Schnorr on secp256k1). Beyond host-chain inheritance, BUIDL has token-specific quantum-critical vulnerabilities: (1) admin/upgrade keys controlled by a single quantum-vulnerable ECDSA-based Fireblocks MPC address, (2) Chronicle Proof of Assets oracle attestations verified via classical Schnorr signatures, and (3) Wormhole bridge dependencies that allow unrestricted value flow between quantum-vulnerable systems. No public cryptographic inventory, quantum threat model, PQC roadmap, migration plan, prototype, or testnet exists. Third-party assessments (EternaX, StablePQC) independently confirm the critical exposure. The QRI Score of 5 reflects the 'No public cryptographic inventory' Readiness & Risk Cap binding at 10 combined with a raw Factor Score of ~4.83. BUIDL is at Stage 1 (Quantum Risk Assessed) — third-party risk assessment exists, but the project itself has published no quantum-specific assessment and has no meaningful production protection. ### Critical quantum blockers - No public cryptographic inventory has been published by BlackRock or Securitize for BUIDL; this applies the 'No public cryptographic inventory' Readiness & Risk Cap at QRI 10. - All spend authorization for token transfers relies entirely on host-chain ECC/EdDSA (Ethereum secp256k1, Solana Ed25519, etc.) — active production spend authorization remains ECC-only. - Admin/upgrade keys for the BUIDL proxy contract are controlled by a single Securitize-owned address (backed by Fireblocks ECDSA-based MPC); on-chain, this is a single point of quantum-vulnerable failure with ~$2.5B AUM at risk. - Chronicle Proof of Assets oracle attestations are verified using Schnorr signatures on secp256k1, creating a quantum-vulnerable state-integrity dependency. - Wormhole bridge infrastructure enables two-way value flow between quantum-vulnerable host chains without quantum-safe restrictions. - No post-quantum roadmap, migration plan, prototype, testnet, or mitigation design of any kind exists for BUIDL. ### Principal risks - Admin key compromise via quantum attack: A CRQC capable of breaking secp256k1 could derive the private key of the BUIDL proxy contract owner from its permanently exposed on-chain public key, enabling unauthorized contract upgrades, token minting, or fund draining across all deployments. - Oracle attestation forgery: Chronicle's Schnorr signature scheme on secp256k1 is quantum-vulnerable; a quantum attacker could forge Proof of Assets attestations, misrepresenting the fund's underlying Treasury holdings on-chain. - Cross-chain bridge exploitation: Wormhole's validator/signer set relies on classical cryptography; quantum compromise of bridge signers could enable unauthorized cross-chain minting or locking of BUIDL tokens. - Holder wallet exposure: Any BUIDL holder address that has sent a transaction has permanently exposed its ECDSA public key on-chain, enabling offline quantum key-recovery attacks with no time constraint (long-exposure, at-rest attack surface). - Host chain consensus risk: All host chains (Ethereum, Solana, etc.) use quantum-vulnerable consensus mechanisms; quantum compromise of validator sets on any host chain could affect BUIDL settlement finality. - No migration path exists: There is no public plan, mechanism, or timeline for migrating BUIDL to quantum-safe cryptography. The fund's multi-chain architecture and reliance on external infrastructure providers (Securitize, Fireblocks, Chronicle, Wormhole, BNY Mellon) mean any migration would require coordinated action across multiple independent organizations. ## Blockchain Capital (BCAP) - Project page: https://qrindex.org/projects/blockchain-capital/ - Complete report JSON: https://qrindex.org/projects/blockchain-capital/report.json - Official project website: https://www.blockchaincapital.com/ - Project type: tokenized asset - Evaluated network: ZKsync Era (primary); Ethereum (legacy contract) - Evaluated scope: Tokenized security (ERC-20) representing economic interest in Blockchain Capital III Digital Liquid Venture Fund, issued via Securitize. Token-specific admin/governance keys and custody arrangements evaluated alongside host-chain (ZKsync Era / Ethereum) cryptographic inheritance per QRI Section 7.2. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Token Inheritance, Roadmap Only, Admin-Key Dependent ### Summary BCAP is a tokenized security (ERC-20) representing fractional interest in Blockchain Capital III Digital Liquid Venture Fund, issued via Securitize and now operating on ZKsync Era. It has no independent cryptographic layers, consensus, P2P, or privacy mechanisms. Per QRI Section 7.2 (Token Inheritance), BCAP inherits the base-layer QRI posture of its host chain (ZKsync Era, Migration Stage 1 / QRI 28 per LayerQu v3.1.0). The token-specific quantum-critical risks are: (1) admin/issuer keys controlled by Securitize/Blockchain Capital with mint, freeze, and unfreeze powers — presumed ECDSA-secured with no PQC protection; (2) custody keys at Anchorage Digital Bank and Coinbase Custody — similarly vulnerable; and (3) complete dependence on ZKsync Era, which has no production PQC transaction protection and relies on pairing-based SNARK wrappers for L1 settlement. Neither Blockchain Capital nor Securitize has published a quantum risk assessment, cryptographic inventory, or migration plan for BCAP. The project scores 1/100 (Stage 1: Quantum Risk Assessed), reflecting zero production PQ protection across all applicable layers and negligible migration coverage (score of 1/20 from the <25% coverage tier for the small protected value-at-risk from hash-based components of the host chain's STARK core). ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published for the BCAP token by Blockchain Capital, Securitize, or any affiliated entity. - Token admin/issuer keys (freeze, unfreeze, mint) controlled by Securitize/Blockchain Capital are presumed ECDSA-secured with no evidence of PQC or hybrid-PQC protection. Compromise would enable unlimited token minting, global freeze, and fund seizure. - Institutional custody keys at Anchorage Digital Bank and Coinbase Custody are presumed ECDSA-secured with no production PQC deployment evidenced for BCAP. - Host chain ZKsync Era has no production PQC protection for user transaction signatures; its on-chain verification depends on pairing-based SNARK wrappers (BN254) vulnerable to Shor's algorithm. ### Principal risks - Admin key compromise: The tokenIssuer address (controlled by Securitize/Blockchain Capital) can mint unlimited tokens, freeze any holder, and unfreeze accounts. If secured by standard ECDSA keys, a quantum attacker could derive the private key from on-chain transaction signatures and gain full control over the token supply and transfer restrictions. - Custody key compromise: Anchorage Digital Bank and Coinbase Custody hold BCAP in custody for institutional holders. Both use ECDSA-based key management with no production PQC deployment evidenced. Compromise of custody keys could enable theft of custodied BCAP. - Host chain dependency: ZKsync Era's security depends on (a) ECDSA transaction signatures, (b) pairing-based SNARK wrappers (BN254) for on-chain proof verification, and (c) Ethereum L1 settlement. All three layers are quantum-vulnerable. A break in any layer could compromise BCAP token state integrity, transaction authorization, or bridge/withdrawal security. - Legacy Ethereum exposure: The original BCAP contract on Ethereum (0x1f41e42d0a9e3c0dd3ba15b527342783b43200a9) may still hold value or be interactable. Unmigrated tokens on Ethereum face the full quantum vulnerability of Ethereum's ECDSA account model. - No migration path: There is no public plan, mechanism, or timeline for migrating BCAP admin keys, custody keys, or token contracts to post-quantum cryptography. In a Q-day scenario, BCAP holders would depend entirely on Securitize, Anchorage, and Coinbase executing an unplanned emergency migration. - Concentration of control: BCAP's compliance-driven centralized admin powers (mint, freeze, unfreeze) mean a single quantum-compromised key could affect the entire token supply. This is a higher-impact attack surface than decentralized tokens where compromise affects only individual holders. ## BNB Chain (BNB) - Project page: https://qrindex.org/projects/bnb/ - Complete report JSON: https://qrindex.org/projects/bnb/report.json - Official project website: https://www.bnbchain.org/en - Project type: PoSA smart-contract platform - Evaluated network: BNB Smart Chain (BSC) mainnet - Evaluated scope: Native asset (BNB) on BSC mainnet; PoSA smart-contract platform including Parlia consensus, EVM execution, BEP-336 blob transactions, and validator infrastructure - QRI score: 22/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection, Prototype ### Summary BNB Chain (BSC) has published a thorough and technically credible post-quantum cryptography migration research report (May 2026), demonstrating a working prototype using ML-DSA-44 for transaction signatures and pqSTARK for consensus vote aggregation. The report provides detailed performance benchmarks, algorithm selection rationale, and compatibility analysis. However, as of the evaluation date (2026-06-01), no PQ protection is deployed on BSC mainnet. All production spend authorization remains ECDSA (secp256k1), all consensus authentication remains BLS12-381, P2P handshakes remain classical (ECDH), and KZG commitments for BEP-336 blob transactions have not been evaluated for PQ alternatives. The project is squarely at Stage 2 (Mitigation/Development): serious research and prototyping exists, but it does not materially protect production users. The Factor Score of approximately 24 reflects credit for substantive risk assessment (Category 1: 5/5), partial credit for prototype-level production-crypto work (Category 2: ~9.5/35), negligible migration coverage and mechanism readiness (Categories 3–4), and moderate algorithm-assurance credit for using NIST-standardized algorithms with performance analysis (Category 5: 7.5/20). The score is capped at 40 by the Readiness & Risk Cap (active production spend authorization remains entirely ECC/BLS-only) and the Stage 2 Cap, but the raw Factor Score of 24 is the binding minimum. ### Critical quantum blockers - Production spend authorization is entirely ECDSA (secp256k1) — all transaction signatures on BSC mainnet are quantum-vulnerable (Readiness & Risk Cap: 40) - Consensus vote aggregation is entirely BLS12-381 — validator authentication can be compromised by quantum attack (Readiness & Risk Cap: 40) - P2P transport and node identity remain classical (ECDH) — not yet evaluated for PQ alternatives per the migration report - KZG commitments used in BEP-336 blob transactions are quantum-vulnerable — not yet evaluated for PQ alternatives; could compromise L2 data availability and bridge verification - Material long-exposure quantum-vulnerable value exists: all BSC EOAs that have sent transactions have permanently exposed ECDSA public keys on-chain with no mainnet migration, freeze, or recovery path ### Principal risks - All BNB on BSC mainnet is secured by ECDSA (secp256k1) transaction signatures. A sufficiently capable quantum computer could forge signatures and steal funds from any address that has ever sent a transaction (public key exposed on-chain). - BSC's Parlia consensus relies on BLS12-381 signature aggregation for validator votes. A quantum attacker compromising validator keys could disrupt finality, propose malicious blocks, or prevent consensus. - KZG commitments (BEP-336, modeled on EIP-4844) are used for blob-carrying transactions that support opBNB and other L2 rollups. These commitments rely on BLS12-381 pairings and are quantum-vulnerable. Compromise could enable data-availability fraud against L2s. - P2P node identity and transport encryption use classical ECDH. A quantum attacker could impersonate nodes, eavesdrop on validator communication, or execute eclipse attacks at the networking layer. - The PQ prototype (ML-DSA-44 + pqSTARK) has not been independently audited. Implementation flaws in lattice-based signature verification or STARK proof verification could introduce new attack surfaces. - The performance penalty documented in the prototype (40-50% TPS reduction, ~18× block size growth) creates a significant deployment barrier. If unresolved, this could delay mainnet migration indefinitely, leaving the network quantum-vulnerable for an extended period. - Long-exposure vulnerability: all BSC EOAs that have sent transactions have permanently exposed ECDSA public keys on-chain. These can be attacked offline by a quantum adversary with no time constraint. ## Canton Network (CC) - Project page: https://qrindex.org/projects/canton/ - Complete report JSON: https://qrindex.org/projects/canton/report.json - Official project website: https://www.canton.network - Project type: privacy-enabled L1 blockchain - Evaluated network: Canton Mainnet (Global Synchronizer) - Evaluated scope: Native asset (CC), base-layer protocol cryptography, privacy layer, EVM integration, and institutional transaction authorization - QRI score: 12/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] — Active production spend authorization, consensus authentication, privacy encryption, and all wallet/custody paths remain entirely classical (Ed25519, ECDSA, RSA). ~$6B market cap (~$4T+ institutional RWAs) is quantum-vulnerable. The project has acknowledged risk and initiated mitigation design (Quanton proposal, BOLTS QFlex pilot, FC 2026 research paper), but no production PQ or hybrid protection exists. Institutional users should monitor mitigation progress and assess store-now-decrypt-later exposure for privacy-sensitive historical data. - Readiness tags: Roadmap Only, Partial Protection, Stage 2: Mitigation / Development ### Summary Canton Network has a public, detailed cryptographic inventory, a published risk assessment (DA forum, April 2025), and active mitigation design work in progress (Quanton proposal for native PQC verification, BOLTS QFlex pilot, FC 2026 research paper on key migration). However, zero production protection exists across all critical layers: spend authorization, consensus authentication, privacy encryption, P2P transport, node identity, and wallets remain entirely classical (Ed25519, ECDSA, RSA). All ~$6B market cap (~$4T+ institutional assets) is quantum-vulnerable with no migration path deployed. The project's privacy model advantageously avoids quantum-vulnerable ZK proof systems but encryption remains classically dependent and vulnerable to store-now-decrypt-later. The QRI Score of 12 (Stage 2: Mitigation / Development, capped at 40) reflects a project that has acknowledged risk and initiated design work but has not yet materially protected production users. ### Critical quantum blockers - Active production spend authorization, consensus-critical authentication (topology transactions, sequencer auth, mediator confirmations), node identity, P2P transport, wallet/custody signing, and privacy-layer encryption remain entirely classical (Ed25519, ECDSA over NIST P-256/P-384/secp256k1, RSA-2048, ECIES). No PQC or hybrid-PQC protection exists for any critical layer. A cryptographically relevant quantum computer could forge transaction authorizations, consensus votes, or decrypt historical privacy-protected transaction views. - No deployed migration path; all ~38.7B CC (~$6B market cap) and ~$4T+ institutional real-world assets on the network remain quantum-vulnerable with no freeze, deprecation, burn, recovery, or policy path for unmigratable value. ### Principal risks - Immediate quantum-critical risk: A cryptographically relevant quantum computer could forge transaction authorizations (spend, transfer, mint, burn), consensus votes (topology changes, validator set modifications, parameter updates), and mediator confirmations using the classical Ed25519/ECDSA keys currently protecting the network. This could enable theft of all on-chain assets and compromise of network governance. - Store-now-decrypt-later (SNDL): Canton's privacy model encrypts transaction views per recipient using ECIES (EC-P256) or RSA-2048. Historical encrypted transaction data collected now could be decrypted once a CRQC becomes available, exposing institutional trading strategies, collateral positions, settlement flows, and counterparty relationships. For a network processing $4T+ monthly in repos and $6T in RWAs, this represents catastrophic privacy exposure with no statute of limitations. - Unmigratable root namespace keys: Root namespace keys are classical (Ed25519 or ECDSA) and their fingerprint defines the namespace. Normal rotation changes the namespace, breaking all associated contracts, party identities, and topology state. The FC 2026 paper proposes a ZKP-based binding mechanism but this requires retained EdDSA seed material and does not cover ECDSA-only or seedless deployments. Major portions of the institutional participant base may be unable to migrate root keys without namespace disruption. - Concentration of development risk: Digital Asset is the sole developer of the Canton protocol client. A supply-chain compromise or development failure could delay or derail PQ migration. No independent client implementation exists. - The Quanton proposal is open and unreviewed (labeled 'Security/revision needed' as of May 2026). Even if approved and funded, delivery, integration, governance approval, and Super Validator adoption timelines are undefined. The proposal's stated priority is verification only; migration and signing infrastructure are explicitly deferred to a follow-up milestone. - BOLTS QFlex uses a bespoke protocol (SDFT) rather than NIST-standardized PQC. While NIST-grant-backed, it introduces third-party dependency and non-standard cryptographic assumptions. As a pilot, its production readiness, audit status, and integration depth are unverified. - No independent cryptographic audit of the core protocol's signing, encryption, or key-management implementation exists. The absence of formal review for the quantum-critical codebase increases residual risk even for the classical implementation, though this affects confidence rather than the QRI Score under v3.1 rules. - The transition from classical to PQ signatures, even when verification support is added, requires coordinated action across Super Validators, validators, participants, custodians, exchanges, and application developers. Canton's governance model (BFT Super Validator voting) can approve protocol changes but cannot compel participant-level key migration. Institutional migration timelines measured in years are plausible, and the network's SNDL exposure clock is already running. ## Cardano (ADA) - Project page: https://qrindex.org/projects/cardano/ - Complete report JSON: https://qrindex.org/projects/cardano/report.json - Official project website: https://cardano.org - Project type: PoS smart-contract platform - Evaluated network: mainnet - Evaluated scope: Cardano L1 native asset (ADA) and core protocol, including Ouroboros consensus, eUTXO transaction model, Mithril state proofs, and Plutus smart-contract platform - QRI score: 12/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-13 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection, eUTXO Structural Mitigation ### Summary Cardano scores 12/100 (Stage 2: Mitigation/Development), capped at 25 by the 'roadmap/proposal only; no public code, prototype, or testnet' Readiness & Risk Cap. The production network relies entirely on classical elliptic curve cryptography: Ed25519 for transaction signatures and KES, ECVRF (Ed25519-based) for Ouroboros leader election, and BLS12-381 for Mithril state proofs — all vulnerable to Shor's algorithm. No post-quantum code exists in any public repository, and no testnet, prototype, or mainnet PQ path is available. The eUTXO model provides a structural mitigation by hashing public keys in addresses until first spend, protecting never-spent UTXOs from long-exposure attacks, but spent and reused-address holdings remain fully exposed. Post-quantum work is active at the research and proposal level: CPS-0027 (merged May 2026) surveys PQ signature approaches for Plutus builtins, Vision 2026 WP1.2 targets TRL 1–4 with PQ VRF design work progressing, and Project Nightstream was announced (February 2026) as an IOG initiative for lattice-based PQ cryptography with research collaborators linked to Google and Microsoft. However, no formal CIP, governance proposal, code release, or public specification for Nightstream has been published. The project earns full credit for its public cryptographic inventory (IOG Cryptography Handbook), quantum threat assessment (CPS-0027, Vision 2026 WP1.2), and security governance infrastructure (Intersect Security Council, bug bounty program), but these do not constitute production protection. Cardano should be monitored for progress on CPS-0027 transitioning to a formal CIP, Vision 2026 H2 deliverables (prototypes and CIP-ready recommendations), and any Nightstream specifications or code releases. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519 (ECC) only — all transaction signatures are quantum-vulnerable to Shor's algorithm, enabling private key recovery and signature forgery. - Consensus-critical authentication (ECVRF for leader election, KES for block signing) is entirely Ed25519-based and quantum-vulnerable, enabling a quantum adversary to predict/bias slot leader schedules and forge alternative chains. - Mithril state proofs rely on BLS12-381 pairings for certificate aggregation, which are quantum-vulnerable; forged certificates could enable malicious state proofs for light clients and bridges. - No PQ or hybrid-PQ code exists in any public Cardano repository (cardano-base, cardano-crypto, cardano-node) as of the evaluation date. All PQ work is confined to research papers, CPS documents, roadmap proposals, and founder announcements. - No testnet, prototype, or mainnet PQ path exists; the most concrete deliverable (CPS-0027) is a problem statement surveying approaches, not an implementation or finalized CIP. ### Principal risks - All active transaction signatures are Ed25519-based and can be forged by a CRQC (cryptanalytically relevant quantum computer) using Shor's algorithm, enabling theft of any ADA in addresses with exposed public keys (spent UTXOs, reused addresses, stake pool keys, treasury keys). - Ouroboros consensus leader election (ECVRF) and block signing (KES) are quantum-vulnerable; a quantum adversary recovering VRF keys can predict/bias slot leader schedules, and recovering KES keys from historical operational certificates can forge alternative chains for bootstrapping nodes. - Mithril certificate aggregation uses BLS12-381 pairings, which are quantum-vulnerable; forged Mithril certificates could enable malicious state proofs for light clients and bridges. - Material long-exposure quantum-vulnerable value exists in all spent UTXOs and reused addresses where public keys are visible on-chain; this value cannot be protected retroactively without migration to PQ keys, and no freeze, deprecation, burn, or migration mechanism exists. - The gap between current research-stage work (TRL 1–4) and production deployment is unquantified and likely spans multiple years, while quantum computing advances may compress the available migration window. - The transition from CPS-0027 (Problem Statement) to a formal CIP to mainnet deployment involves governance, engineering, testing, and ecosystem coordination steps that have not yet begun. - Project Nightstream (lattice-based PQ cryptography) has been announced as an IOG initiative but has no formal CIP, governance proposal, code release, or public specification as of the evaluation date. - No formal quantum-specific incident-response playbook exists; while general security governance is in place, the unique challenges of a quantum attack (e.g., retroactive key recovery, simultaneous multi-target attacks) are not specifically addressed. ## Cellframe (CELL) - Project page: https://qrindex.org/projects/cellframe/ - Complete report JSON: https://qrindex.org/projects/cellframe/report.json - Official project website: https://cellframe.net - Project type: Quantum-safe L0 blockchain protocol - Evaluated network: Cellframe Backbone mainnet - Evaluated scope: Current Cellframe Backbone production protocol and native CF-20 CELL ownership, including consensus, state, P2P, wallet, custody, and external bridge or wrapped-asset dependencies only to the extent verifiable from the canonical dossier as of 2026-08-20. - QRI score: 70/100 - Readiness stage: 3 (Migration Live) - Evidence confidence: Medium - Evaluation date: 2026-08-20 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: PQ-Native (native CF-20), PQ-Resistant Transactions, Partial Protection, External Exposure Unverified ### Summary Cellframe has credible production evidence of post-quantum native transaction signing: public code, official tooling, and current mainnet records show Dilithium use, with Falcon also supported by wallet tooling. Native CF-20 ownership is materially stronger than a roadmap-only claim and no classical native ownership namespace is evidenced. The evaluated system is not treated as fully quantum-ready because consensus-critical authentication, complete state and supply bindings, and possible bridge or wrapped-token dependencies are not sufficiently verifiable from the supplied record. Monitoring is appropriate until these properties and any external value exposure are documented with canonical production evidence. ### Critical quantum blockers - The exact production cryptography for all validator authentication, block certification, randomness, and other consensus-critical operations is not independently verifiable from the supplied artifacts. - Quantum safety of every supply-binding, privileged state-update, and bridge-verification path is not established by a complete public cryptographic inventory. - The canonical record does not establish whether active ERC-20, BEP-20, wrapped CELL, or bridge paths currently expose material CELL value to classical ownership systems. ### Principal risks - A quantum-critical consensus path could remain if any validator, randomness, block-certificate, or privileged consensus key uses classical authentication not disclosed in the supplied documentation. - Undocumented commitment, supply-control, bridge-verification, governance, or privileged state-update keys could preserve a quantum-enabled forgery or ownership path. - If material CELL value is actively held through classical wrapped-token or bridge representations, it may inherit host-chain or bridge authorization risk; neither current operation nor exposure is established by the canonical record. - The incomplete cryptographic inventory makes it difficult to exclude classical fallbacks or undisclosed dependencies outside the well-evidenced native transaction path. ## Chainlink (LINK) - Project page: https://qrindex.org/projects/chainlink/ - Complete report JSON: https://qrindex.org/projects/chainlink/report.json - Official project website: https://chain.link - Project type: decentralized oracle network - Evaluated network: multi-chain (Ethereum and bridged chains) - Evaluated scope: Chainlink decentralized oracle network, including OCR, CCIP, VRF, Data Feeds, node infrastructure, and LINK token (ERC-677/ERC-20 on Ethereum and bridged chains) - QRI score: 4/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ECC-Only Production, L1-Inherited Risk ### Summary Chainlink scores 4/100 (Stage 1: Quantum Risk Assessed). The project has published an educational article acknowledging quantum threats to blockchain cryptography (February 2026), but has no formal cryptographic inventory, no PQC migration roadmap, no PQC design or prototype, and zero production PQC protection across any component. Every critical cryptographic layer — OCR oracle report signing (EdDSA/ECDSA), CCIP cross-chain messaging (classical signatures), VRF randomness (ECC), node P2P identity (secp256k1/Ed25519), and LINK token transfers (inherited Ethereum ECDSA) — remains entirely dependent on quantum-vulnerable classical cryptography. Chainlink secures over $90 billion in DeFi value and dominates ~68% of the oracle market, making its quantum vulnerability a systemic risk for the entire DeFi ecosystem. The project has strong operational security (SOC 2 Type 2, bug bounty, multiple audits) but none of these address quantum readiness. This evaluation covers the Chainlink oracle network, CCIP, VRF, Data Feeds, node infrastructure, and LINK token as of 2026-06-01. ### Critical quantum blockers - OCR oracle report signing uses exclusively classical ECDSA/EdDSA signatures. A quantum attacker could forge oracle reports, manipulate price feeds, and trigger cascading DeFi liquidations across all dependent protocols. - CCIP cross-chain messaging and Risk Management Network rely entirely on classical signatures. A quantum attacker could forge cross-chain messages, mint unbacked bridged assets, or bypass security controls across all CCIP-connected chains. - VRF randomness generation uses classical elliptic curve cryptography. A quantum attacker could predict or manipulate VRF outputs, compromising gaming, lotteries, and fair-distribution mechanisms. - LINK token (ERC-677/ERC-20) inherits the ECDSA vulnerability of its host chain (Ethereum). All LINK token transfers are quantum-vulnerable. - Node P2P identity and key management use classical cryptography (secp256k1, Ed25519) with no PQC alternatives available in the core node software. - No PQC migration roadmap, design document, prototype, testnet, or production code exists for any Chainlink component as of the evaluation date. ### Principal risks - SYSTEMIC DEFI RISK: Chainlink secures ~68% of oracle-dependent value in DeFi. A quantum break of OCR signatures would allow attackers to inject arbitrary price data, triggering cascading liquidations, arbitrage exploits, and protocol insolvencies across hundreds of dependent applications representing tens of billions in TVL. - CCIP BRIDGE RISK: CCIP has processed $18B+ in cross-chain value (Q1 2026). Quantum signature forgery on CCIP would allow unbacked token minting, theft of bridged assets, and compromise of cross-chain messaging integrity across all supported chains. - VRF MANIPULATION: Quantum prediction or forgery of VRF outputs would compromise all dependent gaming, lottery, NFT mint, and fair-distribution applications. - HARVEST-NOW-DECRYPT-LATER: Oracle node public keys and on-chain signature data are permanently recorded. Adversaries can harvest this data today for future quantum decryption, making the threat time-sensitive even though cryptographically relevant quantum computers do not yet exist. - NO MIGRATION PATH: There is no public PQC migration roadmap, design, testnet, or implementation for any Chainlink component. Given Chainlink's multi-party coordination requirements (hundreds of node operators, multiple DONs, cross-chain deployment), migration will require years of planning and execution that has not yet begun. - LINK TOKEN: As an ERC-677/ERC-20 token, LINK inherits the full quantum vulnerability of Ethereum's ECDSA-based account model. LINK holders with exposed public keys (any address that has sent a transaction) are vulnerable to quantum key-recovery attacks. - DEPENDENCY CHAIN: Chainlink's quantum readiness depends on quantum readiness of all host chains (Ethereum, Arbitrum, Polygon, etc.) for on-chain signature verification. Even if Chainlink nodes adopted PQC signatures, on-chain verification would require host-chain support for PQC signature verification precompiles or opcodes, which do not exist in production on most chains as of the evaluation date. ## Circle USYC (USYC) - Project page: https://qrindex.org/projects/hashnote-usyc/ - Complete report JSON: https://qrindex.org/projects/hashnote-usyc/report.json - Official project website: https://www.coingecko.com/en/coins/hashnote-usyc - Project type: cryptoasset - Evaluated network: mainnet - Evaluated scope: native asset and base protocol - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessable ### Summary Generated QRI report. ### Critical quantum blockers - No critical quantum blocker analysis returned. ### Principal risks - No risk summary returned. ## Cosmos Hub (ATOM) - Project page: https://qrindex.org/projects/cosmos/ - Complete report JSON: https://qrindex.org/projects/cosmos/report.json - Official project website: https://www.coingecko.com/en/coins/cosmos - Project type: blockchain network - Evaluated network: Cosmos Hub mainnet - Evaluated scope: Native asset (ATOM), consensus layer, IBC bridge verification, account/transaction layer, P2P networking - QRI score: 12.78/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Partial Protection, ECC-Only Production, Quantum-Vulnerable Consensus, Quantum-Vulnerable Spend Authorization ### Summary Cosmos Hub (ATOM) relies entirely on classical elliptic curve cryptography in production: secp256k1 for user account transaction signatures and Ed25519 for validator consensus authentication. No PQC or hybrid-PQC protection exists on mainnet as of June 2026. The IAVL state tree uses SHA-256 hashing which provides adequate quantum resistance for state commitments, but all ownership authorization and consensus authentication paths remain quantum-vulnerable. Third-party hackathon work (DoraFactory/pqc-cosmos) demonstrates a Dilithium prototype integrated into Tendermint, and community forum discussions outline a potential gradual migration path, but no official governance proposal, foundation roadmap, or production PQC deployment exists. IBC light client verification also depends on Ed25519 validator signatures, extending quantum vulnerability to cross-chain settlement. The project qualifies for Stage 2 due to ecosystem-level prototype and research work, but production users receive no quantum protection. ### Critical quantum blockers - Active production spend authorization remains entirely secp256k1 (ECC-only) with no PQC or hybrid path available on mainnet - Consensus authentication (validator votes, precommits) remains entirely Ed25519 (ECC-only) with no PQC alternative in production CometBFT - IBC light client verification relies on Ed25519 validator signatures, creating quantum-vulnerable cross-chain settlement paths - No migration mechanism, hybrid account support, or PQC key type exists in production Cosmos SDK for Cosmos Hub - P2P node identity and transport key-exchange rely on Ed25519 and X25519 respectively, both quantum-vulnerable ### Principal risks - Any Cosmos Hub account that has ever broadcast a transaction has exposed its secp256k1 public key on-chain, enabling offline quantum key-recovery attacks with no time constraint (long-exposure surface). - Validator Ed25519 keys are long-lived and publicly known; quantum forgery of validator signatures could compromise consensus finality and enable cross-chain double-spending via IBC. - IBC light-client verification relies entirely on Ed25519 validator signatures; a quantum-capable adversary could forge light-client updates and steal bridged assets. - No migration, freeze, deprecation, or emergency recovery mechanism exists for quantum-vulnerable accounts, treasuries, validator keys, or IBC client states. - Cosmos Hub's multi-chain architecture and IBC interoperability amplify the blast radius of a consensus compromise; a single quantum-forged validator set could affect all IBC-connected chains. - P2P transport encryption (X25519 key exchange) is quantum-vulnerable, potentially enabling retrospective decryption of historical P2P traffic if session transcripts are stored. - The project has no governance-approved PQC migration timeline, budget, or activation criteria; migration coordination across 100+ sovereign Cosmos SDK chains and IBC clients would be complex and slow. ## Cronos (CRO) - Project page: https://qrindex.org/projects/crypto-com-chain/ - Complete report JSON: https://qrindex.org/projects/crypto-com-chain/report.json - Official project website: https://www.coingecko.com/en/coins/crypto-com-chain - Project type: AI network token - Evaluated network: Cronos EVM Mainnet - Evaluated scope: Cronos EVM L1 chain (Cosmos SDK + Ethermint + CometBFT); native asset CRO on the EVM chain. Cronos zkEVM L2 and Cronos POS chain are separate networks not evaluated in this scope. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Quantum-Vulnerable, Classical-Only, No-PQ-Roadmap, ECC-Dependent, Long-Exposure-At-Risk ### Summary Cronos (CRO) is a Cosmos SDK + Ethermint EVM-compatible L1 blockchain with CometBFT consensus. As of 2026-06-02, the project exhibits zero quantum readiness across all five QRI categories. No public cryptographic inventory, quantum risk assessment, PQC roadmap, testnet, prototype, or deployed mitigation exists. All production cryptography is classical and fully quantum-vulnerable: secp256k1 ECDSA for EVM spend authorization and Ed25519 for CometBFT validator consensus signatures. The EVM account model permanently exposes public keys after the first transaction, creating a large and growing long-exposure (at-rest) attack surface for quantum key-recovery attacks. The 2025-2026 Cronos roadmap prioritizes AI agents, tokenization, and scalability with no mention of quantum security. Independent assessment by LayerQu confirms Migration Stage 0 (Unaware-of-deployment-path). The QRI Score of 1/100 reflects near-total absence of quantum-attack readiness, capped by the absence of even a basic public cryptographic inventory. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published by Cronos Labs or any Cronos-affiliated entity. - All production spend authorization uses secp256k1 ECDSA (EVM compatibility via Ethermint) — fully quantum-vulnerable to Shor's algorithm. - All consensus validator authentication uses Ed25519 via CometBFT — fully quantum-vulnerable. - EVM account model permanently exposes public keys after first transaction, creating a large and growing long-exposure attack surface. - No PQC migration roadmap, proposal, testnet, prototype, or public acknowledgment of quantum risk exists anywhere in the Cronos ecosystem. ### Principal risks - All CRO held in EVM accounts that have sent at least one transaction has permanently exposed secp256k1 public keys, creating a harvest-now-decrypt-later target for future CRQCs. - Validator Ed25519 consensus keys are long-exposed on-chain; compromise would allow an attacker to forge consensus votes, potentially enabling double-sign attacks, finality disruption, or validator impersonation. - Cronos inherits the full quantum-vulnerability surface of both the Cosmos SDK ecosystem (no PQC support in Cosmos SDK or CometBFT as of mid-2026) and the EVM account model (permanent key exposure), compounding migration complexity. - The IBC bridge between Cronos EVM and Cronos POS (and other Cosmos chains) relies on the same classical validator-key security model; a quantum compromise of validator keys could affect cross-chain asset security. - Cronos zkEVM (L2) may introduce additional quantum-vulnerable pairing-based commitments (ZK Stack/ZKsync heritage), expanding the ecosystem attack surface beyond the L1 scope evaluated here. - With no public quantum acknowledgment from Cronos Labs, the community and institutional users have no visibility into whether any internal preparation is underway, increasing uncertainty for long-horizon asset custody decisions. ## Dai (DAI) - Project page: https://qrindex.org/projects/dai/ - Complete report JSON: https://qrindex.org/projects/dai/report.json - Official project website: https://www.coingecko.com/en/coins/dai - Project type: stablecoin - Evaluated network: Ethereum - Evaluated scope: ERC-20 stablecoin token on Ethereum mainnet; inherits L1 Score [Ethereum] with token-specific admin/governance key evaluation - QRI score: 25/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Inherits L1 Score [Ethereum], Partial Protection, Quantum-Vulnerable Admin Keys ### Summary Dai (DAI) is a standard ERC-20 stablecoin on Ethereum that inherits its host chain's quantum-readiness posture (Ethereum QRI: 25/100, Migration Stage 2 per LayerQu). The token itself has no independent cryptographic layer; all transfers and ownership rely on Ethereum's ECDSA secp256k1 signatures. MakerDAO/Sky governance controls (minting parameters, collateral ratios, stability fees) are administered via classical ECDSA multisig wallets, creating an additional quantum-vulnerable surface. No public cryptographic inventory, quantum threat assessment, or migration roadmap has been published by MakerDAO/Sky. DAI's quantum readiness is therefore entirely gated by Ethereum's future base-layer migration and MakerDAO's eventual governance coordination. ### Critical quantum blockers - MakerDAO/Sky governance and admin keys rely entirely on quantum-vulnerable ECDSA signatures on Ethereum; an attacker who compromises these keys could manipulate collateral ratios, mint unbacked DAI/USDS, adjust stability fees, trigger liquidations, or drain protocol reserves. - No token-specific or L1-inherited post-quantum migration path is currently live, planned, or formally assessed by the MakerDAO/Sky protocol team. ### Principal risks - DAI inherits Ethereum's quantum-vulnerable ECDSA secp256k1 signature scheme for all token transfers and ownership. - MakerDAO/Sky governance and administrative multisig wallets rely on classical ECDSA signatures, exposing DAI's monetary policy, collateral parameters, and emergency controls to quantum key-recovery attacks. - No public cryptographic inventory, quantum threat model, or migration roadmap exists for the Maker Protocol or DAI token. - A quantum attack on Ethereum EOAs would compromise the collateral backing DAI, leading to potential de-pegging, forced liquidations, and systemic failure. - Governance multisig signer public keys are permanently exposed on-chain through historical transactions, creating a long-exposure (at-rest) attack surface with no time constraint for a quantum adversary. ## DeXe (DEXE) - Project page: https://qrindex.org/projects/dexe/ - Complete report JSON: https://qrindex.org/projects/dexe/report.json - Official project website: https://www.coingecko.com/en/coins/dexe - Project type: DeFi protocol token - Evaluated network: Ethereum / BNB Chain - Evaluated scope: DEXE ERC-20/BEP-20 governance token and DeXe Protocol DAO smart contracts; inherits host-chain (Ethereum/BNB Chain) cryptographic risk per QRI Section 7.2. Token-specific evaluation covers admin/governance keys, Snapshot/SafeSnap governance signatures, and protocol upgrade paths. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Inherits L1 Score [Ethereum/BNB Chain], No Quantum Preparedness, Token Inheritance, ECDSA-Only Governance ### Summary DeXe (DEXE) is a standard ERC-20/BEP-20 governance token for the DeXe Protocol DAO deployed on Ethereum and BNB Chain. Under QRI v3.1 Section 7.2 (Token Inheritance), DEXE inherently shares the base-layer quantum risk of its host chains. As of 2026-06-02, neither Ethereum nor BNB Chain has production post-quantum protection — all transactions use ECDSA and Ethereum consensus uses BLS signatures. Ethereum has active PQ research (dedicated EF Post-Quantum team formed January 2026, leanXMSS, leanVM, weekly interop devnets, structured fork milestones targeting ~2029) but this is development-stage work with no production protection. The DeXe project itself has published no cryptographic inventory, no quantum risk assessment, no mitigation roadmap, and no migration mechanism. The DeXe DAO governance relies on Snapshot (off-chain ECDSA signatures) and SafeSnap (on-chain execution), creating an additional quantum-vulnerable surface that controls a ~$1.7-2.8B+ treasury. 100% of DEXE value-at-risk is quantum-vulnerable. The QRI Score of 1 reflects the complete absence of quantum preparedness by the DeXe project, with the score derived from the minimum migration coverage threshold (1 out of 20 points for <25% protected value). ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published by DeXe project - All token spend authorization relies on ECDSA via host chains (Ethereum/BNB Chain) — neither has production PQC protection - DeXe DAO governance (Snapshot + SafeSnap) uses ECDSA signatures exclusively; a quantum attacker could forge governance votes and potentially compromise the ~$1.7-2.8B+ treasury - No quantum migration roadmap, mechanism, or mitigation design exists for the DEXE token or DeXe Protocol DAO - All value-at-risk (100% of token supply and treasury) is quantum-vulnerable with no migration path ### Principal risks - Host-chain dependency: DEXE token security depends entirely on Ethereum and BNB Chain base-layer cryptography (ECDSA). Neither chain has production PQC protection. Ethereum targets ~2029 for core PQ infrastructure, but this is a planning target, not a guarantee. - Governance compromise: An attacker with a cryptographically relevant quantum computer could recover ECDSA private keys of DEXE governance participants, forge Snapshot votes, and potentially execute malicious proposals through SafeSnap to drain the ~$1.7-2.8B+ DeXe DAO Treasury. - Long-exposure keys: All Ethereum accounts that have sent DEXE transactions have exposed their public keys on-chain. These keys are vulnerable to 'harvest now, decrypt later' attacks. - Validator and Council keys: The DeXe DAO's Validators and Council members hold governance authority. Compromise of these keys via quantum attack could allow unauthorized proposal approval and treasury fund extraction. - No recovery mechanism: There is no emergency pause, freeze, or migration mechanism designed to protect the DeXe DAO Treasury or DEXE token holders in the event of a quantum breakthrough. - Dormant and unmigratable assets: The DeXe Protocol has no policy for handling quantum-vulnerable dormant holdings, lost keys, or abandoned governance positions. ## Dogecoin (DOGE) - Project page: https://qrindex.org/projects/dogecoin/ - Complete report JSON: https://qrindex.org/projects/dogecoin/report.json - Official project website: https://dogecoin.com - Project type: PoW chain - Evaluated network: Dogecoin Mainnet - Evaluated scope: Native asset (DOGE) on Dogecoin PoW mainnet; production spend authorization, UTXO state, and native asset ownership. - QRI score: 17/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection, PQ-Recoverable ### Summary Dogecoin is a classical PoW UTXO chain whose production spend authorization remains entirely ECDSA/secp256k1-only. The Dogecoin Foundation and core developers have made tangible R&D progress: libdogecoin PR #288 (merged April 2026) integrates liboqs-based PQC support (Falcon, Dilithium/ML-DSA), and an experimental OP_RETURN-based post-quantum commitment transaction was executed on mainnet in April 2026. However, these are prototype/experimental artifacts that provide zero material protection to production users. The UTXO model offers inherent hash-based at-rest protection for P2PKH addresses that have never been spent or reused, but ~82.5M P2PK public keys are structurally exposed on-chain, and address reuse creates additional operational exposure. No formal cryptographic inventory, quantum threat model, migration mechanism, enforcement path, or independent PQC audit exists. The RE-EN proposal uses un-reviewed bespoke cryptography and should not be weighted as a credible PQC design. Dogecoin is in Stage 2 (Mitigation / Development) with a QRI Score of 17, capped at 40 by the ECC-only spend authorization blocker. ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA/secp256k1-only; no PQC or hybrid-PQC signature path is available to any production user (caps QRI at 40). - Material long-exposure quantum-vulnerable value exists: ~82.5M P2PK extracted unique public keys on-chain (structurally exposed), plus operational exposure from address reuse and spent-output key revelation; no migration, freeze, deprecation, burn, or policy path exists (caps QRI at 55, subsumed by the 40 cap). - No formal public cryptographic inventory or quantum threat model has been published by the Dogecoin project. ### Principal risks - All DOGE spend authorization depends on ECDSA/secp256k1; a CRQC running Shor's algorithm could derive private keys from any revealed public key. - P2PK outputs (~82.5M extracted unique public keys, including early coinbase outputs) are structurally exposed at rest and many may be lost/abandoned, making them permanently vulnerable with no migration path. - Address reuse across the network creates operational exposure: once a P2PKH public key is revealed in a spend, all remaining UTXOs at that address become at-rest vulnerable. - The RE-EN proposal's cryptographic claims ('infinite compression', non-standard techniques) are un-reviewed and could create a false sense of progress; the credible PQC path runs through libdogecoin/liboqs, which is not yet in Dogecoin Core. - No governance process, activation mechanism, or community consensus exists for a PQC soft fork; timeline is aspirational (2027-2030) with no binding milestones. - Dogecoin's 1-minute block time makes on-spend attacks extremely difficult (<0.0125% success probability per Google's March 2026 analysis), but at-rest attacks on exposed keys face no such timing constraint. ## Ethena (ENA) - Project page: https://qrindex.org/projects/ethena/ - Complete report JSON: https://qrindex.org/projects/ethena/report.json - Official project website: https://www.coingecko.com/en/coins/ethena - Project type: DeFi protocol token - Evaluated network: Ethereum - Evaluated scope: ENA governance token (ERC-20) on Ethereum mainnet and bridged/wrapped representations on 23+ chains. Evaluation covers token-specific quantum readiness; base-layer risk inherits from Ethereum L1 per QRI token inheritance rules (Section 7.2). Token-specific admin/governance keys evaluated independently. - QRI score: 6.83/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: ECDSA-only, Token (inherits L1), Admin Key Exposure, No PQC Roadmap, Long-Exposure Public Keys, Multi-Chain (23+ chains), Governance Token ### Summary Ethena (ENA) is a standard ERC-20 governance token on Ethereum with no post-quantum cryptographic protection. All transaction signing, admin multisigs, OES custody, and governance paths rely exclusively on ECDSA secp256k1. Multiple 2026 third-party research assessments (Google Quantum AI, EternaX, BMIC) have identified Ethena's admin keys as quantum-vulnerable, with ~$3B+ in USDe stablecoin value governed by exposed ECDSA keypairs. Ethena Labs has published no cryptographic inventory, no quantum threat model, no PQC migration roadmap, and no evidence of any quantum-readiness work. The ENA token inherits Ethereum L1 quantum vulnerabilities and adds independent token-specific risk through quantum-vulnerable governance multisigs. Classical smart-contract audits exist but are stale (2023-2024) and quantum-scope-mismatched. QRI Score of 7 reflects that quantum risk has been assessed by credible third parties but no mitigation design, prototype, or production protection exists. The project is classified at Stage 1: Quantum Risk Assessed. ### Critical quantum blockers - All spend authorization and transaction signing is ECDSA secp256k1-only with no hybrid-PQC or PQC path. Every ENA wallet that has broadcast a transaction has a permanently exposed public key vulnerable to Shor's algorithm. - Protocol admin multisigs (Gnosis Safe 5/11 and 7/10) use standard Ethereum ECDSA accounts. Compromise of these keys would allow arbitrary control over USDe minting, contract upgrades, custody routing, and governance. - OES (Off-Exchange Settlement) custody relies on third-party MPC/multisig providers whose key material is presumed ECDSA/EdDSA-based with no verified quantum-resistant controls. - No public cryptographic inventory, no quantum threat model, no PQC migration roadmap, and no evidence of any quantum-readiness work has been published by Ethena Labs. ### Principal risks - Quantum-enabled admin key compromise: A CRQC could derive private keys from exposed ECDSA public keys of Ethena's Gnosis Safe multisig signers (5/11 dev multisig at 0x3b0aaf6e6fcd4a7ceef8c92c32dfea9e64dc1862 and 7/10 protocol multisig), enabling arbitrary USDe minting, contract upgrades, custody rerouting, and protocol takeover. The Google Quantum AI March 2026 paper explicitly identifies this attack path for Ethena USDe. - User wallet key extraction: Every ENA holder who has broadcast a transaction has a permanently exposed secp256k1 public key on-chain. A future CRQC could derive the corresponding private key, enabling theft of all ENA and any assets controlled by that Ethereum account. - OES custody compromise: Ethena's delta-neutral hedging model depends on Off-Exchange Settlement providers (Copper, Fireblocks, etc.) whose MPC/multisig key material is assumed to be ECDSA/EdDSA-based. Quantum compromise of custody keys could drain protocol collateral backing USDe. - MINTER_ROLE / REDEEMER_ROLE hot wallet compromise: These EOA addresses sign EIP-712 orders for minting and redemption. Although per-block limits ($100k) and GATEKEEPER_ROLE pauses provide classical mitigation, a quantum attacker could forge signatures from exposed public keys and bypass these controls if gatekeeper keys are also compromised. - Cross-chain bridge risk: ENA exists on 23+ chains via bridges and wrapped representations. Each bridge's signer set and each destination chain's security model add independent quantum-vulnerable attack surfaces. - No migration path exists: Ethena has no published plan, mechanism, or timeline for migrating admin multisigs, user wallets, OES custody, or governance to post-quantum cryptography. The protocol is entirely dependent on Ethereum L1's eventual PQC migration (targeting ~2029), which would not automatically upgrade Ethena's token-specific admin keys or off-chain custody. - Harvest-now-decrypt-later exposure: All exposed ECDSA public keys from historical ENA and USDe transactions are permanently recorded on-chain and can be harvested today for future quantum decryption. This includes admin multisig signers whose keys have transacted on-chain. ## Ethena USDe (USDE) - Project page: https://qrindex.org/projects/ethena-usde/ - Complete report JSON: https://qrindex.org/projects/ethena-usde/report.json - Official project website: https://www.coingecko.com/en/coins/ethena-usde - Project type: stablecoin - Evaluated network: Ethereum - Evaluated scope: ERC-20 Token, Admin Multisigs, Off-chain Custody - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Token: Inherits L1 Score [Ethereum] ### Summary Ethena USDe is a standard ERC-20 stablecoin on Ethereum with no independent post-quantum cryptographic layer. All quantum-relevant properties inherit from Ethereum L1 for basic token transfers (per QRI Section 7.2 Token Inheritance), but token-specific admin and governance controls — including a 5/11 Gnosis Safe Dev Multisig with 608 on-chain transactions (public key permanently exposed), MINTER/REDEEMER/GATEKEEPER EOAs, Reserve Fund and Payout Fund multisigs, and off-chain institutional custodian MPC arrangements — are entirely ECDSA-dependent with no PQC, hybrid-PQC, or migration path. Ethena Labs has published no cryptographic inventory, no quantum threat model, no migration roadmap, and no quantum-specific audit. Third-party reports (StablePQC, EternaX) independently identify Ethena USDe admin keys as exposed and quantum-vulnerable. Approximately $3.96B in circulating supply is protected by quantum-vulnerable admin keys whose compromise would enable unlimited unbacked minting and peg collapse. The QRI Score is 1, capped by the absence of any public cryptographic inventory (Readiness & Risk Cap: 10) and a Factor Score of 1 across all five categories. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model has been published by Ethena Labs (Readiness & Risk Cap: 10). - All production spend authorization and admin-key controls rely exclusively on ECDSA secp256k1 (Ethereum EOAs and Gnosis Safe multisigs); no PQC or hybrid-PQC path exists (Readiness & Risk Cap: 40). - Admin multisig public keys are permanently exposed on-chain (608+ transactions for Dev Multisig), creating a long-exposure quantum vulnerability with no migration, freeze, or deprecation path (Readiness & Risk Cap: 55). - A quantum adversary who compromises the admin multisig could mint unlimited USDe, drain collateral, freeze/redistribute staked funds, and collapse the ~$3.96B peg, making this a plausible quantum-enabled path to theft and inflation (Readiness & Risk Cap: 60). - Off-chain institutional custodians (Copper, Ceffu, Kraken, Anchorage) securing the backing assets rely on classical MPC/multisig setups; compromise of custodian keys would destroy the collateral backing and collapse USDe (Readiness & Risk Cap: 70). ### Principal risks - QUANTUM-CRITICAL: The 5/11 Dev Multisig (0x3B0AAf6e6fCd4a7cEEf8c92C32DFeA9E64dC1862) is the owner of all Ethena mainnet smart contracts. It has executed 608 on-chain transactions, permanently exposing its ECDSA public key. A quantum adversary who recovers the corresponding private key gains unlimited minting authority, can change all contract parameters, and can drain or freeze protocol assets. - QUANTUM-CRITICAL: The Reserve Fund multisig (4/10, 0x2b5ab59163a6e93b4486f6055d33ca4a115dd4d5) and sUSDe Payout Fund multisig (3/11, 0x71e4f98e8f20c88112489de3dded4489802a3a87) are additional ECDSA-based long-exposure surfaces controlling $62.5M+ in protocol reserves and yield distribution. - QUANTUM-CRITICAL: MINTER and REDEEMER roles are EOA addresses on Ethereum. While these are hot wallets with per-block limits ($100K mint, ~$200K redeem), the GATEKEEPER role (also EOAs) and DEFAULT_ADMIN_ROLE (multisig) that can re-enable or escalate privileges are also quantum-vulnerable. - QUANTUM-CRITICAL: Off-chain backing assets (~$3.96B equivalent) are held by institutional custodians (Copper, Ceffu, Kraken, Anchorage) using classical MPC/multisig setups. Quantum compromise of custodian keys would result in theft of the entire collateral backing, instantly breaking the USDe peg. - QUANTUM-CRITICAL: The EthenaMinting contract uses EIP-712 signatures (ECDSA) for mint/redeem order verification. Users who have submitted signed orders have exposed their public keys. Forgery of these signatures by a quantum adversary could enable unauthorized minting or redemption. - STRUCTURAL: USDe is deployed on 20+ chains via bridge/wrapper contracts, each with its own multisig governance. These create additional quantum-vulnerable surfaces not exhaustively evaluated in this report. - STRUCTURAL: Even if Ethereum L1 completes its PQC migration (~2029 target), Ethena's already-deployed multisigs, admin EOAs, and custodian arrangements would remain on quantum-vulnerable keys until independently migrated. There is no evidence Ethena has begun planning for this. ## Ethereum (ETH) - Project page: https://qrindex.org/projects/ethereum/ - Complete report JSON: https://qrindex.org/projects/ethereum/report.json - Official project website: https://ethereum.org - Project type: PoS smart-contract platform - Evaluated network: mainnet - Evaluated scope: Ethereum L1 - QRI score: 16.75/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-19 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only ### Summary Ethereum has a comprehensive public cryptographic inventory and a detailed post-quantum roadmap, but no production quantum-safe protection. Spend authorization (ECDSA), consensus (BLS), and data availability commitments (KZG) remain entirely quantum-vulnerable. Migration has not started; no value is protected. The project is in active research and devnet phase (Stage 2, Mitigation/Development). ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA-only. - Material long-exposure quantum-vulnerable value (transacted EOAs) exists with no migration, freeze, or recovery path. - Users can create new quantum-vulnerable high-value accounts (EOAs) by default. - Consensus authentication (BLS) is quantum-vulnerable. - KZG commitments used for data availability are quantum-vulnerable. ### Principal risks - All existing EOAs with exposed public keys are vulnerable to offline quantum attacks that could steal funds. - New accounts are created vulnerable by default, so any new value is at risk. - Validator consensus keys are vulnerable, potentially allowing fork attacks or finality compromise. - KZG commitments could be broken, compromising data availability and potentially allowing invalid state transitions. - No migration path exists for long-exposure dormant balances, and no policy to freeze or deprecate them. - The P2P layer may be vulnerable, though its direct impact on asset security is lower. ## Ethereum Classic (ETC) - Project page: https://qrindex.org/projects/ethereum-classic/ - Complete report JSON: https://qrindex.org/projects/ethereum-classic/report.json - Official project website: https://www.coingecko.com/en/coins/ethereum-classic - Project type: cryptoasset - Evaluated network: mainnet - Evaluated scope: Native asset (ETC) on Ethereum Classic mainnet (Chain ID 61), PoW EVM layer-1, as of 2026-06-02 - QRI score: 15.75/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Only, PoW ### Summary Ethereum Classic (ETC) is a proof-of-work EVM layer-1 blockchain whose base-layer spend authorization relies entirely on ECDSA over secp256k1, which is vulnerable to Shor's algorithm. All Externally Owned Accounts (EOAs) that have ever sent a transaction have their public keys permanently exposed on-chain, creating a large pool of long-exposure quantum-vulnerable value (~$1.25B circulating market cap). A draft proposal (ECIP-1122, January 2026) and prototype Core-Geth PR exist for an ML-DSA signature-verification precompile, but this would only enable smart-contract-level PQ verification—it cannot migrate base-layer EOAs or protect the native ETC asset from quantum key-recovery attacks. A core contributor publicly stated the project is in a 'funding crisis with its deprecated client in maintenance mode.' No production PQ or hybrid protection exists. The strict immutability ethos ('Code is Law') creates a further governance obstacle to any state intervention that might be needed to handle dormant or lost accounts with exposed public keys. The QRI Score of 16 reflects the presence of a draft mitigation proposal (Stage 2) combined with near-total absence of production protection, migration coverage, or quantum preparedness. Structural advantages include quantum-safe Keccak-based state integrity and PoW consensus without validator signatures. ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA/secp256k1-only with no PQ or hybrid path on mainnet. - Material long-exposure quantum-vulnerable value exists (~$1.25B circulating market cap) with no migration, freeze, deprecation, burn, recovery, or policy path for transacted EOAs with publicly exposed keys, reused addresses, or dormant holdings. - ECIP-1122 addresses only smart-contract-level ML-DSA verification via precompile; it does not migrate or protect base-layer Externally Owned Accounts (EOAs) or the native asset. - The 'Code is Law' immutability ethos creates a governance obstacle: any state intervention to freeze or migrate vulnerable dormant accounts would face strong ideological opposition, making coordinated migration exceptionally difficult. ### Principal risks - All ETC held in externally owned accounts (EOAs) that have ever sent a transaction is subject to offline at-rest quantum key-recovery: public keys are permanently visible on-chain with no rotation mechanism. This includes exchange hot wallets, treasury accounts, DeFi protocol contracts controlled by EOA admin keys, and all historically active addresses. - Dormant and lost accounts with exposed public keys cannot migrate, and the 'Code is Law' ethos makes a network-wide freeze or forced migration politically extremely difficult. This creates a permanent, unpatchable quantum-vulnerable value pool. - The ECIP-1122 proposal addresses only smart-contract-level PQ signature verification (a precompile), not base-layer account migration. Even if deployed, it offers zero protection to existing ETC holders using standard EOAs. - A core contributor publicly stated (Feb 2026) that the project lacks funding and bandwidth to pursue quantum migration, with a deprecated client in maintenance mode. This suggests the current governance and funding structure cannot support a serious migration effort. - ETC's available BN256 and BLS12-381 precompiles are pairing-based and quantum-vulnerable. Applications using these for bridge verification, state-binding, or custody logic inherit quantum vulnerability. - Harvest-now-decrypt-later (HNDL) risk: ETC has been operational since 2015 (11 years), producing an extensive on-chain history of permanently exposed public keys and transaction data that adversaries can collect today for future quantum decryption. - No formal quantum threat model, cryptographic inventory, or migration roadmap has been published by the ETC project. ## EURC (EURC) - Project page: https://qrindex.org/projects/euro-coin/ - Complete report JSON: https://qrindex.org/projects/euro-coin/report.json - Official project website: https://www.circle.com - Project type: stablecoin - Evaluated network: Multi-chain (Ethereum, Solana, Base, Avalanche, Stellar, World Chain) - Evaluated scope: Native EURC token deployments (ERC-20, SPL, Stellar Asset, SEP-41); evaluates token-specific admin/governance keys and host-chain cryptographic inheritance. Excludes bridged/wrapped representations on third-party chains. - QRI score: 9/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: PQ-Recoverable, Roadmap Only, Token-Inherits-L1 ### Summary EURC scores 9/100 (Stage 2: Mitigation / Development). As a standard ERC-20 stablecoin deployed across multiple classical blockchains, EURC inherits full ECDSA vulnerability for all user spend authorization. The token-specific quantum risk is concentrated in Circle's admin EOAs (owner, admin, pauser, blacklister, masterMinter, minters) which control minting, contract upgrades, pausing, and blacklisting via ECDSA signatures. A quantum attacker compromising any admin key could mint unlimited unbacked EURC or freeze/redirect user funds. On the positive side, EURC is highly PQ-Recoverable: as a fiat-backed centralized stablecoin, Circle can freeze off-chain redemptions, deploy new contracts, and restore balances from pre-attack snapshots. Circle has published a comprehensive Post-Quantum Security Roadmap (May 2026) for the Arc blockchain with plans to eventually upgrade smart contracts to support PQ signatures, but this roadmap provides zero production protection for EURC on existing chains as of the evaluation date. No PQ or hybrid-PQ cryptography is deployed anywhere in EURC's production scope. The score is capped by the Stage 2 cap (40), further constrained by the Readiness & Risk Cap (active production spend authorization remains entirely ECDSA-only), and the Factor Score of approximately 9. ### Critical quantum blockers - Admin EOAs (owner, admin, pauser, blacklister, masterMinter) rely entirely on ECDSA signatures. A quantum attacker who compromises any of these keys could mint unlimited EURC, freeze user balances, blacklist addresses, or upgrade the proxy contract to redirect funds. - All user spend authorization for EURC transfers is ECDSA-only, inherited from host chains (Ethereum, Solana, Base, Avalanche, Stellar) which remain entirely classical. - No production PQ or hybrid-PQ protection exists for any EURC-specific cryptographic surface as of the evaluation date. ### Principal risks - Quantum compromise of admin EOAs would allow unlimited minting of unbacked EURC, permanent freezing of user balances, blacklisting of arbitrary addresses, and proxy contract upgrades to redirect funds. - All user transactions rely on host-chain ECDSA/Ed25519 signatures with no PQ fallback; Ethereum EOAs that have sent transactions have permanently exposed public keys (long-exposure attack window). - Circle's PQ roadmap is focused on the Arc blockchain (not yet on mainnet) and does not address EURC on existing chains (Ethereum, Solana, Base, Avalanche, Stellar, World Chain). - No timelock on admin operations means a quantum attacker could execute malicious upgrades instantly with no window for intervention. - Admin EOAs may be backed by MPC/cloud KMS with unknown quantum posture; operational security assumptions are unverifiable. - If CCTP support for EURC is enabled, the CCTP attestation service's ECDSA signatures would create an additional quantum-critical attack surface for cross-chain minting. ## Falcon USD (USDF) - Project page: https://qrindex.org/projects/falcon-finance/ - Complete report JSON: https://qrindex.org/projects/falcon-finance/report.json - Official project website: https://www.coingecko.com/en/coins/falcon-finance - Project type: stablecoin - Evaluated network: Ethereum (primary), BNB Smart Chain, XDC Network, Base - Evaluated scope: USDF token (ERC-20/BEP-20) across all deployed chains, including admin/governance keys, reserve custody, and bridging dependencies - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: None - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Token Inheritance, ECC-Only, Upgradeable Proxy, Multi-Chain, Stablecoin ### Summary Falcon USD (USDF) is a ~$1.62B market-cap overcollateralized synthetic dollar deployed as a standard upgradeable ERC-20/BEP-20 proxy token across Ethereum, BSC, XDC, and Base. It has zero quantum-readiness posture. The project has published no cryptographic inventory, no quantum risk assessment, no PQ migration roadmap, and no quantum-related content of any kind in any official documentation, audit, or roadmap. All spend authorization is inherited from classically ECC-based host chains. Admin control sits behind a 4-of-6 Safe multisig using classical ECDSA. Reserve custody (~$1.76B in backing assets as of March 2026) relies on classical MPC from Fireblocks, Ceffu, BitGo, and ChainUp, with 93.6% held in multisig wallets. No public source code repository exists for independent review. Classical smart contract audits (Zellic, Pashov) cover zero quantum considerations. Falcon Finance's published 2025–2026 roadmap addresses RWA integrations, fiat rails, and institutional products exclusively. QRI Score: 0/100 — Stage 0 (Unassessed / No Evidence). The project is entirely quantum-unprepared across every applicable layer. ### Critical quantum blockers - All spend authorization is ECC-only, inherited from host chains (Ethereum, BSC, XDC, Base) with no PQ or hybrid path — a quantum-capable adversary can forge any USDF transfer on any host chain. - Admin proxy upgrade authority is controlled by a 4-of-6 Safe multisig using classical ECDSA — a quantum attacker who recovers 4 of 6 signer keys can upgrade the implementation, pause transfers, or manipulate the blacklist. - Reserve custody (Fireblocks, Ceffu, BitGo, ChainUp) uses classical MPC — reserves backing ~$1.76B in USDF reserves are protected by quantum-vulnerable threshold schemes. - No public cryptographic inventory exists — the project has not identified or published which cryptographic mechanisms protect user funds, admin controls, or reserve custody. - No quantum risk assessment, migration roadmap, or PQ mitigation design of any kind has been published. ### Principal risks - Quantum key-recovery attack on any host chain (Ethereum, BSC, XDC, Base) enables forgery of USDF transfers for all ~$1.62B in circulating supply. - Quantum compromise of 4-of-6 admin multisig signers enables malicious proxy upgrade, token pausing, or blacklist manipulation — a full takeover of the USDF token contract. - Quantum compromise of MPC-based reserve custodians (Fireblocks, Ceffu, BitGo, ChainUp) could enable theft or misappropriation of the ~$1.76B in collateral backing USDF. - Cross-chain bridges (Chainlink CCIP, Axelar) introduce additional quantum-vulnerable attack surfaces for wrapped/bridged USDF. - No public source code means the implementation's exact cryptographic dependencies and admin capabilities cannot be independently audited, increasing uncertainty about the full attack surface. - With no quantum risk acknowledgment or migration planning, the protocol has no demonstrated capability to respond to accelerating quantum threats. ## Figure Heloc (FIGR_HELOC) - Project page: https://qrindex.org/projects/figure-heloc/ - Complete report JSON: https://qrindex.org/projects/figure-heloc/report.json - Official project website: https://www.figure.com - Project type: tokenized asset - Evaluated network: Provenance Blockchain - Evaluated scope: Tokenized RWA (HELOC portfolio) native to Provenance L1; inherits host chain cryptographic properties with no independent cryptographic namespace. Evaluation covers inherited Provenance L1 quantum exposure. - QRI score: 8.98/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Tokenized RWA, Inherits L1 Score (Provenance Blockchain) ### Summary FIGR_HELOC is a tokenized real-world asset (HELOC portfolio) native to the Provenance Blockchain (Cosmos SDK/CometBFT PoS Layer 1). The token has no independent cryptographic namespace and fully inherits Provenance's quantum exposure. Provenance uses secp256k1 for user transaction spend authorization and ed25519 for validator consensus signatures—both classical ECC schemes vulnerable to Shor's algorithm. No PQC or hybrid-PQC protection is deployed on mainnet. Figure Technologies acknowledged quantum risk in its August 2025 SEC prospectus, and the Provenance whitepaper lists 'Quantum-Resistant Protocol Evolution' as a long-term (24-36 months) vision item with no specific algorithms, implementation plan, or governance proposal. All on-chain FIGR_HELOC ownership and settlement remains quantum-vulnerable. The project is assessed at Stage 1 (Quantum Risk Assessed) with a QRI Score of 19/100. The score is capped by the Stage 1 limit (20) and reflects risk acknowledgment with minimal production protection credit for quantum-safe SHA-256 state-integrity mechanisms. The token's 'digital twin' design with off-chain legal documentation provides potential off-chain recoverability but does not constitute quantum resistance or protect on-chain settlement from quantum-enabled forgery or theft. ### Critical quantum blockers - Spend authorization on Provenance Blockchain is entirely ECC-based (secp256k1) with no PQC or hybrid-PQC support in production. All FIGR_HELOC token ownership, transfer, and settlement paths depend on quantum-vulnerable ECC signatures. - Consensus and validator authentication on Provenance Blockchain uses ed25519 ECC-based signatures, remaining quantum-vulnerable. A quantum adversary could compromise network finality and block certification. - No PQC migration mechanism, prototype, testnet, or mainnet support exists for Provenance Blockchain or FIGR_HELOC token holders. The whitepaper roadmap vision has no implementation plan, algorithm selection, or governance proposal. - Material long-exposure quantum-vulnerable value exists on Provenance (all accounts that have transacted expose public keys on-chain) with no migration, freeze, deprecation, or recovery path. ### Principal risks - Complete quantum vulnerability of all on-chain spend authorization: a CRQC could forge secp256k1 transaction signatures to steal any FIGR_HELOC tokens or manipulate on-chain ownership records. - Consensus and validator authentication on Provenance uses ed25519; a quantum adversary could compromise network finality, validator set integrity, and block certification. - All FIGR_HELOC value-at-risk (approximately $13B+ TVL across Figure's RWA ecosystem as of Sep 2025) is exposed to quantum key-recovery attacks with no migration path, freeze mechanism, or deprecation policy. - No quantum-safe custody, wallet, or HSM workflows exist for FIGR_HELOC tokens. Institutional holders have no protection against long-exposure key compromise. - Public keys are exposed on-chain for every Provenance account that has sent a transaction, creating long-exposure (at-rest) quantum attack surfaces with no time constraint for an adversary. - The Provenance 'Quantum-Resistant Protocol Evolution' roadmap is a whitepaper vision item with no specification, algorithm selection, timeline commitment, or governance proposal, providing no current protection. - Even if off-chain legal documentation could support recovery of underlying HELOC assets, the on-chain token settlement layer would be compromised, potentially freezing secondary market trading and causing cascading trust failures in the RWA tokenization ecosystem. ## Filecoin (FIL) - Project page: https://qrindex.org/projects/filecoin/ - Complete report JSON: https://qrindex.org/projects/filecoin/report.json - Official project website: https://www.coingecko.com/en/coins/filecoin - Project type: blockchain network - Evaluated network: Filecoin Mainnet - Evaluated scope: Native asset, consensus, storage proofs (PoRep/PoSt), FEVM smart contracts, and all on-chain value-at-risk - QRI score: 1.5/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, ECC/BLS-Only Production, Research Acknowledgment Only, Classical-Only ### Summary Filecoin's production cryptography is entirely classical with no post-quantum protection across any critical layer. Spend authorization uses ECDSA (secp256k1) and BLS (BLS12-381) signatures. Consensus relies on BLS block/ticket signatures and Drand BLS threshold randomness. Most critically, the network's core value proposition—verifiable storage via Proof of Replication (PoRep) and Proof of Spacetime (PoSt)—depends on Groth16 zk-SNARKs over BLS12-381 pairings, which a quantum adversary could forge to falsely claim storage rewards or corrupt consensus. Protocol Labs' CryptoNet funded research into lattice-based PQ-SNARKs (2022) demonstrates awareness, but no formal quantum risk assessment, FIP, migration roadmap, prototype, or testnet exists. All address types (f1/secp256k1, f3/BLS, f410/FEVM-secp256k1) remain quantum-vulnerable. The project has not published the minimum required assessment artifacts (Stage 0), and every critical cryptographic layer remains quantum-vulnerable with no mitigation in production. The QRI Score is 2/100, reflecting that while some minimal research acknowledgment exists, there is no formal inventory, threat model, or migration plan. ### Critical quantum blockers - Active production spend authorization remains entirely ECC/BLS-only (secp256k1 for f1/f410 addresses, BLS12-381 for f3 addresses) with no PQC or hybrid-PQC path available. - Storage proofs (PoRep and PoSt) rely on Groth16 zk-SNARKs over BLS12-381 pairings; a quantum adversary could forge storage proofs, breaking the network's economic model and consensus integrity. - Consensus-critical authentication (block signing, ticket signing, Drand randomness beacon) uses BLS12-381 threshold signatures with no PQC alternative. - No public migration roadmap, FIP, prototype, or testnet exists for any post-quantum migration across any critical layer. - Quantum attack can plausibly break supply integrity, state binding, or asset ownership in a critical layer (via forged storage proofs). ### Principal risks - Quantum-enabled storage proof forgery: A quantum adversary could forge Groth16 proofs over BLS12-381, allowing them to claim storage rewards without actually storing data, breaking the network's economic model and data integrity guarantees. - Quantum-enabled spend authorization compromise: All FIL holdings in f1 (secp256k1), f3 (BLS), and f410 (FEVM secp256k1) addresses are vulnerable to Shor's algorithm key recovery from exposed public keys, enabling theft of all on-chain value. - Quantum-enabled consensus takeover: BLS12-381 block and ticket signatures could be forged, allowing a quantum adversary to produce fraudulent blocks and compromise chain finality. - Quantum-enabled randomness manipulation: The Drand BLS threshold randomness beacon could be compromised, enabling grinding attacks on leader election and WindowPoSt/ProveCommit verification. - No migration path exists: There is no FIP, roadmap, prototype, or governance process for migrating any critical layer to post-quantum cryptography, leaving the network entirely exposed with no announced remediation timeline. - Long-exposure public key risk: Reused f1/f3 addresses and transacted f410 EOAs have publicly exposed keys that can be attacked offline with no time constraint. - Deep architectural dependency: The Groth16+BLS12-381 proof system is embedded in the protocol's trusted setup, on-chain verification gas schedule, and storage provider hardware requirements; migration would require a comprehensive re-architecture of the proving subsystem. ## Flare (FLR) - Project page: https://qrindex.org/projects/flare-networks/ - Complete report JSON: https://qrindex.org/projects/flare-networks/report.json - Official project website: https://www.coingecko.com/en/coins/flare-networks - Project type: blockchain network - Evaluated network: Flare Mainnet - Evaluated scope: Native asset (FLR), base layer, consensus, interoperability (FTSO, State Connector, FAssets) - QRI score: 7.5/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only ### Summary Flare is an EVM-compatible PoS L1 network using Avalanche's Snowman++ consensus. The production network relies entirely on classical cryptography (secp256k1 ECDSA for accounts/transactions and likely BLS for validators). While Flare Research published a 2022 whitepaper proposing a hybrid ECDSA + CRYSTALS-Dilithium signature scheme for the EVM, this remains a theoretical design with no evidence of testnet or mainnet implementation. All quantum-critical layers, including spend authorization, consensus authentication, and cross-chain interoperability protocols (FTSO, State Connector, FAssets), remain vulnerable to quantum attacks. The project qualifies for Stage 2 due to the existence of a public mitigation design, but scores low due to the complete absence of production protection or migration tooling. ### Critical quantum blockers - Active production spend authorization remains entirely ECC-only (secp256k1 ECDSA). - Consensus-critical authentication (Snowman++ PoS) relies on classical signatures. - Material long-exposure quantum-vulnerable value exists in transacted EOAs with no migration, freeze, or deprecation path. - FTSO, State Connector, and FAssets bridge verification rely on classical cryptography. ### Principal risks - Shor's algorithm could recover private keys from exposed secp256k1 public keys on-chain, enabling theft of native FLR and ERC-20 assets from transacted EOAs. - Quantum adversaries could forge validator signatures or manipulate Snowman++ consensus sampling, compromising network finality. - FTSO and State Connector attestations rely on classical signatures; a quantum attacker could forge oracle data or cross-chain state proofs, compromising dependent DeFi applications and bridged assets. - LayerZero integration exposes cross-chain messaging to classical signature forgery. ## Gate (GT) - Project page: https://qrindex.org/projects/gatechain-token/ - Complete report JSON: https://qrindex.org/projects/gatechain-token/report.json - Official project website: https://www.coingecko.com/en/coins/gatechain-token - Project type: exchange token - Evaluated network: GateChain Mainnet - Evaluated scope: Native GT on GateChain mainnet (including EVM module). Cross-chain GT representations on Ethereum (ERC-20) and Gate Layer are noted as dependencies but are not the primary evaluated scope. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Migration Required] - No migration path currently available; all native and cross-chain GT remains quantum-vulnerable - Readiness tags: Not Assessed ### Summary GateChain (GT) is an EVM-compatible Layer-1 PoS blockchain operated by Gate.io. Despite 2020 marketing claims that its '40-16-byte hash string' address format provides 'post-quantum attack prevention,' the chain's production cryptography is entirely classical: Ed25519 for native account spend authorization and consensus VRF, and secp256k1/ECDSA for the EVM module. Both are vulnerable to Shor's algorithm. No PQC or hybrid-PQC algorithms exist in the public codebase (github.com/gatechain/crypto), no quantum migration roadmap has been published, and GateChain is conspicuously absent from Gate.io's own May 2026 analysis of quantum-resistant chain roadmaps. The 'post-quantum' address claim appears to reference only a longer hash-based address format, which at best delays public key exposure until first spend (identical to Bitcoin P2PKH) and provides no protection once a transaction is signed. All native GT, ERC-20 GT, and Gate Layer GT remain fully quantum-vulnerable across all attack windows with no migration, freeze, deprecation, or recovery path. The QRI Score of 1 reflects zero meaningful quantum protection, zero migration progress, and unsubstantiated public claims about quantum resistance. ### Critical quantum blockers - Active production spend authorization remains entirely classical (Ed25519 for native GateChain accounts, secp256k1 for EVM accounts) with no PQC or hybrid-PQC path — Readiness & Risk Cap: 40 - Project's public 'post-quantum' address format claim is an unsubstantiated marketing statement; the underlying signature schemes remain fully vulnerable to Shor's algorithm — Readiness & Risk Cap: 5 - No public cryptographic inventory or evidence-backed quantum risk assessment has been published by the project — Readiness & Risk Cap: 10 - Consensus authentication (VRF with Ed25519 public-key verification) is quantum-vulnerable, creating a path to consensus compromise or validator impersonation by a quantum adversary - Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, or recovery path — all circulating GT (~106M) is quantum-vulnerable - Two-way on-chain bridges to Ethereum and Gate Layer allow GT value to flow into similarly quantum-vulnerable systems with no quantum-safe restrictions ### Principal risks - All GT spend authorization (native Ed25519 and EVM secp256k1) is vulnerable to quantum key-recovery via Shor's algorithm, enabling potential theft of any holdings whose public keys are exposed on-chain. - Consensus authentication (VRF with classical public key verification, Ed25519 validator signatures) is quantum-vulnerable, creating a path to consensus compromise or validator impersonation by a quantum adversary. - Long-exposure public keys from previously transacted native accounts and EVM EOAs are permanently vulnerable to offline quantum attack with no migration or deprecation mechanism. - Cross-chain bridge infrastructure connecting Ethereum GT, GateChain native GT, GateChain EVM GT, and Gate Layer GT uses undocumented signer sets that likely rely on classical cryptography. - Misleading 'post-quantum' marketing claims may give users and custodians a false sense of security, delaying necessary migration planning. - No quantum-specific incident response, emergency governance, or disclosure process exists for the event of a quantum-enabled attack. ## Geeq (GEEQ) - Project page: https://qrindex.org/projects/geeq/ - Complete report JSON: https://qrindex.org/projects/geeq/report.json - Official project website: https://geeq.io - Project type: Layer 0 verification infrastructure - Evaluated network: Ethereum (ERC-20) - Evaluated scope: ERC-20 token on Ethereum mainnet; native Geeq Chain not yet launched - QRI score: 6/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ERC-20 Token, Inherits L1 Risk, No PQ Implementation ### Summary Geeq (GEEQ) currently operates solely as an ERC-20 token on Ethereum mainnet. The native Geeq Chain using Proof of Honesty (PoH) consensus remains in testnet phase with no mainnet launch as of 2026-06-01. The official roadmap lists a 'Quantum-Ready Upgrade' for post-quantum cryptography as 'Planned' — not in progress, not implemented. The current production value-at-risk (~$409K market cap, ~38.5M circulating GEEQ) is entirely exposed to Ethereum's quantum-vulnerable ECDSA spend authorization. All testnet cryptography uses Ed25519, which is also an elliptic-curve scheme vulnerable to Shor's algorithm. The project's 2019 whitepaper acknowledges the quantum threat and describes a conceptual multi-chain architecture that could support quantum-ready instances in the future, but no PQC algorithm has been selected, no PQC code is publicly available, no independent audit exists, and no PQC testnet or mainnet deployment is live. The QRI Score of 6 reflects quantum risk awareness with no meaningful production protection. ### Critical quantum blockers - Active production spend authorization (ERC-20 on Ethereum) is entirely ECDSA-only with no PQ or hybrid protection and no announced migration timeline. - Post-quantum cryptography is listed as 'Planned' on the roadmap with no prototype, testnet implementation, public code, or algorithm specification. - No public source code or independent audit exists to verify any cryptographic implementation claims for the native Geeq Chain. ### Principal risks - All ~38.5M circulating GEEQ tokens are held on Ethereum and spend authorization depends entirely on quantum-vulnerable ECDSA signatures. A cryptographically relevant quantum computer could derive private keys from exposed public keys of transacted EOAs and steal tokens. - The native Geeq chain mainnet has no confirmed launch date. Even if launched with current Ed25519 testnet cryptography, it would remain quantum-vulnerable until the 'Quantum-Ready Upgrade' (currently 'Planned') is implemented. - No specific PQC algorithm has been selected or prototyped, creating uncertainty about migration timeline, wallet compatibility, signature sizes, and transaction cost impact. - No public source code exists to independently verify any cryptographic implementation or security claims. - The project has no published independent security audit covering cryptographic layers. - There is no quantum-specific incident response process, emergency governance, or mechanism to freeze or migrate vulnerable ERC-20 balances in the event of a quantum advance. ## GHO (GHO) - Project page: https://qrindex.org/projects/gho/ - Complete report JSON: https://qrindex.org/projects/gho/report.json - Official project website: https://www.coingecko.com/en/coins/gho - Project type: stablecoin - Evaluated network: Ethereum (multi-chain via CCIP: Arbitrum, Base, Avalanche, Gnosis, Plasma) - Evaluated scope: GHO ERC-20 stablecoin token, facilitator governance, permit signatures, and Chainlink CCIP bridge dependency - QRI score: 4/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, ECC-Only Spend Authorization, Long-Exposure Vulnerable Value, Bridge-Dependent: Chainlink CCIP, Token Inheritance: Ethereum L1 ### Summary GHO is a ~$584M ERC-20 stablecoin governed by the Aave DAO with zero quantum readiness. The project has published no cryptographic inventory, no quantum risk assessment, no PQC migration roadmap, and no hybrid-PQC or PQ production protection. All spend authorization uses Ethereum ECDSA (secp256k1), permit signatures (EIP-2612) use ECDSA, governance operates through ECDSA-based EVM transactions, and cross-chain supply integrity depends on Chainlink CCIP's classical cryptographic signers. QRI Score of 4 (Stage 0) reflects the complete absence of project-level quantum readiness work combined with fully quantum-vulnerable production cryptography protecting ~$584M in value. ### Critical quantum blockers - All GHO spend authorization relies on Ethereum ECDSA (secp256k1) with no PQC or hybrid-PQC path. - EIP-2612 permit signatures use ECDSA, creating long-exposure vulnerable signatures on-chain. - Aave DAO governance operates through ECDSA-based EVM transactions; quantum compromise of major AAVE holder keys could enable malicious governance. - Chainlink CCIP uses classical cryptographic signatures from Decentralized Oracle Networks; a quantum break could enable infinite unbacked minting of GHO on destination chains. - No public cryptographic inventory or quantum risk assessment exists for GHO. ### Principal risks - Quantum key recovery from exposed Ethereum EOA public keys: any GHO holder who has sent a transaction has permanently exposed their public key on-chain. - Governance compromise: Quantum break of AAVE token holder keys could enable malicious facilitator onboarding, bucket capacity manipulation, or GSM parameter changes. - Bridge supply-integrity failure: Chainlink CCIP's DON signers use classical cryptography. A quantum attacker could forge cross-chain messages to mint unbacked GHO on L2s. - Permit signature harvesting: EIP-2612 permit signatures broadcast on-chain are permanently harvestable and quantum-vulnerable. - No freeze or deprecation mechanism: GHO has no protocol-level mechanism to freeze, deprecate, or burn quantum-vulnerable tokens. ## Global Dollar (USDG) - Project page: https://qrindex.org/projects/global-dollar/ - Complete report JSON: https://qrindex.org/projects/global-dollar/report.json - Official project website: https://www.coingecko.com/en/coins/global-dollar - Project type: stablecoin - Evaluated network: Ethereum, Solana, Ink, X Layer (bridged via LayerZero OFT to Hyperliquid, Plume, Aptos) - Evaluated scope: USDG stablecoin token across all deployed chains including the LayerZero OFT-bridged USDG0 variant. Evaluated under Token Inheritance (Section 7.2) with token-specific admin key and bridge dependency analysis. - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, No Quantum Protection, Token Inheritance, Bridge Dependent, Centralized Issuer, Stablecoin ### Summary Global Dollar (USDG) is a MAS-regulated USD-pegged stablecoin issued by Paxos Digital Singapore Pte. Ltd., deployed as a standard ERC-20/SPL token on Ethereum, Solana, Ink, and X Layer, with a LayerZero OFT-bridged variant (USDG0) extending to additional chains. As of the evaluation date, USDG has approximately $2.6B in total supply across all chains. QRI Evaluation Result: Score 0/100 — Stage 0 (Unassessed / No Evidence). USDG has no quantum readiness whatsoever. There is no public cryptographic inventory, no quantum threat model, no PQC or hybrid-signature support, no quantum migration roadmap, and no quantum-specific incident-response planning. Every critical cryptographic surface — user spend authorization (inherited from host-chain ECDSA/Ed25519), admin key operations (mint/burn/pause/freeze/upgrade via ECDSA multisigs and an EOA), and the LayerZero OFT bridge (classical DVN/relayer signatures) — remains entirely classical and quantum-vulnerable. The token inherits the quantum risk profile of its host chains (Ethereum, Solana, Ink, X Layer) under the Token Inheritance rule (Section 7.2). Token-specific quantum-critical vulnerabilities include: (1) the DEFAULT_ADMIN 7-owner multisig and operational 3-of-7 multisig, both of which have executed on-chain transactions exposing their public keys to long-exposure quantum attack; (2) the SupplyControl admin EOA (0x3Af3...) which can add supply controllers with $500M–$1B mint capacities and has an exposed public key; and (3) the LayerZero OFT bridge whose DVN signer set relies entirely on classical cryptography. Existing audits (Zellic, Trail of Bits, Halborn) cover classical smart-contract security only. No quantum-scoped audit exists. A $1M bug bounty program was launched on Cantina in March 2026. Confidence in the evaluation is High because the complete absence of quantum protection is verifiable from multiple primary sources (source code, documentation, mainnet deployment, explorer data, independent risk assessments). ### Critical quantum blockers - No public cryptographic inventory or quantum threat model exists for USDG (Readiness & Risk Cap: 10). - All spend authorization is classical ECDSA/Ed25519 only, inherited from host chains (Ethereum, Solana, Ink, X Layer). No PQC or hybrid path exists for any user transaction. - Paxos admin keys (DEFAULT_ADMIN 7-owner multisig, operational 3-of-7 multisig, SupplyControl EOA) use classical ECDSA with on-chain public-key exposure. Compromise would enable unbacked minting, burning, pausing, freezing, contract upgrades, and role changes. - LayerZero OFT bridge (USDG0) relies on classical cryptography for DVN signer sets and relayer authentication. A quantum compromise could enable unbacked minting of bridged USDG0 or draining of locked USDG across chains. - No quantum migration roadmap, no PQC testnet, no hybrid-signature support, and no incident-response plan for quantum cryptographic break exists. ### Principal risks - QUANTUM-CRITICAL: All user spend authorization is classical ECDSA/Ed25519 via host chains. A quantum attacker can derive private keys from exposed public keys and steal any USDG held in addresses that have sent transactions (long-exposure attack window). - QUANTUM-CRITICAL: The DEFAULT_ADMIN 7-owner multisig (0x137Dcd97872dE27a4d3bf36A4643c5e18FA40713) has executed 43+ on-chain transactions. Its constituent signer public keys are exposed. Quantum compromise would grant full control over contract upgrades, role management, and facet changes. - QUANTUM-CRITICAL: The operational 3-of-7 multisig (0x0644Bd0248d5F89e4F6E845a91D15c23591e5D33) controls PAUSE_ROLE, ASSET_PROTECTION_ROLE, and SUPPLY_CONTROLLER_MANAGER_ROLE. Its signer public keys are exposed. Quantum compromise would enable pausing all transfers, freezing/wiping any address, and managing supply controllers. - QUANTUM-CRITICAL: The SupplyControl admin is a single EOA (0x3Af3e85f4f97De7AD0f000B724Fb77fE5ffc024B) with DEFAULT_ADMIN_ROLE and SUPPLY_CONTROLLER_MANAGER_ROLE on the SupplyControl contract. Its public key is exposed on-chain. Quantum compromise would allow an attacker to add malicious supply controllers and mint unbacked USDG at scale (current controller capacities: $500M and $1B). - QUANTUM-CRITICAL: The LayerZero OFT bridge (USDG0) depends on classical-cryptography DVN signer sets and relayer authentication. A quantum attacker who compromises the DVN verification layer could forge cross-chain messages to mint unbacked USDG0 on destination chains or drain locked USDG from the bridge. - No quantum risk assessment, cryptographic inventory, or threat model has been published. Paxos has not publicly acknowledged quantum risk for USDG. - No PQC migration roadmap, testnet, prototype, or research proposal exists. The project has taken zero steps toward quantum readiness. - The EIP-2612 (permit) and EIP-3009 (transferWithAuthorization) functions use EIP-712 ECDSA signatures for gasless delegation. These signatures are quantum-vulnerable and could be forged by a quantum attacker to authorize transfers from any address whose ECDSA public key is known. ## Hedera (HBAR) - Project page: https://qrindex.org/projects/hedera-hashgraph/ - Complete report JSON: https://qrindex.org/projects/hedera-hashgraph/report.json - Official project website: https://www.coingecko.com/en/coins/hedera-hashgraph - Project type: blockchain network - Evaluated network: Hedera Mainnet - Evaluated scope: Native asset (HBAR) and core consensus network layers on Hedera mainnet, evaluated as of 2026-06-05. Token-level assets (HTS tokens), wrapped representations (WHBAR), bridged assets, and L2/sidechain deployments are noted as dependencies but not independently scored. - QRI score: 15/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection, PQ-Recoverable ### Summary Hedera has published one of the most detailed post-quantum migration roadmaps in the blockchain industry (April 2026), with explicit algorithm selection (FN-DSA/ML-DSA for signatures, ML-KEM for TLS), phased sequencing, and dependency analysis. The hashgraph consensus already uses SHA-384 hashing, providing genuine quantum-resistant state integrity. The account model supports in-place key rotation. However, as of June 2026, all production spend authorization, consensus event signing, and the TSS proof system rely entirely on quantum-vulnerable classical signatures (ECDSA secp256k1, Ed25519, Schnorr, BLS). No PQC code, prototype, or testnet exists. The effective QRI score is capped at 25 by the Readiness & Risk Cap for 'Roadmap/proposal only; no public code, prototype, or testnet,' and the Factor Score of 15.28 reflects the gap between excellent planning and zero production protection. The final QRI Score of 15 places Hedera firmly in Stage 2 (Mitigation / Development). ### Critical quantum blockers - Active production spend authorization remains entirely ECC (ECDSA secp256k1, Ed25519). All user accounts, transaction signing, and smart-contract authorization use quantum-vulnerable classical signatures with exposed public keys. - No PQC signature code, prototype, or testnet exists. The published roadmap is a detailed plan only; no production or testnet PQC implementation is available. - Consensus event signing and the TSS (Threshold Signature Scheme) rely on classical signatures (Ed25519, Schnorr, BLS). A quantum computer could forge consensus events. - Material long-exposure value-at-risk exists across all accounts that have submitted transactions, with no migration, freeze, deprecation, burn, or enforced policy path. - Two-way bridges (Axelar, Chainlink CCIP) allow HBAR value to flow into non-PQ-secure systems without quantum-related restrictions. ### Principal risks - All HBAR accounts that have ever submitted a transaction have exposed ECDSA or Ed25519 public keys on-chain, creating a permanent long-exposure attack surface. A future CRQC could derive private keys from these public keys and steal all accessible funds. - Consensus event forging: nodes sign hashgraph events with classical signatures. A quantum adversary could forge events and potentially disrupt consensus ordering or finality. - The TSS (Threshold Signature Scheme) being rolled out in 2026 uses Schnorr and BLS signatures for its chain-of-trust proofs (wraps). These are quantum-vulnerable, meaning bridge verifiers and light clients relying on TSS proofs could be compromised by a quantum adversary. - Axelar and Chainlink CCIP bridges allow unrestricted two-way flow between Hedera and non-PQ-secure chains (Ethereum, etc.), creating cross-chain quantum contagion risk. - FN-DSA (Falcon), Hedera's preferred PQC signature algorithm, is not yet a finalized NIST standard (FIPS 206). The fallback to ML-DSA carries a approximately 3.6x signature size penalty. - No deprecation, freeze, or burn policy exists for dormant or unmigrated accounts with exposed classical public keys. Users can indefinitely maintain quantum-vulnerable accounts even after PQC key types become available. - Signature size increases (20x-72x) may stress Hedera's throughput model, fixed-fee economics, and maximum transaction size limits in ways not yet publicly modeled. ## HTX DAO (HTX) - Project page: https://qrindex.org/projects/htx-dao/ - Complete report JSON: https://qrindex.org/projects/htx-dao/report.json - Official project website: https://www.coingecko.com/en/coins/htx-dao - Project type: exchange token - Evaluated network: Multi-chain (TRON, Ethereum, BSC, BTTC) - Evaluated scope: Standard multi-chain governance token (TRC-20/ERC-20/BEP-20) inheriting host-chain cryptographic security; token-specific DAO governance multisig risk - QRI score: 6.45/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance, Roadmap Only, Multi-Chain, Governance Token, Exchange Token ### Summary HTX DAO (HTX) is a standard multi-chain governance token deployed on TRON, Ethereum, BSC, and BTTC with a market cap of approximately $1.5–1.8B. The token contract is immutable with no admin keys or minting capabilities—a positive design property. However, HTX DAO has published no quantum risk assessment, cryptographic inventory, PQC migration plan, or quantum-resistant implementation. All token spend authorization inherits quantum-vulnerable ECC signatures from its four host chains. Critically, the DAO's governance execution relies on classical multi-signature administrators whose ECC-based keys are quantum-vulnerable. The QRI Score of 6.5 reflects the total absence of quantum readiness activity combined with the availability of public evidence to assess the risk (on-chain contracts, whitepaper, and audit). The score is capped at 10 by the 'No public cryptographic inventory' Readiness & Risk Cap and at 20 by Stage 1. The project qualifies as 'Inherits L1 Score' for token-transaction purposes but carries material token-specific quantum risk from its DAO governance multisig layer. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model has been published by HTX DAO. Readiness & Risk Cap: 10. - All token spend authorization across TRON, Ethereum, BSC, and BTTC relies entirely on host-chain ECC signatures (ECDSA secp256k1 on ETH/BSC, Ed25519/ECDSA on TRON). These are quantum-vulnerable and no PQC migration path exists at the token level. - HTX DAO governance execution is controlled by classical multi-signature administrators using quantum-vulnerable ECC keys. A quantum adversary compromising these keys could deploy malicious governance actions affecting treasury and ecosystem funds. - No quantum risk assessment, PQC migration plan, or quantum-resistant cryptography implementation exists at any level of the HTX DAO ecosystem. ### Principal risks - A cryptographically relevant quantum computer could derive private keys from exposed public keys on any of the four host chains, enabling theft of all HTX tokens held in EOA/standard accounts that have ever sent transactions. - The DAO multi-signature administrators control governance execution including treasury management, liquidity operations, and ecosystem fund allocation. Quantum compromise of the multisig keys could enable unauthorized deployment of governance decisions. - The token inherits quantum risk from four separate L1s, each with different quantum readiness postures. TRON and BSC have less publicly documented quantum migration plans compared to Ethereum's structured roadmap. - Quarterly burn transactions executed by the Governance Committee create recurring quantum-vulnerable signing events with long-exposure public keys on TRON. - No emergency governance process, quantum-specific incident response, or cryptographic agility mechanism exists to respond to a quantum breakthrough affecting any host chain. ## Humanity (H) - Project page: https://qrindex.org/projects/humanity/ - Complete report JSON: https://qrindex.org/projects/humanity/report.json - Official project website: https://www.coingecko.com/en/coins/humanity - Project type: cryptoasset - Evaluated network: Ethereum (ERC-20) + Humanity Protocol zkEVM L2 (Polygon CDK) - Evaluated scope: H ERC-20 token and Humanity Protocol L2 network. The H token is a standard ERC-20 inheriting Ethereum and L2 cryptographic properties. The L2 is a zkEVM rollup on Polygon CDK with Proof-of-Humanity consensus, DIDs, VCs, and ZK-proof-based identity verification. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: ECC-Only, No Quantum Risk Assessment, No PQC Implementation, ERC-20 Token Inherits L1 Risk, Polygon CDK zkEVM, Standard EVM Cryptography ### Summary Humanity Protocol scores 1/100 on the Quantum Readiness Index. The project is a zkEVM Layer 2 built on Polygon CDK with an ERC-20 token (H) on Ethereum. All critical cryptographic layers—spend authorization (ECDSA), consensus authentication, state-integrity verification (pairing-based ZK proofs), and bridge/settlement—rely entirely on classical cryptography vulnerable to quantum attack. The project has published no quantum risk assessment, no cryptographic inventory, no PQC migration roadmap, no prototype, and no testnet or mainnet PQC support. The score of 1 reflects only the evaluator's ability to identify the vulnerability based on publicly documented architecture; the project itself has done no quantum readiness work. The evaluation is capped at 10 by the absence of a public cryptographic inventory and further constrained by the near-zero factor score. ### Critical quantum blockers - NO_PUBLIC_CRYPTOGRAPHIC_INVENTORY: The project has not published a cryptographic inventory or quantum threat model. All critical cryptographic systems inherited from Ethereum and Polygon CDK are quantum-vulnerable. (Cap: 10) - ECC_ONLY_SPEND_AUTH: All transaction and spend authorization relies exclusively on ECDSA (standard EVM accounts). This is a quantum-critical vulnerability enabling offline key-recovery attacks against any EOA that has broadcast a transaction. (Cap: 40) - ECC_ONLY_CONSENSUS: The DAC (Decentralized Attestation Committee) and sequencer authentication relies on standard EVM signatures. No PQC protection exists. (Cap: 70) - PAIRING_BASED_ZK: The zkEVM validity proof system (likely Groth16/PLONK with KZG commitments on BN254) depends on pairing-based cryptography that is broken by quantum computers. This affects state-integrity verification and L1 settlement. (Cap: 70) ### Principal risks - All H token holders using standard Ethereum EOAs are exposed to long-exposure quantum key-recovery attacks: any address that has ever sent a transaction has revealed its ECDSA public key on-chain, enabling offline attack with no time constraint. - The L2's zkEVM validity proofs likely depend on Groth16 or PLONK with KZG polynomial commitments on the BN254 curve. Both the pairing-based proof system and the KZG trusted setup are broken by quantum computers, potentially enabling forged validity proofs and theft from the L1 bridge escrow. - The DAC multi-signature verification for batch attestation uses standard ECDSA. A quantum attacker compromising a threshold of DAC signers could certify fraudulent batches. - The project inherits Ethereum L1 settlement risk: even if the L2 were somehow quantum-secured, the L1 bridge contract and settlement layer remain quantum-vulnerable. - No mechanism exists to freeze, deprecate, migrate, or recover quantum-vulnerable funds. Lost or abandoned tokens with exposed public keys will remain perpetually vulnerable. - The ZK identity verification layer may rely on pairing-based proofs; if compromised, Sybil resistance (the protocol's core value proposition) would fail. ## Hyperliquid (HYPE) - Project page: https://qrindex.org/projects/hyperliquid/ - Complete report JSON: https://qrindex.org/projects/hyperliquid/report.json - Official project website: https://hyperliquid.xyz - Project type: L1 derivatives exchange - Evaluated network: Hyperliquid L1 mainnet - Evaluated scope: Current production Hyperliquid L1 as of 2026-08-20, including native HYPE ownership and transactions, HyperCore, HyperEVM, HyperBFT consensus, wallet and custody paths, and documented production bridge dependencies. - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-08-20 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Classical Cryptography Only, No Production PQ Protection, No Public PQ Migration Path ### Summary Hyperliquid is assessable as a production classical L1, but the supplied evidence shows no public post-quantum or hybrid-PQ protection for native user authorization, exposed accounts, HyperBFT validator authentication, wallets, custody, or migration. Public sources also lack a quantum threat model, cryptographic inventory, migration mechanism, and measurable protected-value coverage. Available bridge audits are limited in scope and do not establish quantum protection for the core protocol. Users and institutions should treat current accounts, validator authentication, and associated custody paths as requiring a future migration rather than as quantum-ready. ### Critical quantum blockers - Production user authorization appears to rely on classical Ethereum-compatible signing, with no evidenced PQC or hybrid-PQC mainnet path. - HyperBFT depends on validator quorum authentication, but no PQC or hybrid-PQC protection is evidenced for validator signatures or block certification. - Transacted classical accounts create long-exposure ownership surfaces, with no evidenced migration, freeze, recovery, deprecation, or enforcement path. - No public cryptographic inventory or quantum threat model covers transaction, consensus, bridge, wallet, custody, and state-integrity dependencies. - Protected coverage for native value, critical wallets, bridges, and protocol-controlled assets is not measured or attested. ### Principal risks - A cryptographically relevant quantum computer could recover keys associated with exposed classical accounts and forge orders, transfers, withdrawals, or other authorized actions. - Quantum compromise of validator authentication could threaten block certification, consensus finality, or validator identity assumptions. - Continued default creation and use of classical accounts expands the future pool of vulnerable balances and protocol activity. - No evidenced migration or enforcement mechanism addresses dormant accounts, critical wallets, treasuries, custodians, bridges, or other long-exposure holdings. - The quantum properties of bridge verification, bridge signers, state commitments, P2P identity, and custody integrations remain insufficiently documented to verify protection. ## Injective (INJ) - Project page: https://qrindex.org/projects/injective-protocol/ - Complete report JSON: https://qrindex.org/projects/injective-protocol/report.json - Official project website: https://www.coingecko.com/en/coins/injective-protocol - Project type: blockchain network - Evaluated network: mainnet - Evaluated scope: Injective L1 blockchain (Cosmos SDK + Native EVM), including consensus, spend authorization, bridges (Peggy, IBC, Wormhole, Hyperlane), and native asset INJ - QRI score: 3.64/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: ECC-Only, No PQC Implementation, No Quantum Roadmap, Classical Cryptography Only, Bridge-Exposed ### Summary Injective (INJ) is a Cosmos SDK-based Layer 1 blockchain with Native EVM, evaluated as of 2026-06-05. Every cryptographic primitive in active production use is quantum-vulnerable: spend authorization uses secp256k1/ethsecp256k1 ECDSA (Shor-breakable), validator consensus uses Ed25519 (Shor-breakable), and all four bridge surfaces (Peggy, IBC, Wormhole, Hyperlane) rely entirely on classical cryptography. No PQC primitives are deployed, no PQC code exists in injective-core or its dependency tree, 0% of mainnet traffic is PQC-protected, and 0% of validators use PQC keys. Injective Foundation has not published a quantum risk assessment, cryptographic inventory, PQC roadmap, migration proposal, or governance discussion addressing quantum threats. The project's demonstrated upgrade capability (Native EVM, Vulcan) is a positive architectural signal but offers zero current quantum protection. The most restrictive Readiness & Risk Cap is 'No public cryptographic inventory' at Max QRI 10, and the raw Factor Score of 3.64 is further capped by Stage 1 (Max QRI 20). Final QRI Score: 4, placing Injective in Stage 1: Quantum Risk Assessed — quantum risk is assessable from public evidence, but no meaningful production protection exists. ### Critical quantum blockers - No public cryptographic inventory: Injective Foundation has not published any inventory of quantum-vulnerable cryptographic primitives. Cap: 10. - Active production spend authorization entirely ECC-only (secp256k1 + ethsecp256k1): all transaction signing is Shor-breakable. Cap: 40. - Validator consensus authentication entirely Ed25519: all validator signatures are Shor-breakable. Cap: 70. - Bridge signer sets entirely classical: Peggy (validator secp256k1 multisig), Wormhole (19-guardian secp256k1), IBC (Tendermint light-client Ed25519 proofs), Hyperlane (ECDSA). Cap: 50 (two-way bridge to non-PQ-secure systems). - Material long-exposure quantum-vulnerable value: effectively all active addresses have revealed public keys; mainnet live since 2021-11-08 with ~4.5 years of accumulated vulnerable signatures including treasury, validator self-stake, and bridge-out authorizations. No migration, freeze, deprecation, or recovery policy. Cap: 55. - No quantum risk assessment, no PQC mitigation design, no roadmap, no governance proposal addressing quantum migration from Injective Foundation. ### Principal risks - All active transaction signing (secp256k1/ethsecp256k1 ECDSA) is Shor-breakable. A CRQC-capable adversary can recover private keys from on-chain public keys and forge any transaction. - All validator consensus keys (Ed25519) are Shor-breakable, enabling consensus compromise, finality reversal, and validator impersonation by a quantum adversary. - The Injective Bridge (Peggy) relies on a validator-orchestrated secp256k1 multisig on Ethereum. A forged Peggy withdrawal signature could drain bridge-locked assets on Ethereum. - Wormhole bridge uses a 19-guardian secp256k1 multisig with 13-of-19 threshold — entirely Shor-breakable and outside Injective's governance control. - IBC light-client verification depends on Tendermint/CometBFT Ed25519 validator signatures. Quantum forgery of IBC proofs could enable cross-chain theft across the Cosmos ecosystem. - Effectively all active Injective addresses have revealed public keys due to the order-book derivatives model requiring continuous on-chain activity. Long-exposure attack surface is near-total. - Dormant balances (validator self-stake, foundation treasury, early holder vesting wallets) have accumulated ~4.5 years of vulnerable signatures since mainnet launch (2021-11-08). No freeze, deprecation, burn, or recovery policy exists. - Injective Foundation has declared no position (option f: Undeclared) on freezing, rescuing, rate-limiting, or migrating quantum-vulnerable balances. - Bridge-out and withdrawal signatures (Peggy MsgSendToEth, Wormhole VAA initiator signatures) persist on-chain forever and could be replayed by a quantum adversary against bridge module state. - No named PQC working group, no PQC mandate, no assigned lead for quantum migration within Injective Labs or Injective Foundation. - Cosmos SDK and CometBFT upstream PQC efforts remain research-stage. Injective inherits whatever upstream ships, adding EVM-side hybrid and bridge migration complexity across IBC, Peggy, Wormhole, and Hyperlane. Estimated migration timeline: 8–13 years. ## Internet Computer (ICP) - Project page: https://qrindex.org/projects/internet-computer/ - Complete report JSON: https://qrindex.org/projects/internet-computer/report.json - Official project website: https://www.coingecko.com/en/coins/internet-computer - Project type: blockchain network - Evaluated network: Internet Computer L1 - Evaluated scope: Native asset, consensus, and cross-chain canister signatures - QRI score: 2/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Classical ECC/BLS, Quantum-Vulnerable Consensus, Quantum-Vulnerable Spend Authorization ### Summary The Internet Computer (ICP) relies entirely on classical cryptography for its core L1 operations. Consensus, finality, and randomness are secured via Threshold BLS, while native spend authorization and cross-chain canister signing (Chain Fusion) use Threshold ECDSA, Threshold Schnorr (BIP340), and Ed25519. All of these schemes are vulnerable to quantum attacks via Shor's algorithm. While DFINITY acknowledged the quantum threat in a 2021 NNS governance proposal (Proposal 35660) and the community has experimented with application-layer PQ signature verification inside canisters, there is no active L1 mitigation design, prototype, or testnet. The protocol's architecture supports crypto-agility and upgrades without hard forks, but the production environment remains fully exposed to long-term quantum risk. ### Critical quantum blockers - Active production spend authorization and cross-chain canister signing remain entirely ECC/BLS/Schnorr/EdDSA-only (Threshold ECDSA, Threshold Schnorr, Ed25519). - Consensus-critical authentication (notarization, finalization, randomness) relies on Threshold BLS, which is vulnerable to Shor's algorithm. - No credible L1 mitigation design, prototype, or testnet exists beyond a 2021 R&D proposal. ### Principal risks - Quantum adversaries could forge Threshold BLS signatures, compromising consensus finality and subnet state integrity. - Threshold ECDSA and Schnorr keys controlling cross-chain assets (Bitcoin, Ethereum, etc.) and native ICP balances are vulnerable to key-recovery attacks once public keys are exposed. - Long-exposure public keys (e.g., subnet registry keys, canister master keys) present immediate at-rest quantum risk. - Lack of a concrete L1 migration roadmap or timeline leaves the network and its integrated ecosystems exposed to future quantum breakthroughs without a coordinated defense path. ## IOTA (IOTA) - Project page: https://qrindex.org/projects/iota/ - Complete report JSON: https://qrindex.org/projects/iota/report.json - Official project website: https://iota.org/ - Project type: DeFi protocol token - Evaluated network: IOTA Rebased Mainnet (L1) - Evaluated scope: Native IOTA asset on IOTA Rebased L1 (post-May 2025 MoveVM/DPoS architecture). PQ features in IOTA Identity v1.7 are noted but do not protect the native asset. - QRI score: 6/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-18 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Partial Protection ### Summary IOTA's Rebased mainnet (launched May 2025) uses a Sui-inspired MoveVM/DPoS architecture with entirely classical ECC cryptography for all critical layers. User transaction signatures use Ed25519 Pure (default), ECDSA secp256k1, or ECDSA secp256r1. Validator/authority consensus signatures use BLS12381 aggregated signatures. All native IOTA asset spend authorization, consensus authentication, and account ownership remain quantum-vulnerable with no PQ or hybrid option available on mainnet. IOTA Identity v1.7 introduces PQ signatures (ML-DSA, SLH-DSA, Falcon, hybrid) but exclusively for Verifiable Credentials/Verifiable Presentations in the identity layer, explicitly not extending to core token spend, consensus, or ledger state. No public PQ migration roadmap, governance proposal, or testnet for the core L1 protocol has been identified. The project demonstrates quantum risk awareness through Identity-layer PQ work and cryptographic agility claims, but no meaningful production protection exists for the native asset or consensus. No independent audit of the core protocol's current cryptographic implementation has been found. The QRI Score of 6 reflects Stage 1 (Quantum Risk Assessed): risk is acknowledged through documentation and Identity-layer PQ work, but no meaningful production PQ protection exists for the native asset. ### Critical quantum blockers - Active production spend authorization remains entirely ECC-only (Ed25519 Pure, ECDSA secp256k1, ECDSA secp256r1) with no PQ or hybrid option for native IOTA asset transactions. - Consensus-critical validator authentication uses BLS12381 (classical pairing-based) aggregated signatures, which are quantum-vulnerable. - No public PQ migration roadmap, governance proposal, or testnet for the core IOTA L1 protocol has been identified. - All native IOTA value (~100% of circulating supply) is quantum-vulnerable with no migration path. ### Principal risks - All native IOTA token holdings controlled by Ed25519 or ECDSA keys are exposed to long-exposure quantum key-recovery attacks once public keys are revealed on-chain (at spend time or through address reuse). - Validator BLS12381 keys are long-exposure: public keys are registered on-chain and remain visible, enabling offline quantum attacks against consensus authentication. - No migration path, freeze mechanism, deprecation policy, or recovery mechanism exists for quantum-vulnerable native IOTA balances. - Bridge dependencies (Echo Protocol, LayerZero/Stargate integration) introduce additional quantum-vulnerable cross-chain value paths with classical ECDSA signer sets. - The absence of any core protocol PQ migration roadmap means the entire native asset supply remains indefinitely exposed to future quantum attacks with no planned mitigation. - P2P node identity uses classical Ed25519 for TLS/QUIC — while not directly spend-critical, it could enable network-level attacks in conjunction with consensus compromise. ## Janus Henderson Anemoy Treasury Fund (JTRSY) - Project page: https://qrindex.org/projects/janus-henderson-anemoy-treasury-fund/ - Complete report JSON: https://qrindex.org/projects/janus-henderson-anemoy-treasury-fund/report.json - Official project website: https://www.coingecko.com/en/coins/janus-henderson-anemoy-treasury-fund - Project type: tokenized asset - Evaluated network: Multi-chain (Ethereum, Arbitrum, Base, Avalanche, BNB Chain, Celo, Plume, Stellar) - Evaluated scope: JTRSY token (ERC-20 via Centrifuge Tranche.sol) — token-specific admin/governance keys plus inherited host-chain risk. Evaluated under QRI Section 7.2 Token Inheritance. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance, Roadmap Only, RWA, Tokenized Asset, No PQ Protection, Admin Key Vulnerability, Multi-chain ### Summary JTRSY scores 1/100 on the Quantum Readiness Index, placing it at Stage 1 (Quantum Risk Assessed). The token has zero quantum readiness. It inherits full ECDSA-based spend authorization vulnerability from its host chains (Ethereum, Arbitrum, Base, Avalanche, BNB Chain, Celo, Plume, Stellar) and additionally exposes ~$1.33B in tokenized Treasury value to quantum attack through Centrifuge's ECDSA-based admin key system (Root contract, ProtocolGuardian/OpsGuardian, Safe multisig with 48-hour timelock). No quantum risk assessment, cryptographic inventory, PQC roadmap, prototype, or migration plan has been published by Janus Henderson, Anemoy, or Centrifuge. Third-party research (BMIC, EternaX) has independently identified Centrifuge's quantum-vulnerable admin key architecture. An off-chain legal fallback exists (tokenized shares can be replaced with traditional shares via the fund administrator) but this is a reactive recovery mechanism, not a quantum-preventive control. The single point awarded reflects the minimum coverage score under Category 3 for having identifiable (but entirely unprotected) value-at-risk. ### Critical quantum blockers - Admin key quantum vulnerability: Centrifuge's ward-based admin system (Root contract → ProtocolGuardian/OpsGuardian → Safe multisig → 48-hour timelock) relies entirely on ECDSA-based Ethereum addresses. A quantum computer capable of running Shor's algorithm could derive private keys from exposed public keys of admin signers, enabling an attacker to: (1) mint unlimited JTRSY tokens, (2) burn holder balances, (3) upgrade or replace the hook contract to manipulate transfer restrictions, (4) reassign ward permissions, or (5) update vault configurations. This controls ~$1.33B in tokenized Treasury value across 8 chains. - No public cryptographic inventory or quantum threat model has been published by Janus Henderson, Anemoy, or Centrifuge for the JTRSY token or the Centrifuge protocol. - Spend authorization for JTRSY token holders inherits host-chain ECDSA vulnerability (Ethereum, Arbitrum, Base, etc.). All holder accounts that have sent transactions have exposed public keys vulnerable to quantum key recovery. - No PQC migration roadmap, prototype, testnet, or production path exists for JTRSY or the Centrifuge protocol. ### Principal risks - Quantum admin key compromise: A CRQC (cryptographically relevant quantum computer) could recover private keys from exposed public keys of the Safe multisig signers, enabling unlimited minting, burning, and protocol manipulation across ~$1.33B in tokenized Treasury value on 8 chains. - Host-chain spend authorization: All JTRSY holder accounts that have ever sent a transaction have exposed ECDSA public keys on their respective host chains. A quantum attacker could recover private keys and transfer tokens from any such account. - No quantum risk governance: The absence of a cryptographic inventory or quantum threat model means the project cannot systematically identify, prioritize, or mitigate quantum-vulnerable surfaces. - Cross-chain expansion amplifies exposure: JTRSY's deployment across 8 chains multiplies the attack surface — each chain has independent admin key deployments potentially controlled by the same ECDSA-based signer set. - Centrifuge protocol dependency: JTRSY's security model depends on the Centrifuge protocol's admin infrastructure (wards, Root, Guardian). Any quantum compromise of Centrifuge's admin layer affects all Centrifuge-issued tokens including JTRSY. - Harvest-now-decrypt-later risk: Admin signer public keys that are already exposed on-chain can be harvested today and decrypted once a sufficiently powerful quantum computer exists, with no time constraint on the attack. - 48-hour timelock provides detection window but does not prevent quantum attack: once admin keys are compromised, the attacker can wait out the timelock and execute malicious transactions. ## Jupiter (JUP) - Project page: https://qrindex.org/projects/jupiter-exchange-solana/ - Complete report JSON: https://qrindex.org/projects/jupiter-exchange-solana/report.json - Official project website: https://www.coingecko.com/en/coins/jupiter-exchange-solana - Project type: exchange token - Evaluated network: Solana - Evaluated scope: JUP governance/ecosystem token (SPL) on Solana mainnet, including Jupiter Exchange protocol admin keys, treasury, and multisig governance. Evaluated under Token Inheritance Rule (7.2) as a standard SPL token lacking custom cryptographic dependencies. - QRI score: 6/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Token Inheritance: Solana L1, Partial Protection, ECC-Only Spend Authorization, Long-Exposure Public Keys ### Summary Jupiter (JUP) is a standard SPL governance/ecosystem token on Solana, evaluated under the Token Inheritance Rule (7.2). JUP inherits Solana L1's quantum security posture entirely: all spend authorization, account controls, admin keys, and multisig governance rely on Ed25519 signatures. Solana has published extensive quantum research (Falcon-512 implementations by Anza and Firedancer on GitHub, Project Eleven PQC testnet, 3-step roadmap) and has an optional quantum-resistant Winternitz Vault live on mainnet for 2+ years. However, zero mainnet PQC protection exists at the protocol level — all transactions remain Ed25519-only. Jupiter has not published its own cryptographic inventory, quantum risk assessment, or migration plan for its admin keys, treasury, or multisig. The protocol's upgrade authority and treasury are controlled by Squads Ed25519 multisig, representing high-value quantum targets. With ~$610M market cap fully exposed to long-exposure Ed25519 public keys on-chain, JUP scores 6/100 — capped at 40 by the 'active production spend authorization remains entirely ECC-only' Readiness & Risk Cap, and further constrained to 6 by the near-total absence of production protection, migration coverage, or token-specific quantum preparedness. Users should monitor Solana's PQC migration timeline, as JUP's quantum safety depends entirely on it. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519-only on Solana mainnet. All JUP token transfers, admin operations, governance actions, and multisig executions depend on Ed25519 signatures vulnerable to Shor's algorithm. Cap: 40. - Solana exposes account public keys directly on-chain (unlike Bitcoin/Ethereum's hashed addresses). 100% of JUP holder accounts have long-exposure Ed25519 public keys visible on-chain, enabling offline quantum key-recovery attacks with no time constraint. - Jupiter protocol upgrade authority and treasury are controlled by Squads multisig using Ed25519 signer keys — a high-value target for quantum adversaries. No migration to Winternitz or other PQC custody exists for these critical keys. ### Principal risks - All JUP spend authorization, admin key operations, multisig governance, and treasury controls depend on Ed25519 signatures that are vulnerable to Shor's algorithm. A cryptographically relevant quantum computer could recover private keys from any of the ~100% on-chain exposed Solana public keys and steal or manipulate JUP token holdings and protocol controls. - Solana's architecture exposes Ed25519 public keys directly on-chain for every account that has ever transacted. This is a long-exposure (at-rest) attack surface: an adversary with a sufficiently capable quantum computer can attack any JUP holder's key offline with no time constraint, unlike Bitcoin/Ethereum where addresses are hashed until first spend. - Jupiter's protocol upgrade authority uses Squads multisig with Ed25519 signer keys and a 12-hour timelock. A quantum attacker compromising the multisig could upgrade Jupiter programs to malicious versions, potentially draining liquidity pools, altering swap routing, or minting tokens before the 12-hour timelock expires. - Jupiter has no published quantum risk assessment, cryptographic inventory for token-specific keys, or migration coordination plan. The project appears entirely dependent on Solana L1 migration with no independent preparedness. If Solana's migration is delayed or requires per-protocol coordination, Jupiter may be caught unprepared. - JUP token has no known bridge or wrapped representation identified in the evidence dossier, but any future cross-chain deployment on non-PQ-secure chains would introduce additional quantum-vulnerable paths under the two-way bridge cap (50). ## JUST (JST) - Project page: https://qrindex.org/projects/just/ - Complete report JSON: https://qrindex.org/projects/just/report.json - Official project website: https://www.coingecko.com/en/coins/just - Project type: DeFi protocol token - Evaluated network: TRON - Evaluated scope: JST governance token (TRC-20) on TRON mainnet, including JustLend DAO governance contracts - QRI score: 3/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Token Inheritance, TRC-20, DeFi, Governance Token, ECDSA-only, TRON Ecosystem ### Summary JUST (JST) is a standard TRC-20 governance token on the TRON blockchain. Under QRI Token Inheritance rules (Section 7.2), it inherits TRON's base-layer quantum security posture — which as of June 5, 2026 is entirely ECDSA-based with no production post-quantum protection. TRON founder Justin Sun has announced a quantum-resistant upgrade roadmap (Q2 2026 testnet, Q3 2026 mainnet) targeting NIST-standardized algorithms (ML-DSA, SLH-DSA), but no formal governance proposal, technical specification, public testnet code, or verifiable mainnet deployment exists. The Shasta testnet (last updated March 18, 2026) shows no quantum-resistant features. All JST spend authorization, governance voting (castVoteBySignature), and Timelock execution remain quantum-vulnerable. Approximately $768M in JST market cap and $6.9B in JustLend DAO TVL are fully exposed. The QRI Score of 3 reflects the presence of a public roadmap announcement but zero production protection and no verifiable quantum-ready implementation. Score is capped at 20 by the Stage 1 cap and Readiness & Risk Cap (risk assessment only; no credible mitigation design). Users and exchanges should monitor TRON's Q3 2026 mainnet upgrade for material changes to quantum-attack readiness. ### Critical quantum blockers - All JST spend authorization and transfer authorization is exclusively ECDSA-based on TRON mainnet — fully vulnerable to quantum key-recovery attacks (Shor's algorithm) - JST governance (GovernorBravo proposals, voting via castVoteBySignature, Timelock execution) relies entirely on quantum-vulnerable ECDSA signatures with no PQ migration path in production - All JST value-at-risk (~$768M market cap, ~$6.9B TVL in JustLend DAO) is held in quantum-vulnerable accounts with long-exposure public keys on TRON - No formal governance proposal, technical specification, or verifiable testnet code exists for TRON's announced quantum-resistant upgrade ### Principal risks - All JST token transfers and approvals are secured exclusively by TRON's ECDSA signatures — a cryptographically relevant quantum computer could recover private keys from public keys exposed in every transaction, enabling theft of all JST holdings - JST governance contracts (GovernorBravoDelegator, Timelock) authorize protocol changes via ECDSA-based voting — a quantum adversary could forge governance votes, pass malicious proposals, and drain protocol-controlled assets - castVoteBySignature in GovernorBravo uses ECDSA recovery — votes signed offline with long-exposure keys are vulnerable to offline quantum attack - TRON's DPoS consensus and validator authentication remain classical — a quantum attack on consensus could disrupt JST transaction finality and governance execution - No JST-specific quantum risk assessment or cryptographic inventory has been published by the JUST team; all quantum-readiness depends entirely on unverified TRON L1 roadmap announcements - Even if TRON deploys PQ mainnet signatures in Q3 2026, JST governance contracts may require separate upgrades to support PQ voting — no token-level migration planning has been evidenced - The ~$6.9B TVL in JustLend DAO (supply markets, sTRX staking, energy rental) is controlled by quantum-vulnerable smart-contract admin paths with no published migration or emergency recovery plan ## Kaspa (KAS) - Project page: https://qrindex.org/projects/kaspa/ - Complete report JSON: https://qrindex.org/projects/kaspa/report.json - Official project website: https://www.coingecko.com/en/coins/kaspa - Project type: blockchain network - Evaluated network: mainnet - Evaluated scope: Native L1 asset and protocol (PoW blockDAG, GHOSTDAG consensus, UTXO model) - QRI score: 6/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Only Spend Authorization, Long-Exposure Public Keys (P2PK), Structurally Vulnerable State Commitments (MuHash/ECDLP) ### Summary Kaspa (KAS) is a proof-of-work blockDAG network using GHOSTDAG consensus with a UTXO model. As of the evaluation date, Kaspa has no production post-quantum cryptographic protection whatsoever. All spend authorization uses Schnorr (default) or ECDSA signatures on secp256k1—both fully vulnerable to Shor's algorithm. The P2PK address format exposes public keys immediately upon funding, creating a massive long-exposure quantum attack surface. Critically, Kaspa's MuHash UTXO commitment scheme depends on the ECDLP, meaning a quantum adversary could forge the network state after data pruning, enabling chain-history rewriting. A community-authored KIP proposes a 4-phase quantum resiliency strategy including P2PKH-Blake2b-256-via-P2SH addresses, but this remains a draft proposal with no production implementation, no official core team adoption, and no mainnet or testnet deployment. Quantum risk is publicly acknowledged (Kaspa wiki FAQ: 'Not yet'), but no official cryptographic inventory, formal risk assessment, or core-team mitigation roadmap exists. The QRI Score of 6 reflects quantum risk awareness without any meaningful production protection. All value-at-risk (~100%) remains exposed to quantum key-recovery attacks. ### Critical quantum blockers - All production spend authorization is ECC-only (Schnorr/ECDSA on secp256k1), fully vulnerable to Shor's algorithm. - P2PK address format exposes public keys immediately upon funding, creating a massive long-exposure quantum attack surface across all funded addresses. - MuHash UTXO commitment scheme depends on the Elliptic Curve Discrete Logarithm Problem (ECDLP). A quantum adversary running Shor's algorithm can forge UTXO set commitments, enabling network state manipulation and chain-history rewriting, exacerbated by Kaspa's data pruning. - No production post-quantum or hybrid-PQC protection exists for any critical layer. All value-at-risk (~100%) remains quantum-vulnerable with no migration path in production. ### Principal risks - 100% of circulating supply is held in quantum-vulnerable addresses with ECC-based spend authorization. A cryptographically relevant quantum computer could derive private keys from on-chain public keys and steal all exposed funds. - P2PK address format exposes public keys at funding time, not at spend time. This creates a long-exposure attack surface: every funded address is immediately vulnerable to offline quantum key-recovery attacks with no time constraint. - MuHash UTXO commitments are structurally dependent on ECDLP. A quantum adversary can forge a UTXO set commitment, and because Kaspa prunes historical block data, nodes would be unable to distinguish the forged state from the legitimate one. This enables chain-history rewriting within a pruning window and fundamentally undermines trustless verification. - Kaspa's data pruning amplifies the MuHash vulnerability: shorter pruning windows reduce the quantum security margin rather than increase it, because the attack cost is proportional to pruning window length. - No migration mechanism, no hybrid-PQC path, no deprecation policy for vulnerable addresses, and no emergency quantum-incident response process exists in production. - The only quantum-related proposal is a community-authored draft KIP with no official core team commitment, no testnet deployment, and no production wallet integration. ## KuCoin (KCS) - Project page: https://qrindex.org/projects/kucoin-shares/ - Complete report JSON: https://qrindex.org/projects/kucoin-shares/report.json - Official project website: https://www.coingecko.com/en/coins/kucoin-shares - Project type: exchange token - Evaluated network: Ethereum (ERC-20) / KuCoin Community Chain (KCC) - Evaluated scope: KCS token across Ethereum ERC-20 and KCC native deployments, including KCC consensus dependency - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Partial Protection ### Summary KuCoin Token (KCS) is a standard exchange/utility token deployed as ERC-20 on Ethereum and native on KuCoin Community Chain (KCC), an EVM-compatible Layer 1 blockchain using Proof of Staked Authority (PoSA) consensus with 29 validators. Both environments rely entirely on classical ECDSA cryptography with no post-quantum implementation, migration plan, or quantum-specific risk assessment for KCS/KCC. KuCoin has demonstrated quantum-risk awareness through educational blog posts and a PQC Gateway Proof of Concept (December 2025) for TLS-level exchange web protection using ML-KEM and Dilithium, but this does not protect on-chain KCS token ownership, KCC consensus validator signatures, or blockchain transaction authorization. All KCS value-at-risk remains in ECDSA-vulnerable addresses and accounts with no migration path, recovery mechanism, or deprecation policy. The project scores at Stage 1 (Quantum Risk Assessed) due to general quantum awareness but lacks any meaningful production protection or migration readiness for the evaluated token scope. ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA-only on both Ethereum (ERC-20 KCS) and KCC (native KCS) - KCC consensus (Proof of Staked Authority) uses ECDSA validator signatures with no PQC or hybrid-PQC protection - No public cryptographic inventory exists cataloging KCC/KCS critical public-key mechanisms, attack assumptions, affected assets, or affected layers - No blockchain-level PQC migration plan, roadmap, testnet, or deployment exists for KCC or the KCS token - Material long-exposure quantum-vulnerable value exists: all KCS holdings in addresses that have sent transactions on Ethereum or KCC have exposed public keys vulnerable to offline quantum attacks ### Principal risks - All KCS token ownership on Ethereum (ERC-20) and KCC (native) relies on ECDSA signatures vulnerable to quantum key-recovery attacks via Shor's algorithm - KCC validator signatures and consensus authentication use classical ECDSA cryptography with no PQC or hybrid-PQC protection; a quantum adversary could forge validator signatures to compromise consensus finality - Long-exposure attack surface: all KCS holdings in addresses that have sent transactions on Ethereum or KCC have exposed public keys vulnerable to offline quantum attacks - No migration tooling, user prompts, wallet support, or enforcement mechanisms exist for KCS holders to transition to quantum-safe custody - No emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities affecting KCS or KCC - Bridge or wrapper mechanisms between Ethereum ERC-20 KCS and KCC native KCS may preserve quantum-vulnerable value paths without restrictions - KuCoin exchange custody wallets holding KCS remain ECDSA-vulnerable with no public attestation of PQC migration or hybrid protection ## LAB (LAB) - Project page: https://qrindex.org/projects/lab/ - Complete report JSON: https://qrindex.org/projects/lab/report.json - Official project website: https://www.coingecko.com/en/coins/lab - Project type: cryptoasset - Evaluated network: BNB Chain (BSC) - Evaluated scope: LAB token (BEP-20, 0x7ec43cf65f1663f820427c62a5780b8f2e25593a) on BNB Chain — standard smart-contract token inheriting L1 QRI per Section 7.2 - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Inherits L1 Score [BNB Chain], No Custom Cryptography, No Admin Keys, Token Inheritance, Roadmap Only (via BNB Chain) ### Summary LAB is a standard BEP-20 token on BNB Chain with no custom cryptography and no token-specific admin keys. Per QRI Section 7.2 (Token Inheritance), it inherently shares BNB Chain's L1 QRI posture. BNB Chain is at Stage 1 (Quantum Risk Assessed), independently rated QRI 19/100 by LayerQu — it published a PQC research report in May 2026 but has zero production PQC deployment. All LAB transactions depend on BNB Chain's quantum-vulnerable ECDSA secp256k1 signatures and BLS consensus. The LAB project itself has published no quantum risk assessment, cryptographic inventory, or migration plan. The token contract (verified on BscScan) is fully immutable with no admin keys — the dossier's 'unrenounced minting authority' claim is contradicted by on-chain source code. The QRI Score of 10 reflects the binding constraint of 'No public cryptographic inventory' at the token project level. ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA-only (inherited from BNB Chain, which has no production PQC deployment). All LAB token transfers depend on BNB Chain's quantum-vulnerable ECDSA secp256k1 signature scheme. - No public cryptographic inventory published by the LAB project itself. The token project has not acknowledged quantum risk, published a threat model, or identified affected cryptographic surfaces. ### Principal risks - All LAB token value is secured by BNB Chain's ECDSA secp256k1 signatures, which are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer. - BNB Chain consensus uses BLS12-381 signatures — also quantum-vulnerable. A quantum attacker compromising BNB Chain consensus could censor or reorder LAB transactions. - >95% insider supply control means the vast majority of LAB value-at-risk is concentrated in a small number of quantum-vulnerable wallets on BNB Chain. - LAB project has no published quantum risk acknowledgement, threat model, migration plan, or incident-response process. - BNB Chain's PQC research is prototype-stage only with no production timeline. Migration remains years away and will impose 40-50% throughput reduction when deployed. ## LEO Token (LEO) - Project page: https://qrindex.org/projects/leo-token/ - Complete report JSON: https://qrindex.org/projects/leo-token/report.json - Official project website: https://www.bitfinex.com/ - Project type: exchange token - Evaluated network: Ethereum (ERC-20) / Vaulta (EOS) - Evaluated scope: Standard ERC-20 exchange utility token with dual-chain issuance on Ethereum and Vaulta, token-specific admin keys, and centralized Bitfinex bridge dependency. Evaluated under Token Inheritance rule (QRI §7.2). - QRI score: 3/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Token Inheritance — Ethereum, Token Inheritance — Vaulta/EOS, Centralized Admin Keys, Centralized Bridge Dependency, Long-Exposure Value-at-Risk ### Summary LEO Token scores 3/100 (Stage 0: Unassessed / No Evidence). LEO is a standard ERC-20 utility token with dual issuance on Ethereum and Vaulta (formerly EOS), inheriting all quantum vulnerabilities of both classical ECC-based host chains. The project has published no cryptographic inventory, no quantum threat model, no risk assessment, no migration roadmap, and no PQ prototype or testnet. All production spend authorization, admin key control, and cross-chain bridge paths remain entirely ECC-dependent. The only positive credit (3 points in Algorithm & Implementation Assurance) reflects the open-source, verified contract code on Etherscan — a baseline transparency property that does not indicate any quantum readiness. Bitfinex has published general educational content about quantum computing risks but has not applied this to LEO specifically. The fully diluted valuation across both chains represents material long-exposure quantum-vulnerable value with no migration, freeze, or recovery path. Token admin keys with mint/burn/upgrade authority introduce an additional quantum-critical attack surface beyond standard holder risk. The QRI Score is capped at 5 by Stage 0 (no quantum work performed) and further constrained by the Factor Score of 3.00. ### Critical quantum blockers - No public cryptographic inventory — project has not published any quantum threat model, affected-asset inventory, or risk assessment (Readiness & Risk Cap: 10) - Active production spend authorization is entirely ECC-based — LEO inherits Ethereum secp256k1 ECDSA and Vaulta/EOS classical ECC for all transaction signatures (Readiness & Risk Cap: 40) - Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path (Readiness & Risk Cap: 55) - Token admin keys (controller address with mint/burn/upgrade authority) are quantum-vulnerable via host-chain ECDSA; controller address public-key exposure status is unverified - Centralized Bitfinex bridge between Ethereum and Vaulta preserves classical ownership paths on both ends with no PQ migration plan ### Principal risks - All LEO token transfers and approvals rely on Ethereum secp256k1 ECDSA signatures, which are breakable by Shor's algorithm on a cryptographically relevant quantum computer. - LEO holdings on Vaulta/EOS rely on the Vaulta chain's classical ECC, which is similarly quantum-vulnerable. - The LEO ERC-20 contract's admin functions (generateTokens, destroyTokens, changeController) are controlled by an Ethereum address secured by classical ECDSA. If the controller's public key is exposed on-chain, a quantum adversary could seize unlimited minting and token-destruction authority. - Bitfinex's centralized conversion bridge between Ethereum (ERC-20) and Vaulta LEO representations relies on internal custody infrastructure with no publicly verifiable post-quantum controls. A compromise of either chain's ECC or Bitfinex's custody keys could enable theft across both representations. - Long-exposure risk: Ethereum EOAs that have transacted LEO have exposed their public keys on-chain, making them vulnerable to offline quantum key-recovery attacks with no time constraint. - No evidence that Bitfinex or iFinex has commissioned any quantum-specific security audit, cryptographic inventory, or migration feasibility study for LEO. - Dormant or lost LEO holdings cannot practically migrate even if a migration path were created, and no salvage/deprecation policy exists to address unmigratable quantum-vulnerable value. ## Litecoin (LTC) - Project page: https://qrindex.org/projects/litecoin/ - Complete report JSON: https://qrindex.org/projects/litecoin/report.json - Official project website: https://www.coingecko.com/en/coins/litecoin - Project type: blockchain network - Evaluated network: Litecoin mainnet - Evaluated scope: Native asset (LTC) on Litecoin mainnet, including MWEB extension block and all standard address formats (L, M, ltc1q, ltc1p, ltcmweb1) - QRI score: 5/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Partial Protection, ECC-Dependent, Long-Exposure Value-at-Risk, MWEB-Quantum-Acknowledged ### Summary Litecoin is a classical PoW UTXO chain with ECDSA/secp256k1 spend authorization and an optional MWEB privacy extension using classical Schnorr, Pedersen commitments, and Bulletproofs on secp256k1-zkp. Every critical cryptographic layer is quantum-vulnerable. The Litecoin project has published exactly one quantum-related mitigation proposal: LIP-0003's switch-commitment-to-Elgamal for MWEB commitments, which addresses only supply-inflation risks in the extension block—not ECDSA key recovery, not base-layer transaction signing, not long-exposure public-key theft. This proposal has never been implemented or activated. No comprehensive cryptographic inventory, quantum threat model, PQC design, prototype, testnet, or migration plan exists. Charlie Lee publicly acknowledged quantum risk in March 2026 but stated the community 'can quite easily switch to quantum safe encryption algorithms' without publishing a roadmap. With ~0.45% of supply in MWEB and >99.5% on the transparent ECC-vulnerable ledger, material long-exposure value-at-risk exists with no protection or migration path. Litecoin's 2.5-minute block time provides partial mitigation against on-spend attacks (<3% success probability per Google Quantum AI) but zero protection against at-rest attacks on already-exposed public keys. The project earns minimal credit for LIP-0003's quantum acknowledgment (Stage 1) but remains far from any production quantum protection. QRI Score 5 reflects evidence of quantum risk awareness at the specification and founder level with no meaningful production protection. ### Critical quantum blockers - No public cryptographic inventory or quantum threat assessment has been published by the Litecoin project. - All production spend authorization (base layer and MWEB) remains exclusively ECDSA/secp256k1 or classical Schnorr—fully vulnerable to Shor's algorithm. - Material long-exposure quantum-vulnerable value exists across P2PK outputs, reused P2PKH/P2WPKH addresses, and P2TR key-path outputs with no migration, freeze, deprecation, or recovery path. - MWEB Pedersen commitments and Bulletproofs rely on the discrete logarithm assumption; the Google Quantum AI paper (iacr 2026/625) identifies an on-setup vulnerability enabling permanent classical inflation exploits after a single ECDLP solution. - No PQC design, prototype, testnet, or mainnet path exists for the base-layer ECDSA spend authorization—the LIP-0003 switch-commitment proposal addresses only MWEB commitment binding, not transaction signing. ### Principal risks - All LTC spend authorization (ECDSA/secp256k1, MWEB Schnorr) is fully breakable by Shor's algorithm—a CRQC can forge transactions and steal funds from any address with an exposed public key. - Significant long-exposure value-at-risk: early P2PK mining outputs, reused P2PKH/P2WPKH addresses, and P2TR key-path outputs have public keys permanently visible on-chain with unlimited attack window. - MWEB Pedersen commitments use fixed public parameters; a single ECDLP solution creates a permanent classical exploit for undetected MWEB inflation (Google Quantum AI paper, iacr 2026/625). - MWEB privacy guarantees are retroactively breakable—a future CRQC can decrypt historical confidential transactions, deanonymizing years of MWEB activity. This damage is irreversible. - No migration, freeze, deprecation, burn, or recovery mechanism exists for quantum-vulnerable UTXOs. Lost/abandoned coins with exposed public keys are permanently vulnerable with no policy path to address them. - Litecoin's development resources are significantly smaller than Bitcoin's; any PQC upgrade would likely trail Bitcoin's already-uncertain timeline, creating a window where LTC is the softer quantum target among BTC-fork chains. - The misleading 'Quantum resistant' claim in official documentation may cause users to falsely believe their funds are protected, delaying precautionary measures. ## Mantle (MNT) - Project page: https://qrindex.org/projects/mantle/ - Complete report JSON: https://qrindex.org/projects/mantle/report.json - Official project website: https://www.coingecko.com/en/coins/mantle - Project type: L2 network token - Evaluated network: Ethereum L2 (OP Stack / ZK Validity Rollup) - Evaluated scope: Native asset (MNT), L2 execution layer, bridge contracts, and data availability dependencies - QRI score: 4/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, EVM-Inherited Risk ### Summary Mantle is an Ethereum L2 ZK Validity Rollup with ~$1.7B in Total Value Secured. Every quantum-critical cryptographic layer in the current production system is quantum-vulnerable: user transaction signatures are ECDSA secp256k1 (and secp256r1 via RIP-7212), L1 proof verification uses Groth16/PLONK over BN254 pairing-based SNARKs, and data availability depends on Ethereum KZG commitments over BLS12-381. Mantle has published zero quantum risk assessment, cryptographic inventory, migration roadmap, or any acknowledgment of the quantum threat. The sole point earned in Migration Status reflects the minimum <25% coverage score for unprotected value-at-risk. The 3 points in Algorithm & Implementation Assurance reflect open-source, reproducible code. Score: 4/100 (Stage Cap: 5, Readiness & Risk Cap: 10, Factor Score: 4). ### Critical quantum blockers - No public cryptographic inventory or project-specific quantum threat model has been published by Mantle. - Active production spend authorization remains entirely ECC-only (ECDSA secp256k1 for standard EVM accounts; secp256r1/P256 via RIP-7212 precompile for Passkeys). No PQ or hybrid signature path exists on mainnet. - L1 settlement and bridge verification depend on Groth16/PLONK SNARK wrappers over BN254 pairing-friendly curve. A quantum adversary could forge validity proofs, enabling theft of bridged and escrowed assets. - Data availability commitments rely on Ethereum blob KZG commitments over BLS12-381. A quantum adversary can break the binding property of KZG, enabling data withholding or state forgery. - All economically relevant value-at-risk (~$1.7B+ TVS) is quantum-vulnerable with long-exposure public keys on transacted EOAs and no migration, freeze, deprecation, burn, recovery, or policy path exists. ### Principal risks - Quantum key-recovery attack on ECDSA secp256k1 accounts: All EOAs that have ever sent a transaction have exposed their public key on-chain. A CRQC can derive private keys offline with no time constraint (long-exposure/harvest-now-decrypt-later). This affects 100% of economically relevant value on Mantle. - Quantum forgery of ZK validity proofs: The Groth16/PLONK SNARK wrapper over BN254 used for L1 verification can be broken by Shor's algorithm on pairings. A quantum adversary could forge a validity proof for a fraudulent state transition, enabling theft of all assets in the L1 bridge/escrow contracts. - KZG commitment binding failure: Ethereum blob KZG commitments over BLS12-381 are vulnerable to quantum pairings attack. A quantum adversary could break the binding property, enabling data withholding attacks that could stall or compromise the rollup. - No migration or recovery mechanism exists: There is no freeze, deprecation, burn, salvage, or policy path for quantum-vulnerable accounts. If a CRQC emerges, all exposed value is at immediate risk with no protocol-level defense. - Bridge/wrapper risk: The Mantle canonical bridge to Ethereum L1 inherits quantum vulnerabilities from both sides. A quantum compromise of either L1 or L2 bridge contracts could drain all bridged assets. - Dependency-chain risk: Mantle depends on Ethereum L1 for settlement and DA. Even if Mantle were to implement PQ protections, it cannot become quantum-ready until Ethereum L1 completes its own PQ migration (targeted ~2029+). ## MemeCore (M) - Project page: https://qrindex.org/projects/memecore/ - Complete report JSON: https://qrindex.org/projects/memecore/report.json - Official project website: https://www.coingecko.com/en/coins/memecore - Project type: meme token - Evaluated network: MemeCore L1 - Evaluated scope: Native asset and EVM-compatible Layer 1 blockchain - QRI score: 3/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only ### Summary MemeCore is an EVM-compatible Layer 1 blockchain tailored for meme coins, operating on a Proof of Staked Authority (PoSA) consensus mechanism derived from a standard Geth fork. The project relies entirely on classical cryptography (secp256k1 ECDSA) for spend authorization, consensus authentication, and account management. While a MiCA-compliant whitepaper includes a boilerplate disclosure acknowledging quantum computing as a potential risk, the project has no public cryptographic inventory, no PQC or hybrid-PQC implementation, and no migration roadmap. Unverified marketing claims regarding a 'post-quantum security layer' are directly contradicted by the open-source codebase. As of the evaluation date, MemeCore presents a full quantum-critical vulnerability surface across all applicable production layers. ### Critical quantum blockers - Active production spend authorization remains entirely ECC-only (secp256k1 ECDSA) with no PQ or hybrid protection. - No public cryptographic inventory or credible quantum mitigation design exists. ### Principal risks - Active production spend authorization and consensus authentication remain entirely ECC-only (secp256k1 ECDSA) with no PQ or hybrid protection. - Standard EVM EOAs expose long-duration public keys on-chain upon first transaction, creating a long-exposure quantum vulnerability for all transacted accounts and dormant holdings. - BEP-20 wrapper on BSC creates a two-way bridge dependency to a non-PQ-secure system, preserving a quantum-vulnerable fallback path for wrapped value. - No public cryptographic inventory, migration roadmap, or quantum-specific incident response plan exists to coordinate a future transition. ## Midnight (NIGHT) - Project page: https://qrindex.org/projects/midnight-3/ - Complete report JSON: https://qrindex.org/projects/midnight-3/report.json - Official project website: https://www.coingecko.com/en/coins/midnight-3 - Project type: blockchain network - Evaluated network: Midnight Mainnet (Cardano Partner Chain) - Evaluated scope: Native asset (NIGHT) on Midnight Network mainnet, including consensus, privacy/proof layers, P2P, and Cardano partner-chain dependencies - QRI score: 10.5/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Partial Protection, HNDL-Mitigated (privacy layer) ### Summary Midnight Network (NIGHT) scores 12/100 on the Quantum Readiness Index, placing it in Stage 2 (Mitigation/Development). The production mainnet (launched March 2026, Kūkolu federated phase) relies entirely on quantum-vulnerable elliptic curve cryptography for all critical layers: sr25519 for AURA block authorship, Ed25519 for GRANDPA finality and libp2p, ECDSA for partner-chain consensus, and Halo 2 (PLONK-derived over BLS12-381) for zero-knowledge proofs. All 24B NIGHT tokens are unshielded UTXOs secured by classical sr25519 public keys with no PQ migration mechanism. The project demonstrates credible post-quantum awareness through the Nightstream lattice-based folding scheme (open-source research prototype on GitHub, developed with Google and Linux Foundation researchers) and architectural concepts like pluggable signatures and statistical blinding for HNDL mitigation. However, none of these mitigations are deployed in production. The raw factor score of 12 reflects the complete absence of production quantum protection across all critical layers, with credit only for risk assessment preparedness and research-stage PQ algorithm development. The score is bounded by the 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only' Readiness & Risk Cap of 40. ### Critical quantum blockers - Active production spend authorization remains entirely classical: sr25519, Ed25519, ECDSA for consensus and P2P, and Halo 2 (PLONK-derived over BLS12-381) for ZK proofs are all vulnerable to Shor's algorithm. - All 24B NIGHT tokens exist as unshielded UTXOs controlled by sr25519 public keys, representing full long-exposure value-at-risk with no migration mechanism deployed. - Privacy and proof layers depend on quantum-vulnerable classical elliptic curve assumptions (Halo 2/BLS12-381); statistical blinding mitigates HNDL for data confidentiality but does not prevent quantum forgery of proofs. ### Principal risks - Quantum-enabled forgery of Halo 2 ZK proofs could allow an attacker to authorize invalid state transitions or spend shielded/unshielded assets, as most Midnight transactions are proof-based rather than signature-based. - All consensus authentication (AURA/sr25519, GRANDPA/Ed25519, BEEFY/ECDSA) is quantum-vulnerable, enabling potential chain reorganization, finality compromise, or validator impersonation. - All 24B NIGHT tokens exist as unshielded UTXOs controlled by sr25519 public keys, representing long-exposure value-at-risk with no migration, freeze, deprecation, or burn mechanism. - The Cardano partner-chain dependency inherits Cardano's quantum-vulnerable cryptography; governance contracts and bridge verification on Cardano are exposed. - Nightstream is explicitly a research prototype ('not production-ready,' 'no audit,' 'research-grade performance/side-channel posture') with no published timeline for mainnet integration. - The Midnight node repository depends on unreleased dependencies, limiting independent verification of the full cryptographic implementation. ## Mochimo (MCM) - Project page: https://qrindex.org/projects/mochimo/ - Complete report JSON: https://qrindex.org/projects/mochimo/report.json - Official project website: https://mochimo.org - Project type: Post-quantum PoW chain - Evaluated network: Mochimo mainnet (v3.0 PoW production network) - Evaluated scope: Native MCM asset and base protocol on Mochimo proof-of-work mainnet as of 2026-08-20, including spend authorization, account and public-key exposure, consensus, state integrity, P2P, and native wallet paths. Excludes the v4.0 proof-of-stake testnet and any third-party wrapped or bridged MCM representations not established by canonical evidence. - QRI score: 86.96/100 - Readiness stage: 4 (Migration Complete / Quantum-Ready) - Evidence confidence: Medium - Evaluation date: 2026-08-20 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: PQ-Native, PQ-Resistant, PoW, WOTS+ ### Summary Mochimo is a PQ-native proof-of-work chain whose native asset has used mandatory WOTS+ authorization since genesis. Its specification, public production code, and mainnet explorer support complete-by-design native ownership coverage, with no evidenced classical native ownership namespace or legacy native migration pool. No current quantum-vulnerable native spend path was identified. The production assessment remains Medium confidence because no usable canonical independent audit was supplied and the evidence does not comprehensively verify every state-integrity, supply-binding, signing-control, and external-dependency property. ### Critical quantum blockers - The canonical record does not fully verify all current production state-integrity and supply-binding properties sufficiently to exclude every quantum-relevant critical-state failure mode. ### Principal risks - Incomplete canonical documentation of production state-integrity and supply-binding mechanisms prevents exclusion of every quantum-relevant critical-state failure mode. - WOTS+ safety depends on correct one-time signing-state discipline; anti-reuse, serialization, randomness, side-channel, fault-injection, HSM, and custody controls are not comprehensively verified in the supplied record. - Any external wrapped or bridged MCM representation could introduce classical ownership or bridge-signing risk and is outside this native-mainnet assessment. - The future proof-of-stake transition would introduce new consensus-authentication requirements and must be reassessed if deployed to mainnet. ## Monero (XMR) - Project page: https://qrindex.org/projects/monero/ - Complete report JSON: https://qrindex.org/projects/monero/report.json - Official project website: https://www.getmonero.org - Project type: PoW privacy chain - Evaluated network: mainnet - Evaluated scope: Native asset (XMR) on Monero PoW privacy chain with no validator signatures; FCMP++ beta stressnet noted as development-stage activity that does not materially protect production users - QRI score: 10.4/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Partial Protection ### Summary Monero (XMR) is a PoW privacy chain whose production cryptographic stack is entirely dependent on elliptic curve cryptography (Ed25519-based CLSAG ring signatures, Pedersen commitments, Bulletproofs+) and is therefore vulnerable to Shor's algorithm across all critical layers: spend authorization, address/public-key exposure, state-integrity, and privacy. The Monero Research Lab has conducted extensive public quantum risk assessments since 2020, earning full marks in Security Assessment & Evidence Preparedness (5.0/5). The FCMP++ beta stressnet (May 2026) introduces forward secrecy for historical transaction privacy using post-quantum commitments, representing meaningful Stage 2 development activity, but it does not replace the ECC-based spend authorization that secures all active XMR. Jamtis-PQ (CSIDH-1024) is a research-stage addressing scheme for post-quantum encryption. No production PQ protection exists for any critical layer. The QRI Score of 10.4 reflects strong risk assessment preparedness combined with zero production quantum protection. All XMR value-at-risk remains quantum-vulnerable. A full PQ migration would require replacing Ed25519 spend authorization, redesigning Pedersen commitments and Bulletproofs+ under PQ assumptions, migrating stealth addressing to PQ key derivation, and coordinating a network-wide hard fork — none of which has progressed beyond research proposals. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519/ECC-based (CLSAG ring signatures); all XMR spend paths are quantum-vulnerable via Shor's algorithm. This is the single most restrictive quantum-critical blocker (Readiness & Risk Cap: 40). - Stealth addresses expose one-time public keys on-chain at transaction broadcast, creating a long-exposure quantum-vulnerable ownership path for all unspent outputs; an attacker with a CRQC can recover private keys from exposed public keys and steal funds. - State-integrity mechanisms (Pedersen commitments, Bulletproofs+) and privacy layers (ring signatures, RingCT amount hiding) rely on ECC/DLP assumptions vulnerable to quantum attack; a quantum adversary could forge commitments (inflation risk), break amount confidentiality, and de-anonymize transaction graphs. ### Principal risks - Quantum key-recovery attack on exposed stealth-address one-time public keys: every Monero transaction broadcasts a one-time public key (tx pub key) on-chain, creating a permanent long-exposure attack surface. A CRQC-capable adversary can recover the private key from any exposed public key, enabling theft of all unspent outputs. - Inflation via forged Pedersen commitments: if discrete log is broken, an attacker can open Pedersen commitments to arbitrary values, potentially creating XMR from nothing and breaking the supply-integrity guarantee. - De-anonymization of the entire transaction graph: Shor's algorithm can break the linkability tag (key image) derivation, identifying the true spender within each ring signature and collapsing sender anonymity across the entire blockchain history. - Amount confidentiality failure: RingCT amount hiding relies on Pedersen commitments; a quantum adversary could decrypt all historical and future transaction amounts. - Wallet seed extraction from public addresses: Monero addresses contain public spend and view keys derived from Ed25519; quantum reversal of this derivation exposes the wallet seed and all associated funds. - No migration path for existing unspent outputs: stealth addresses permanently expose one-time public keys; there is no current mechanism to migrate, freeze, deprecate, or burn quantum-vulnerable UTXOs. - FCMP++ mainnet activation timeline is uncertain (6–12 months from May 2026 stressnet) and even after activation, it will not provide quantum-resistant spend authorization — only forward secrecy for past transaction privacy. ## Morpho (MORPHO) - Project page: https://qrindex.org/projects/morpho/ - Complete report JSON: https://qrindex.org/projects/morpho/report.json - Official project website: https://www.coingecko.com/en/coins/morpho - Project type: DeFi protocol token - Evaluated network: Ethereum (primary), Base, Arbitrum, Optimism, Polygon POS, Scroll, Ink, World Chain, Fraxtal - Evaluated scope: MORPHO ERC-20 governance/utility token (token layer only; protocol-layer Morpho Blue/Midnight lending markets not evaluated) - QRI score: 4/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance: Inherits Ethereum L1 QRI Score, Classical ECC-Only, No Quantum Risk Assessment Published by Project, Governance Multisig Quantum-Vulnerable, DeFi Protocol Token, Cross-Chain (LayerZero OFT) ### Summary Morpho (MORPHO) is a standard ERC-20 governance/utility token for the Morpho DeFi lending protocol, deployed on Ethereum and multiple EVM-compatible chains. Under QRI Section 7.2 (Token Inheritance), the MORPHO token inherits Ethereum's base-layer cryptographic posture for transaction signatures and consensus — meaning all token transfers rely on quantum-vulnerable ECDSA. The token layer itself has no custom cryptographic mechanisms, no post-quantum features, no published quantum risk assessment, and no migration roadmap. Token-specific governance is controlled by a 5/9 Gnosis Safe multisig (morpho.eth) and a 3/5 Rewards multisig, both entirely ECDSA-based. A quantum adversary capable of breaking ECDSA could compromise these multisigs to drain the treasury (~35.7% of 1B total supply allocated to DAO), upgrade the token contract maliciously, or alter protocol parameters. The LayerZero OFT cross-chain bridge (currently paused on Arbitrum) introduces an additional quantum-vulnerable path when active. Morpho Midnight, an upcoming fixed-rate protocol, mentions optional post-quantum signature support in its whitepaper, but this is a design option in a not-yet-deployed system and does not constitute current production protection. The QRI Score of 4 reflects the complete absence of quantum-specific preparedness, protection, migration, or assurance at the token layer, capped at 10 by the lack of any public cryptographic inventory. The Morpho DAO should prioritize publishing a cryptographic inventory, migrating governance multisigs to PQ-safe smart contract wallets once Ethereum supports them (e.g., post-EIP-8141), and developing a token-specific quantum migration plan. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published by the Morpho DAO or Morpho Association (Readiness & Risk Cap: 10) - Governance 5/9 multisig (morpho.eth: 0xcBa28b38103307Ec8dA98377ffF9816C164f9AFa) and Rewards 3/5 multisig (0xF057afeEc22E220f47AD4220871364e9E828b2e9) rely entirely on ECDSA-based Gnosis Safe; a quantum adversary forging signer keys could drain treasury, upgrade the token contract maliciously, or alter protocol parameters - All MORPHO token transfer authorization relies on Ethereum ECDSA signatures; no PQ or hybrid spend-authorization path exists - LayerZero OFT bridge (currently paused on Arbitrum) uses classical cryptography for cross-chain message verification; if reactivated without PQ upgrades, creates a bridge-specific quantum-vulnerable path between chains ### Principal risks - Governance multisig compromise via quantum ECDSA break: The 5/9 multisig at 0xcBa28b38103307Ec8dA98377ffF9816C164f9AFa controls the MORPHO token treasury, token contract upgrades, fee parameters, LLTV/IRM whitelisting, and ENS domain management. A quantum adversary who compromises 5 of 9 signer keys could execute arbitrary governance actions. - Rewards multisig compromise: The 3/5 Rewards multisig at 0xF057afeEc22E220f47AD4220871364e9E828b2e9 controls reward distributions; only 3 signers need to be compromised. - Token contract upgrade path: The MORPHO token is upgradable (proxy pattern); a compromised governance multisig could deploy a malicious implementation that mints, burns, or freezes tokens arbitrarily. - Cross-chain bridge exposure: The LayerZero OFT adapter for MORPHO (morpho-org/morpho-token-l0) relies on LayerZero's classical cryptographic verification. When unpaused, a quantum attacker could potentially forge cross-chain messages to mint or unlock MORPHO tokens on destination chains. - Long-exposure public keys: All MORPHO token holders who have sent transactions from their EOAs have exposed secp256k1 public keys on-chain, vulnerable to offline quantum attack with no time constraint (harvest now, decrypt later). - No migration path for governance: Neither the Morpho DAO nor the Morpho Association has published any plan, timeline, or design for migrating governance multisigs to post-quantum secure alternatives. - Inherited Ethereum risk: The MORPHO token is fully exposed to Ethereum's ECDSA vulnerability. While Ethereum has a structured PQ roadmap targeting ~2029, this timeline extends beyond typical quantum threat horizon estimates and does not guarantee timely token-level protection. ## Naoris Protocol (NAORIS) - Project page: https://qrindex.org/projects/naoris-protocol/ - Complete report JSON: https://qrindex.org/projects/naoris-protocol/report.json - Official project website: https://www.naorisprotocol.com - Project type: Post-quantum cybersecurity and trust-mesh L1 - Evaluated network: Ethereum (ERC-20 token) + claimed sovereign L1 mainnet (invite-only, unverifiable) - Evaluated scope: NAORIS ERC-20 token on Ethereum and claimed post-quantum L1 mainnet - QRI score: 19.91/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Very Low - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Partial Protection, Roadmap Only, Token Inheritance Risk ### Summary Naoris Protocol claims to be a post-quantum native Layer 1 blockchain using NIST ML-DSA (FIPS 204 / Dilithium-5) for all transactions from genesis, with mainnet launched April 1, 2026. However, the primary publicly accessible value-bearing asset is the NAORIS ERC-20 token on Ethereum (~$54M circulating market cap, ~599M tokens, ~2,409 holders), which relies entirely on ECDSA signatures and inherits all of Ethereum's quantum vulnerabilities. The claimed native L1 has no public blockchain explorer, no open-source node software, no chain ID, and no independently verifiable mainnet transactions. Mainnet access is invite-only with permissioned validators. Testnet evidence (106M+ claimed PQ transactions) exists but cannot be independently verified. The bridge mechanism between the ERC-20 token and the native L1 is undocumented and its quantum security is unknown. The project has published some technical documentation and threat awareness content, and has engaged auditors (Hashlock 2025, CertiK), but audit scope appears limited to classical ERC-20 contracts. Overall, the project is in an early mitigation/development stage with testnet-level PQ evidence for the native L1, while production value remains fully exposed to quantum attack on Ethereum. QRI Score: 20/100 (Stage 2 — Mitigation/Development). ### Critical quantum blockers - ERC-20 NAORIS token on Ethereum: all transfers, approvals, and admin operations rely on ECDSA signatures — a quantum-critical vulnerability. The ~$54M circulating supply (599M tokens, ~2,409 holders) is fully exposed to Ethereum's classical cryptography. - Native L1 PQ claims cannot be independently verified: no public blockchain explorer, no open-source node software, no reproducible mainnet transactions, no chain ID. This is a quantum-critical uncertainty. - Bridge mechanism between ERC-20 and native L1 is undocumented and unverified. A two-way bridge from a PQ-claimed L1 back to quantum-vulnerable Ethereum creates a quantum-critical vulnerability if unrestricted. ### Principal risks - 100% of publicly verifiable NAORIS token value (~$54M circulating) resides on Ethereum as an ERC-20 token secured by ECDSA — fully quantum-vulnerable. - ERC-20 token contract is upgradeable (UUPS proxy) with admin-controlled keys on Ethereum; admin key compromise via quantum attack could affect the entire token supply. - The native L1 PQ claims rely entirely on project self-attestation with no independent verifiability path for external observers. - The 'Bridge tokens' feature on the official website implies a two-way flow between Ethereum and the native L1; if unrestricted, this creates a pathway for quantum-vulnerable value to undermine any PQ protection on the native chain. - dPoSec consensus uses BFT elements; the exact cryptographic signature scheme for validator voting is undocumented — Dilithium is known to be challenging for BFT aggregation/threshold use cases. - No evidence of quantum-safe P2P networking, node identity, or peer authentication. - No evidence of hardware wallet, HSM, or institutional custody support for ML-DSA signatures. - The 'irreversible security transition' feature implies classical keys may be initially supported, creating a migration window vulnerability. ## NEAR Protocol (NEAR) - Project page: https://qrindex.org/projects/near/ - Complete report JSON: https://qrindex.org/projects/near/report.json - Official project website: https://www.coingecko.com/en/coins/near - Project type: blockchain network - Evaluated network: mainnet - Evaluated scope: Native asset (NEAR) on NEAR Protocol mainnet, protocol version 86 (upgrade 2.13), including base-layer accounts, consensus, P2P, and Chain Signatures MPC cross-chain infrastructure - QRI score: 42.75/100 - Readiness stage: 3 (Migration Live) - Evidence confidence: Medium - Evaluation date: 2026-07-25 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Partial Protection, Migration Live ### Summary NEAR Protocol activated mainnet upgrade 2.13 on July 20, 2026, adding NIST-standardized FIPS-204 (ML-DSA-65) as an optional third signature scheme for account spend authorization alongside Ed25519 and secp256k1. NEAR's decoupled account model—human-readable account IDs with rotatable access keys—is a genuine structural advantage that enables single-transaction key rotation without address migration. However, as of the evaluation date (2026-07-25, ~5 days post-upgrade), migration coverage is effectively zero, default signing remains Ed25519 (quantum-vulnerable), users can still create new classical-only accounts by default, and no enforcement or deprecation mechanism exists for unmigrated keys. Critically, consensus/validator authentication remains Ed25519-only with no PQ path, and the Chain Signatures MPC cross-chain infrastructure (serving 35+ chains) uses classical threshold cryptography with post-quantum MPC still in research. No independent audit of the ML-DSA implementation has been identified. The QRI Score of 43 reflects optional mainnet PQ spend authorization (Stage 3: Migration Live) capped at 70 by vulnerable consensus and further constrained by near-zero migration coverage, absent consensus protection, and unverified implementation assurance. ### Critical quantum blockers - Consensus/validator authentication remains Ed25519-only: validator endorsement and skip messages are signed with Ed25519, making finality and block production vulnerable to quantum forgery attacks (cap 70). - Chain Signatures MPC network uses classical threshold ECDSA/EdDSA for cross-chain signing across 35+ chains; post-quantum MPC remains in research stage with no production timeline (cap 70). - Default spend authorization remains Ed25519/secp256k1; users can still create new quantum-vulnerable accounts by default; no enforcement, deprecation, or freeze mechanism for unmigrated classical keys (cap 60). - No independent audit of the ML-DSA-65 implementation exists; quantum-critical implementation assurance is unverified by external review. ### Principal risks - Consensus compromise risk: Validator endorsement/skip messages are signed with Ed25519. A quantum adversary capable of forging Ed25519 signatures could disrupt finality, enable double-signing, or halt block production. This is a quantum-critical vulnerability affecting the entire network. - Chain Signatures MPC bridge risk: The 5-of-8 threshold MPC network uses classical ECDSA/EdDSA to sign cross-chain transactions for 35+ external blockchains. Quantum compromise could drain cross-chain assets. Post-quantum MPC remains in research with no production timeline. - Default vulnerability persistence: All new accounts are created with Ed25519 keys by default. Users must proactively rotate to ML-DSA. Without default PQ or enforcement, the vast majority of value will remain quantum-vulnerable indefinitely. - Long-exposure key risk: All NEAR accounts that have submitted transactions have exposed Ed25519 or secp256k1 public keys on-chain, creating an at-rest attack surface for offline quantum key-recovery attacks with no time constraint. - Unverified implementation: The ML-DSA-65 implementation in nearcore has not undergone independent third-party cryptographic audit. While it uses the aws-lc-rs backend and received internal code review, the absence of external validation creates uncertainty about implementation correctness for a security-critical new primitive. - Ecosystem readiness gap: Hardware wallets, browser extension wallets, exchanges (Rosetta), and mirror/fork networks do not yet support ML-DSA-65, creating a multi-year downstream dependency before institutional migration becomes practical. - No emergency quantum response process: The absence of a published quantum-specific incident-response playbook or emergency governance process means the protocol lacks a documented mechanism to respond to a sudden quantum breakthrough. ## Nervos Network (CKB) - Project page: https://qrindex.org/projects/nervos-network/ - Complete report JSON: https://qrindex.org/projects/nervos-network/report.json - Official project website: https://www.nervos.org - Project type: PoW modular smart-contract blockchain network - Evaluated network: mainnet - Evaluated scope: CKB Layer 1 native asset and base protocol - QRI score: 52.65/100 - Readiness stage: 3 (Migration Live) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Partial Protection, Opt-In PQC, PoW, Migration Live ### Summary Nervos CKB demonstrates strong cryptographic agility through its RISC-V based CKB-VM, enabling deployment of a NIST-standardized SPHINCS+ (FIPS 205) lock script on mainnet without a hard fork. The SPHINCS+ implementation is open-source, audited by ScaleBit, and supported by a community desktop wallet (Quantum Purse). However, quantum protection is strictly opt-in: the default lock script remains secp256k1 (ECC-only), users can still create new quantum-vulnerable accounts by default, and no migration enforcement, deprecation, or freeze mechanism exists. The vast majority of CKB value-at-risk almost certainly remains in classical secp256k1-locked cells. The P2P networking layer (Tentacle/Secio) relies on ECDH and secp256k1 ECDSA. PoW consensus with Eaglesong hash avoids validator-signature risk. Godwoken L2 and Force Bridge have been shut down, removing bridge-related quantum exposure. Overall QRI Score of 53 reflects optional mainnet PQ protection with vulnerable defaults and major quantum-critical gaps. ### Critical quantum blockers - Default spend authorization (secp256k1_blake160_sighash_all) is ECC-only and quantum-vulnerable. SPHINCS+ is strictly opt-in with no enforcement, deprecation, or freeze mechanism for classical accounts. - Users can still create new quantum-vulnerable secp256k1 accounts by default; no warnings, prompts, or guardrails prevent this. - P2P node identity and transport encryption (Tentacle/Secio) rely on ECDH (P-256) and secp256k1 ECDSA signatures, making node authentication and session encryption quantum-vulnerable. - No public migration coverage data exists; the vast majority of CKB circulating supply almost certainly remains in classical secp256k1-locked cells with no measurable migration progress. ### Principal risks - Vast majority of CKB circulating supply is secured by secp256k1 (ECC) lock scripts, vulnerable to Shor's algorithm once CRQCs reach sufficient scale. - No mechanism prevents users from creating new quantum-vulnerable secp256k1 accounts; the default wallet path remains ECC-only. - P2P node identity and transport encryption (ECDH P-256 + secp256k1 ECDSA in Secio) is quantum-vulnerable, enabling node impersonation and traffic decryption by a quantum adversary. - Migration coverage is unmeasurable; no public analytics, explorer support, or attestation framework exists to track SPHINCS+ adoption. - No deprecation, freeze, burn, or enforced-migration policy exists for classical secp256k1 accounts, leaving legacy value pools permanently exposed. - Only one community wallet supports SPHINCS+; exchange and institutional custody support is absent, severely limiting practical migration. ## NEXO (NEXO) - Project page: https://qrindex.org/projects/nexo/ - Complete report JSON: https://qrindex.org/projects/nexo/report.json - Official project website: https://www.coingecko.com/en/coins/nexo - Project type: cryptoasset - Evaluated network: Ethereum (ERC-20) - Evaluated scope: ERC-20 token on Ethereum mainnet (0xb62132e35a6c13ee1ee0f84dc5d40bad8d815206); token-specific admin/owner keys; centralized custodial infrastructure (Fireblocks, Ledger Vault) - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Token Inheritance, Quantum Risk Acknowledged, ECC-Only Spend Authorization, Custodial Quantum Exposure ### Summary NEXO is a standard ERC-20 token on Ethereum (QRI Rule 7.2 Token Inheritance) with no independent cryptographic layers, no PQC features, and no quantum migration planning. The token inherits Ethereum's base-layer quantum posture, but token-specific vulnerabilities create additional quantum-critical attack surfaces: a classical ECDSA-secured owner key with privileged transfer authority over allocation pools, and the Nexo platform's entirely classical custodial infrastructure (Fireblocks MPC, Ledger Vault) holding >70% of supply. Nexo published a blog post in April 2025 acknowledging quantum risk to Bitcoin, but this does not constitute a cryptographic inventory, risk assessment, or mitigation plan for the NEXO token. The final QRI Score of 1.0 reflects: (a) a Factor Score of 1.0 driven only by minimal migration-status coverage acknowledgment (<25% protected), (b) a Readiness & Risk Cap of 10 from absence of public cryptographic inventory, and (c) a Stage 1 cap of 20. No PQC protection exists at any layer for the NEXO token or its custodial dependencies. ### Critical quantum blockers - No public cryptographic inventory: Nexo has not published an inventory of quantum-vulnerable cryptographic mechanisms (token contract owner key, custody MPC/HSM keys, platform TLS, authentication systems). This is a Readiness & Risk Cap at 10. - Active production spend authorization is entirely ECDSA-only: NEXO inherits Ethereum's secp256k1 ECDSA for all token transfers. No PQC or hybrid-PQC path exists. This is a Readiness & Risk Cap at 40. - Token contract owner key is quantum-vulnerable: NexoToken contract uses an Owned pattern where the owner (ECDSA-secured Ethereum EOA or multisig) can forcibly transfer tokens from allocation addresses via onlyOwner functions. Quantum compromise enables unauthorized token distribution from investor, team, community, overdraft, and adviser allocation pools. - Custodial platform quantum exposure: Nexo's $7B+ AUM custodial infrastructure relies on Fireblocks MPC (ECDSA-based CGGMP protocol) and Ledger Vault (classical HSM). Over 70% of NEXO token supply is held in company-controlled wallets secured by these quantum-vulnerable systems. Neither offers production PQC signing as of June 2026. - Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, or recovery path: concentrated token supply in classical custodial wallets and exposed owner key create plausible quantum-enabled path to theft. ### Principal risks - Quantum compromise of token contract owner key would allow attacker to drain all allocation pools (investor, team, community, advisers, overdraft reserves) via onlyOwner transfer functions. Owner address is ECDSA-secured Ethereum account whose public key is exposed on-chain if it has ever sent a transaction. - Quantum compromise of Nexo's Fireblocks MPC or Ledger Vault custody keys would expose >70% of NEXO supply held in company-controlled wallets, plus $7B+ of other custodial assets. Fireblocks uses ECDSA-based CGGMP threshold signatures with no production PQC alternative. - NEXO token holders who self-custody on Ethereum are exposed to same ECDSA key-recovery risk as all Ethereum users: any account that has sent a transaction has exposed public key vulnerable to future quantum attack ('harvest now, decrypt later'). - No migration, freeze, burn, or deprecation mechanism exists for quantum-vulnerable NEXO token holdings. Neither Nexo nor Ethereum has activated protocol-level quantum migration path as of June 2026. - Nexo platform's reliance on third-party custody providers (Fireblocks, Ledger Vault) means NEXO's quantum migration timeline is partially dependent on vendors whose PQC roadmaps are still in early research phases with no committed production dates. - Supply concentration risk: Over 70% of NEXO supply is held in company-controlled wallets. Single quantum compromise of Nexo's custody infrastructure could lead to catastrophic loss of token supply, destabilizing token's market value. ## OKB (OKB) - Project page: https://qrindex.org/projects/okb/ - Complete report JSON: https://qrindex.org/projects/okb/report.json - Official project website: https://www.coingecko.com/en/coins/okb - Project type: exchange token - Evaluated network: Ethereum / X Layer (OP Stack) - Evaluated scope: OKB ERC-20 token on Ethereum L1 and native gas token on X Layer L2 - QRI score: 1.75/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Only, Token Inherits Host-Chain Risk, Upgradeable Proxy Risk ### Summary OKB scores 2/100 on the Quantum Readiness Index, placing it in Stage 1 (Quantum Risk Assessed). OKX has published educational articles acknowledging the quantum threat to ECDSA and blockchain security generally, but has not produced an OKB-specific cryptographic inventory, threat model, or risk assessment. No post-quantum or hybrid cryptographic protection exists in any layer: spend authorization, consensus authentication, state integrity, bridge verification, admin/governance keys, and custody paths all remain entirely dependent on classical ECDSA secp256k1. All ~21M OKB in circulation is quantum-vulnerable with no migration, freeze, deprecation, or recovery path. The OP Stack infrastructure (to which X Layer migrated in October 2025) has a published 10-year PQ roadmap (January 2026) targeting ECDSA EOA deprecation by 2036, but this is a future infrastructure plan with zero current production protection for OKB holders. The Ethereum legacy proxy contract retains quantum-vulnerable admin keys despite L1 withdrawals being discontinued. OKB is a standard EVM-based token that fully inherits the quantum vulnerabilities of its host chains (Ethereum L1, X Layer/OP Stack L2) with the additional centralized risk of upgradeable proxy admin keys. ### Critical quantum blockers - No public cryptographic inventory: OKB/X Layer has not published an inventory of critical public-key mechanisms, quantum threat model, affected assets, or affected layers (Readiness & Risk Cap: 10). - Active production spend authorization remains entirely ECDSA secp256k1-only on both X Layer (OP Stack) and Ethereum. No PQC or hybrid-PQC signature support exists in production, testnet, prototype, or design phase specific to OKB. - The OKB token proxy contract on Ethereum (OwnedUpgradeabilityProxy) and X Layer bridge/sequencer infrastructure are controlled by ECDSA-based admin keys and multisigs, creating quantum-vulnerable control paths that could enable contract upgrades, supply manipulation, or bridge compromise. - Material long-exposure quantum-vulnerable value exists (all ~21M OKB circulating supply, exchange-held OKB, bridge-escrowed OKB, and dormant Ethereum ERC-20 OKB) with no migration, freeze, deprecation, burn, or recovery path for quantum-vulnerable keys. - X Layer inherits Ethereum's ECDSA security model for all user transactions, sequencer authentication, and L1 settlement, with no quantum-safe fallback or migration mechanism. ### Principal risks - All OKB spend authorization on X Layer and Ethereum relies on ECDSA secp256k1, which is broken by Shor's algorithm on a sufficiently powerful quantum computer. Every OKB transaction, transfer, and authorization is quantum-vulnerable. - The OKB proxy contract on Ethereum (OwnedUpgradeabilityProxy) is controlled by an ECDSA-secured admin key. A quantum attacker who breaks this key could upgrade the contract to a malicious implementation, potentially affecting residual ERC-20 balances or creating confusion across the ecosystem. - X Layer bridge contracts (OP Stack + AggLayer mode) and sequencer infrastructure are controlled by classical multisigs and ECDSA keys. Compromise of these keys could enable bridge theft, malicious state transitions, or forced network upgrades. - Long-exposure public keys: all OKB held in Ethereum EOAs that have ever sent a transaction, all sequencer/bridge signer keys, and all admin keys have publicly exposed public keys vulnerable to offline quantum attack with no time constraint. - No migration mechanism exists for OKB holders to transition to quantum-safe keys or accounts. Users cannot voluntarily protect their holdings against quantum attacks even if they wanted to. - The OP Stack PQ roadmap (10-year timeline to 2036) is a credible infrastructure-level plan but does not bind OKX to any specific timeline for OKB/X Layer migration, nor does it address token-specific admin keys, bridge governance, or legacy Ethereum contract exposure. - Dormant and exchange-held OKB on Ethereum (pre-August 2025 migration) with exposed public keys represents a permanent quantum-vulnerable value pool with no deprecation, freeze, or recovery mechanism. - No quantum-specific incident response process exists. If a quantum attack on ECDSA became practical, there is no public plan for emergency pause, migration acceleration, or user communication. ## Ondo (ONDO) - Project page: https://qrindex.org/projects/ondo-finance/ - Complete report JSON: https://qrindex.org/projects/ondo-finance/report.json - Official project website: https://www.coingecko.com/en/coins/ondo-finance - Project type: DeFi protocol token - Evaluated network: Ethereum (primary), Polygon, BNB Chain, Solana, Noble - Evaluated scope: ERC-20 governance token with tokenized RWA control plane - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Inherits L1 Score [Ethereum], Token: Standard ERC-20, Multi-Chain Protocol, Real-World Assets (RWA), No Quantum Readiness Features, Admin-Key Quantum-Critical Vulnerability ### Summary Ondo Finance is a leading DeFi protocol for tokenized real-world assets (RWAs) with approximately $2B in ONDO market capitalization and $3.75B in total value locked across OUSG, USDY, Ondo Global Markets, and related products. The ONDO token itself is a standard ERC-20 on Ethereum that inherits Ethereum's base-layer quantum readiness posture for token transfers. However, the protocol's control plane — including 4-of-7 Gnosis Safe admin multisigs, proxy-upgrade authorities, oracle keys, bridge DVN configurations, and freeze/pause capabilities — relies entirely on ECDSA-secured keys with no post-quantum or hybrid cryptographic protection. Ondo Finance has published no quantum risk assessment, no cryptographic inventory, no PQC migration roadmap, no quantum-specific incident-response process, and no evidence of any post-quantum development work whatsoever. The protocol's otherwise sophisticated security architecture (defense-in-depth, rate limiting, DVN diversity, operational security) is ultimately gated behind the same ECDSA keys a quantum adversary would target. With multi-billion-dollar value-at-risk controlled by quantum-vulnerable keys whose public keys are exposed on-chain through regular multisig operations, the protocol has material, unmitigated quantum-critical vulnerabilities across its entire control plane. QRI Score: 0 (Stage 0 cap of 5, Readiness & Risk Cap of 10 due to absence of cryptographic inventory, Factor Score of 0). ### Critical quantum blockers - No public cryptographic inventory of quantum-vulnerable keys, contracts, bridges, or oracle dependencies (Readiness & Risk Cap: 10) - All production spend authorization, admin-key operations, multisig governance, bridge verification, and oracle authentication remain entirely ECDSA-only with no PQC or hybrid alternative (Readiness & Risk Cap: 40) - Material long-exposure quantum-vulnerable value (~$2B ONDO market cap, ~$3.75B protocol TVL, ~$1.85B in known multisig wallets) controlled by ECDSA keys with exposed on-chain public keys and no migration, freeze, or deprecation path (Readiness & Risk Cap: 55) ### Principal risks - CRITICAL: All admin multisig keys (OUSG ProxyAdmin owner 0xaed4ca..., USDY ProxyAdmin owner 0x1a694a..., Multisig 2 at 0x677fd4ed... holding ~$1.85B) are 4-of-7 Gnosis Safe wallets using standard ECDSA. Public keys are exposed on-chain through routine execTransaction operations. A quantum adversary recovering any 4 of 7 private keys gains unrestricted upgrade, mint, burn, pause, and freeze authority. - CRITICAL: No timelock exists on OUSG or USDY proxy upgrades. A quantum-compromised multisig can execute instantaneous, irreversible contract upgrades with no delay for detection or intervention. - CRITICAL: Bridge infrastructure (LayerZero OFT with custom DVN configuration) relies on ECDSA for admin operations. While Ondo's multi-DVN architecture and rate limits bound classical blast radius, the admin keys controlling DVN configuration, rate-limit parameters, and emergency controls remain quantum-vulnerable. - HIGH: Oracle keys (attestation signers for Ondo Global Markets mint/redeem operations) use secp256k1 ECDSA. Compromise of these keys could enable unauthorized minting of tokenized securities. - HIGH: No quantum risk assessment means the full scope of quantum-vulnerable cryptographic dependencies across the multi-chain protocol (Ethereum, Solana, Polygon, BNB Chain, Noble, Mantle, Arbitrum) is unknown even to the project itself. - MEDIUM: Off-chain custodians BitGo and Hex Trust have not published quantum-readiness roadmaps specific to their Ondo custody arrangements, creating an unassessed dependency chain for tokenized RWA backing. - MEDIUM: The Ondo DAO governance token (ONDO) itself is secured by standard Ethereum ECDSA; token holder voting power could be compromised through quantum key-recovery attacks against delegate/whale addresses with exposed public keys. - LOW: Ondo Chain (pre-launch) may eventually introduce PQC capabilities, but its cryptographic design is unpublished and its launch timeline uncertain. It provides zero protection for the current production system. ## Ondo US Dollar Yield (USDY) - Project page: https://qrindex.org/projects/ondo-us-dollar-yield/ - Complete report JSON: https://qrindex.org/projects/ondo-us-dollar-yield/report.json - Official project website: https://www.coingecko.com/en/coins/ondo-us-dollar-yield - Project type: tokenized asset - Evaluated network: Ethereum (primary), multi-chain (Arbitrum, Mantle, Solana, Sui, Aptos, Stellar, Sei, Noble, Plume) - Evaluated scope: Token-specific admin/governance keys and cross-chain bridge dependency; inherits L1 QRI from host chains - QRI score: 3.33/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Tokenized RWA, Not Assessed by Project, Classical-Only Admin Keys, Quantum-Vulnerable Bridge Dependency, Multi-Chain, Long-Exposure Admin Key Risk ### Summary Ondo US Dollar Yield (USDY) is a tokenized real-world asset representing claims on short-term US Treasuries, deployed across 10+ blockchains with ~$994M in AUM. As a smart-contract token, user-level transfers inherit host-chain quantum risk profiles. However, USDY has token-specific quantum-critical vulnerabilities that are entirely unaddressed: (1) Admin and upgrade authority is secured by two Gnosis Safe 4-of-7 ECDSA multisigs whose signers' public keys are exposed on-chain — a long-exposure quantum vulnerability enabling complete token takeover by a future quantum adversary. (2) The Ondo Bridge depends on LayerZero OFT adapters with a classical verifier set, creating a cross-chain supply-integrity vulnerability. The project has published no cryptographic inventory, no quantum risk assessment, no migration plan, and no PQ implementation of any kind. The only mitigating factor is that smart contracts are open-source and verified, enabling community review of the classical implementation. The QRI Score of 3.33 reflects zero quantum readiness at the token-specific layer, capped at 10 by the absence of a public cryptographic inventory. This is a Stage 1 (Quantum Risk Assessed) evaluation where the assessment is performed by the evaluator, not self-reported by the project. ### Critical quantum blockers - No public cryptographic inventory published by the project (Readiness & Risk Cap: 10). - Admin/Gnosis Safe multisig keys use classical ECDSA with exposed public keys from executed transactions; quantum key recovery could enable unauthorized mint, burn, freeze, upgrade, or blocklist operations. - Cross-chain bridge (LayerZero OFT adapters) relies on classical verifier set; quantum compromise could authorize fraudulent cross-chain minting across all deployed chains. - No migration plan, PQ roadmap, or quantum-specific governance process exists for any token-specific cryptographic surface. ### Principal risks - Admin key quantum compromise: Both ProxyAdmin owner multisig (0x1a694a...) and Management multisig (0xAEd4ca...) are 4-of-7 Gnosis Safes using ECDSA. Signers have executed transactions on Ethereum mainnet, exposing public keys permanently on-chain. A future CRQC could recover 4 of 7 private keys and execute arbitrary admin actions including: upgrading proxy to malicious implementation, minting unlimited USDY, burning tokens from any address, freezing all transfers, modifying blocklist/allowlist, and changing oracle price parameters. - Bridge validator compromise: The Ondo Bridge uses LayerZero Omnichain Fungible Token Adapters with a classical verifier set (Axelar, Polyhedra, LayerZero Labs, Ondo DVNs). Quantum compromise of these verifier keys could authorize fraudulent cross-chain mint messages, creating unbacked USDY on destination chains. - Harvest-now-decrypt-later (HNDL) exposure: All admin multisig public keys and bridge verifier public keys are already visible on public blockchains. Adversaries can harvest this data today and decrypt it once a CRQC becomes available. - No quantum governance or emergency process: The project lacks any published quantum-specific incident response plan, emergency key rotation procedure, or governance framework for responding to a quantum cryptographic break. - Multi-chain blast radius: USDY is deployed on Ethereum, Arbitrum, Mantle, Solana, Sui, Aptos, Stellar, Sei, Noble, and Plume. A compromise of the Ethereum admin multisig could affect token integrity across all chains due to centralized admin control and cross-chain bridge dependencies. ## Optimism (OP) - Project page: https://qrindex.org/projects/optimism/ - Complete report JSON: https://qrindex.org/projects/optimism/report.json - Official project website: https://www.optimism.io - Project type: AI network token - Evaluated network: OP Mainnet (Ethereum L2 optimistic rollup) - Evaluated scope: OP Mainnet native L2 rollup, OP Stack, L1 bridge dependency, sequencer infrastructure - QRI score: 5.25/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-18 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ECC-Only Production, L2 Rollup, L1-Dependent, Superchain ### Summary Optimism (OP Mainnet) is a Stage 1 (Quantum Risk Assessed) Ethereum L2 optimistic rollup with a comprehensive post-quantum roadmap published January 14, 2026, but zero production PQ cryptographic protection as of June 2026. All spend authorization (EOAs), sequencer block signing, batch submission, L1 bridge escrow, Security Council multisig, and P2P identity remain entirely ECDSA/secp256k1-dependent. Approximately $1.2B in bridged TVL and ~$296M in DeFi TVL (DefiLlama) are exposed to quantum key-recovery attacks with no current mitigation, migration path, prototype, or testnet. The project earns credit for a detailed public roadmap reviewed by Dan Boneh and Justin Drake, enabling infrastructure (EIP-7702 live via Isthmus hardfork, May 2025), and strong open-source codebase, but the QRI Score of 5.25 reflects the absence of any production or testnet PQ protection. The binding Readiness & Risk Cap is 25 (roadmap/proposal only); the Factor Score of 5.25 is lower. The Stage 1 cap of 20 is not binding. Users and institutions should monitor for testnet and mainnet PQ deployments, which are not expected before late 2026 at the earliest per the published roadmap. ### Critical quantum blockers - Roadmap/proposal only; no public PQ code, prototype, testnet, or implementation exists — Readiness & Risk Cap: 25. - Active production spend authorization remains entirely ECDSA-only for all EOAs, sequencer, and batch submitter — Readiness & Risk Cap: 40. - Material long-exposure quantum-vulnerable value exists (~$1.2B bridged TVL, ~$296M DeFi TVL) in transacted EOAs with exposed public keys, L1 bridge escrow contracts, and Security Council multisig, with no migration, freeze, deprecation, or burn path yet active — Readiness & Risk Cap: 55. - Security Council multisig (10-of-13 + 5-of-7 nested) and Foundation multisig use classical ECDSA keys with no PQ migration path; quantum key recovery could enable unauthorized contract upgrades bypassing all fault-proof security. - L1 bridge and settlement dependency inherits Ethereum L1's quantum-vulnerable BLS validator signatures and KZG commitments; Optimism cannot independently mitigate this dependency. ### Principal risks - Harvest-now-decrypt-later: All ECDSA public keys exposed on OP Mainnet (every EOA that has sent a transaction, all sequencer/batcher public keys, all multisig signer addresses) are permanently recorded on-chain and harvestable for future quantum decryption via Shor's algorithm. - Sequencer compromise: A quantum attacker who recovers the sequencer ECDSA private key could submit fraudulent batches, censor transactions, reorder blocks for MEV extraction, and disrupt L2 block production. - Bridge escrow risk: ~$1.2B in bridged TVL is secured by L1 bridge contracts governed by the Security Council multisig and Ethereum L1 settlement. Quantum compromise of the multisig or Ethereum L1 validators could enable unauthorized bridge withdrawals. - Instant upgrade risk: The Security Council multisig (2-of-2 nested: 10-of-13 + 5-of-7) can upgrade all OP Mainnet contracts without timelock. Quantum compromise of these keys would bypass all fault-proof security guarantees and could drain the bridge or alter protocol rules instantly. - L1 dependency: OP Mainnet inherits Ethereum L1 quantum vulnerabilities including BLS validator signatures and KZG commitments for EIP-4844 blob data availability. A quantum break of Ethereum L1 finality would cascade to OP Mainnet settlement. - Superchain cascade: The OP Stack is shared across dozens of chains (Base, Zora, Mode, Unichain, Soneium, Ink). A quantum vulnerability in the shared codebase affects the entire Superchain ecosystem simultaneously. - No PQ algorithm selected: The roadmap defers algorithm selection, adding uncertainty about migration timelines, wallet compatibility, and gas cost implications for the eventual PQ transition. - Long-exposure value: A significant portion of bridged TVL sits in long-exposure EOAs and smart contracts whose admin keys have transacted on-chain. These public keys are permanently harvestable with no deprecation, freeze, or burn mechanism. ## OUSG (OUSG) - Project page: https://qrindex.org/projects/ousg/ - Complete report JSON: https://qrindex.org/projects/ousg/report.json - Official project website: https://ondo.finance/ - Project type: tokenized asset - Evaluated network: Ethereum (primary), Polygon, Solana, XRP Ledger - Evaluated scope: Tokenized RWA (ERC-20 and multi-chain equivalents) with token-specific admin/governance key evaluation; inherits host-chain classical ECC cryptography - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Tokenized RWA, Inherits L1 Score, ECDSA-Only, No Quantum Readiness Work ### Summary OUSG (Ondo Short-Term US Government Treasuries) is a tokenized RWA deployed as a standard ERC-20 token on Ethereum, Polygon, Solana, and XRP Ledger. It inherits the quantum-vulnerable ECDSA/EdDSA spend authorization of all its host chains. Critically, all token-specific administrative functions — including minting, burning, pausing, KYC registry management, contract upgrades, and redemption controls — are secured by a 4-of-7 Gnosis Safe multisig using ECDSA signatures, with no on-chain timelock. Ondo Finance has not published any cryptographic inventory, quantum threat model, PQC migration roadmap, or quantum risk assessment for OUSG. The ToS contains a generic quantum disclaimer that does not constitute QRI-qualifying assessment. With approximately $556M-$625M in AUM (May 2026) and zero quantum readiness work, OUSG represents significant quantum-exposed value-at-risk. The project is at Stage 0 (Unassessed / No Evidence) with a QRI Score of 0/100, capped by the absence of any public cryptographic inventory. Per token inheritance rules (QRI Section 7.2), OUSG shares its host chains' quantum vulnerabilities, with additional token-specific exposure from classical admin keys. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published by Ondo Finance (Readiness & Risk Cap 0: no public cryptographic inventory) - All spend authorization on all host chains is ECDSA/EdDSA-only with no PQ or hybrid-PQC path (Readiness & Risk Cap 40: active production spend authorization remains entirely ECC-only) - Token admin/governance keys are secured by a 4-of-7 Gnosis Safe using ECDSA signatures with no on-chain timelock; quantum key recovery would compromise minting, burning, pausing, contract upgrades, KYC registry, and redemption controls - No PQC migration roadmap, prototype, testnet, or implementation exists for OUSG or its admin infrastructure - Ondo Finance has not published any quantum risk assessment, cryptographic inventory, or migration plan for OUSG token contracts or admin multisig ### Principal risks - Quantum key recovery of any 4 of 7 ECDSA multisig signers would grant an attacker full control over OUSG token contracts, including unlimited minting, burning of any holder's tokens, pausing all operations, modifying the KYC registry, and upgrading to malicious contract implementations - The absence of an on-chain timelock means a quantum-compromised admin multisig could execute destructive upgrades instantly with no user exit window - All user spend authorization across Ethereum, Polygon, Solana, and XRPL relies on quantum-vulnerable ECDSA/EdDSA signatures inherited from host chains - OUSG holders have no alternative exit path; all redemptions flow through Ondo-managed contracts controlled by the same ECDSA admin keys - No migration or recovery mechanism exists for OUSG holders or the protocol itself in the event of quantum compromise - Multisig signer identities are undisclosed, making it impossible to verify whether signers use secure key management practices or whether keys are stored in quantum-vulnerable configurations - OUSG is deployed across multiple chains with different quantum readiness postures, creating a complex inherited risk surface with no unified mitigation strategy - Quantum compromise of the admin multisig could silently modify contract state, whitelist malicious addresses, or drain fund assets before any detection or response ## PAX Gold (PAXG) - Project page: https://qrindex.org/projects/pax-gold/ - Complete report JSON: https://qrindex.org/projects/pax-gold/report.json - Official project website: https://www.coingecko.com/en/coins/pax-gold - Project type: tokenized asset - Evaluated network: Ethereum - Evaluated scope: ERC-20 tokenized gold asset on Ethereum mainnet, including token-specific admin/governance keys (owner, supplyController, assetProtectionRole, feeController). User transaction authorization is inherited from Ethereum L1 per QRI Section 7.2 (Token Inheritance). - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Token Inheritance: Ethereum L1, ECDSA-Only Spend Authorization, Centralized Admin Key Risk, No Quantum Preparedness, No Cryptographic Inventory, No Migration Plan ### Summary PAX Gold (PAXG) is a standard ERC-20 tokenized gold asset on Ethereum, issued by Paxos Trust Company. Per QRI Section 7.2 (Token Inheritance), PAXG inherits Ethereum L1's quantum vulnerability for all user transaction authorization (ECDSA/secp256k1). Beyond inherited L1 risk, PAXG has critical token-specific quantum vulnerabilities in its centralized admin keys. The owner, supplyController, assetProtectionRole, and feeController are all standard Ethereum ECDSA addresses. These admin addresses have transacted on-chain, permanently exposing their public keys. A quantum adversary recovering any of these private keys could mint unlimited PAXG tokens, freeze or wipe any user's balance, or upgrade the proxy contract to a malicious implementation — compromising the entire ~$100M+ token supply integrity. Paxos has published no cryptographic inventory, no quantum risk assessment, no post-quantum migration plan, and no evidence of quantum-resistant admin key protection. The PAXG contract contains no custom post-quantum cryptography and relies entirely on Ethereum's native ECDSA for all authorization paths. The QRI Score is 1, reflecting the complete absence of quantum preparedness at the token-specific level. ### Critical quantum blockers - No public cryptographic inventory: Paxos has not published any inventory of quantum-vulnerable cryptographic mechanisms for PAXG. Readiness & Risk Cap: 10. - Active production spend authorization remains entirely ECDSA-only for all token-specific admin roles (owner, supplyController, assetProtectionRole). A quantum adversary recovering any admin private key could mint unlimited PAXG, freeze all user funds, wipe frozen addresses, or upgrade the contract to a malicious implementation. Readiness & Risk Cap: 40. - Admin addresses have almost certainly sent on-chain transactions (contract deployment, initialization, supply operations, role management), exposing their public keys permanently. This constitutes a long-exposure quantum vulnerability for the entire token supply integrity. ### Principal risks - Supply integrity compromise: A quantum adversary recovering the supplyController private key could mint unlimited PAXG tokens, causing infinite inflation and destroying the gold-backing guarantee. - Asset seizure: A quantum adversary recovering the assetProtectionRole private key could freeze and then wipe (burn) any PAXG holder's balance, enabling targeted theft at scale. - Contract takeover: A quantum adversary recovering the owner private key could pause all transfers indefinitely and upgrade the proxy to a malicious implementation, potentially draining all approved allowances or redirecting all future transfers. - Long-exposure admin keys: All admin role addresses have very likely transacted on-chain (contract deployment, initialization, supply operations), permanently exposing their secp256k1 public keys for offline quantum attack with no time constraint. - No recovery mechanism: Once an admin key is compromised via quantum attack, there is no on-chain mechanism to reverse fraudulent minting, freezing, or wiping. PAXG's centralized architecture means the security of the entire token depends on the continued classical security of a small set of ECDSA keys. - Delegated transfer vulnerability: The betaDelegatedTransfer function uses ecrecover for ECDSA signature recovery, adding another ECDSA-dependent authorization path that a quantum adversary could forge. ## PayPal USD (PYUSD) - Project page: https://qrindex.org/projects/paypal-usd/ - Complete report JSON: https://qrindex.org/projects/paypal-usd/report.json - Official project website: https://www.coingecko.com/en/coins/paypal-usd - Project type: stablecoin - Evaluated network: Ethereum, Solana, Arbitrum - Evaluated scope: Multi-chain fiat-backed stablecoin token (ERC-20 on Ethereum, SPL on Solana, ERC-20 on Arbitrum). Token-specific admin/governance keys and supply-control mechanisms evaluated directly. Host-chain cryptographic layers evaluated via token inheritance (QRI §7.2). - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Classical-Only, Multi-Chain, Stablecoin, Token-Inherits-Host-Chain-Risk, No-Quantum-Work, High-Value-At-Risk ### Summary PayPal USD (PYUSD) scores 1/100 on the Quantum Readiness Index. PYUSD is a centrally-issued fiat-backed stablecoin deployed as standard ERC-20 tokens on Ethereum, Arbitrum, and SPL token on Solana. The project has undertaken zero quantum-specific work: no public cryptographic inventory, no quantum risk assessment, no PQC design or prototype, no migration roadmap, and no acknowledgment of the quantum threat from either Paxos or PayPal. All token-specific admin and governance keys—controlling mint, burn, freeze, pause, and contract upgrade—are classical ECDSA addresses protected only by Gnosis Safe multisig (3-of-20 threshold), which itself relies on ECDSA. The SupplyControl contract's daily rate limits provide operational blast-radius mitigation but zero quantum resistance. With approximately $3.48 billion in circulating supply fully exposed to quantum key-recovery attacks and no migration, freeze, or recovery path, PYUSD represents a high-value quantum-critical vulnerability. The project is at Stage 1 (Quantum Risk Assessed) because the cryptographic inventory is publicly verifiable from source code and on-chain data, even though the issuer has not published or acknowledged a quantum risk assessment. The single point awarded reflects only that the value-at-risk is measurable (<25% coverage tier per QRI §9.3.1). ### Critical quantum blockers - All PYUSD spend authorization is ECC-only via host chains: ECDSA (secp256k1) on Ethereum/Arbitrum, Ed25519 on Solana. No PQ or hybrid signature path exists for any user transaction. - All token-specific admin and governance keys are classical ECDSA addresses protected only by multisig (3-of-20 Gnosis Safe). A quantum attacker capable of breaking ECDSA could compromise proxy admin, owner, assetProtectionRole, and supplyController keys—enabling unlimited mint, freeze/wipe of any address, contract upgrade to malicious logic, and permanent pause. - SupplyControl daily rate limits provide only blast-radius mitigation, not quantum resistance. A quantum attacker forging the supplyController signature can mint up to the daily cap repeatedly or rotate the supplyController address. - No public quantum risk assessment, cryptographic inventory, PQC design, migration roadmap, or acknowledgment of the quantum threat exists from Paxos or PayPal. - Approximately $3.48B in circulating supply (June 2026, CoinMarketCap/CoinGecko; supply contracted ~13% in May 2026 per MetaMask) represents fully quantum-exposed on-chain value with no migration, freeze, deprecation, or recovery path. ### Principal risks - QUANTUM-CRITICAL: A quantum attacker compromising the proxy admin key (ECDSA) can upgrade the PYUSD implementation contract to malicious logic, affecting all ~$3.48B in circulating supply across all holders on that chain. - QUANTUM-CRITICAL: A quantum attacker compromising the owner key can pause all transfers indefinitely, reclaim all PYUSD held by the contract, and change the assetProtectionRole and supplyController—effectively taking full control of the token. - QUANTUM-CRITICAL: A quantum attacker compromising the assetProtectionRole can freeze and wipe the balance of any address, enabling targeted theft or mass destruction of token value. - QUANTUM-CRITICAL: A quantum attacker compromising the supplyController key can mint tokens up to the daily rate limit and immediately rotate the supplyController to a new attacker-controlled address, bypassing future rate limits. Even with caps, repeated daily minting can inflate supply. - QUANTUM-CRITICAL: On Solana, Ed25519 public keys are exposed directly and by default across the entire address space, creating a permanent at-rest attack surface. All PYUSD holder addresses on Solana are vulnerable to offline quantum key-recovery with no time constraint. - QUANTUM-CRITICAL: On Ethereum/Arbitrum, any PYUSD holder address that has ever sent a transaction has an exposed ECDSA public key, creating a long-exposure at-rest vulnerability. Only unused (never-sent) addresses benefit from hash-based address protection. - STRUCTURAL: PYUSD's multi-chain deployment means quantum safety requires independent migration on each host chain (Ethereum, Solana, Arbitrum). A base-layer fix on one chain does not protect PYUSD on others. - STRUCTURAL: As a centrally-issued stablecoin with upgradeable proxy contracts, PYUSD is entirely dependent on Paxos's administrative key management. There is no protocol-level or community-governance path to force quantum migration if Paxos does not act. - OPERATIONAL: The G7 CEG's January 2026 roadmap targets 2035 for financial-sector PQC migration completion with critical systems prioritized for 2030-32. Paxos/PayPal have shown no evidence of engagement with this timeline. ## Pepe (PEPE) - Project page: https://qrindex.org/projects/pepe/ - Complete report JSON: https://qrindex.org/projects/pepe/report.json - Official project website: https://www.coingecko.com/en/coins/pepe - Project type: meme token - Evaluated network: Ethereum - Evaluated scope: PEPE ERC-20 token on Ethereum mainnet (contract 0x6982508145454ce325ddbe47a25d4ec3d2311933); inherits Ethereum L1 QRI per Section 7.2 - QRI score: 4.53/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Token Inheritance: Ethereum L1, Roadmap Only ### Summary PEPE is a standard ERC-20 meme token on Ethereum with a renounced contract and no custom cryptographic mechanisms. Per QRI Section 7.2 (Token Inheritance), PEPE inherently shares Ethereum's base-layer quantum-readiness posture. As of 2026-06-05, Ethereum has no production PQC protection—all spend authorization remains ECDSA-based and consensus relies on BLS signatures, both quantum-vulnerable. The PEPE token contract itself has no admin keys (ownership renounced to zero address), eliminating token-level admin-key quantum risk. However, the project maintains a multisig treasury wallet secured by standard ECDSA, representing a concentrated quantum-vulnerable value pool with a documented history of key-management failures (August 2023: 16T tokens stolen after signer threshold reduced from 5/8 to 2/8). The PEPE project has published no quantum risk assessment, cryptographic inventory, migration roadmap, or PQC custody plan. The QRI Score of 5 reflects verifiable public evidence (contract code, audit) but zero production quantum protection and no project-level quantum readiness work. Token holders should monitor Ethereum's post-quantum migration progress, as PEPE's security depends entirely on Ethereum's transition. ### Critical quantum blockers - Project multisig wallet holding significant PEPE supply uses classical ECDSA signers with no post-quantum migration path or public mitigation plan. - All PEPE token transfers rely on Ethereum's quantum-vulnerable ECDSA transaction signatures; no production PQC path exists on Ethereum mainnet. ### Principal risks - Inherited ECDSA vulnerability: All PEPE token transfers depend on Ethereum's quantum-vulnerable ECDSA transaction signatures. When a cryptographically relevant quantum computer emerges, any PEPE held in EOAs with exposed public keys could be stolen. - Multisig treasury at risk: The PEPE project multisig holds a material portion of token supply behind ECDSA signer keys. If signer public keys are exposed on-chain (likely if those EOAs have sent transactions), the treasury is vulnerable to offline quantum key-recovery attacks with no time constraint (long-exposure/at-rest attack surface). - No migration path: Neither Ethereum L1 nor the PEPE project offers a production PQC migration path for token holders or the multisig as of the evaluation date. Ethereum's structured fork milestones target ~2029 for core PQC infrastructure—several years away. - Operational key-management history: The August 2023 multisig incident (internal theft via threshold manipulation) demonstrates that the remaining multisig signers operate with weak operational controls, compounding the quantum risk for the treasury. ## Pi Network (PI) - Project page: https://qrindex.org/projects/pi-network/ - Complete report JSON: https://qrindex.org/projects/pi-network/report.json - Official project website: https://www.coingecko.com/en/coins/pi-network - Project type: blockchain network - Evaluated network: Pi Network Mainnet - Evaluated scope: Native asset (PI) on Pi Network Mainnet, including consensus, spend authorization, and known bridge/wrapped-asset dependencies - QRI score: 2.75/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Only, Ed25519-Dependent, SCP-Based, No PQC Implementation ### Summary Pi Network is a Stellar Consensus Protocol (SCP) derivative blockchain with a live mainnet, substantial migrated value (>10B PI), and a large user base. All production cryptographic layers — spend authorization, consensus authentication, P2P node identity, and newly introduced ZK-proof infrastructure (BN254 pairings via Protocol v25 X-Ray) — rely exclusively on classical elliptic-curve cryptography (Ed25519). The project acknowledged quantum computing as a technological risk in its MiCA regulatory whitepaper (November 2025), satisfying minimal risk-assessment preparedness, but has published no formal cryptographic inventory, no PQC migration roadmap, no prototype, no testnet, and no mainnet PQC or hybrid-PQC path. Viral community claims about 'v25/v26 Quantum Core' are unsubstantiated speculation absent from all official Pi Core Team communications. A third-party bridge (PiBridge) enables two-way wrapped PI flow to BSC, creating an additional quantum-vulnerable value path. No independent cryptographic audit of the core protocol exists. The QRI Score of 3 reflects: acknowledgment of quantum risk without any meaningful production protection, no public cryptographic inventory, and fully quantum-vulnerable critical layers. This places Pi Network at Stage 1 (Quantum Risk Assessed) with an effective Readiness & Risk Cap of 10 from the absence of a public cryptographic inventory. ### Critical quantum blockers - All spend authorization uses Ed25519 (ECC) signatures — vulnerable to Shor's algorithm on a CRQC. - All consensus authentication (SCP quorum messages, nomination, balloting) uses Ed25519 — quantum-vulnerable. - No public cryptographic inventory has been published by the Pi Core Team. - No PQC migration roadmap, prototype, testnet, or mainnet path exists in any official capacity. - Third-party PiBridge enables two-way wrapped PI flow to BSC (non-PQ-secure), creating a quantum-vulnerable value path. ### Principal risks - Quantum-critical vulnerability: All transaction spend authorization uses Ed25519. A CRQC could forge signatures and steal any PI from any address whose public key is known or derivable. - Quantum-critical vulnerability: SCP consensus messages (nomination, balloting, externalize) are authenticated with Ed25519. A quantum adversary could forge consensus messages, potentially disrupting finality or enabling double-spend attacks. - Quantum-critical vulnerability: Protocol v25 introduced X-Ray with BN254 pairing support for ZK-proofs. BN254 is vulnerable to Shor's algorithm, meaning any ZK-based privacy or scaling applications built on this infrastructure inherit quantum vulnerability. - Quantum-critical uncertainty: The Pi Core Team has made no official statement about quantum readiness. Community-speculated 'Quantum Core' claims are unverifiable and contradicted by the absence of any PQC code, specification, or official announcement. - Quantum-critical uncertainty: The core consensus node implementation is not open-source, making independent verification of cryptographic primitives impossible without official disclosure. - Bridge risk: PiBridge (third-party) enables wrapping PI to WPI on BSC (BEP-20). BSC is not PQ-secure. Value flowing through this bridge inherits BSC's quantum vulnerability, and a two-way bridge allows vulnerable value to potentially affect Pi Network's economic security. - Value-at-risk concentration: With >10B PI migrated and a market cap of ~$1.79B, the economically exposed value to quantum attack is substantial. The project's KYC-based migration model means most migrated value sits in identified, KYC-linked accounts with known public keys. - No migration path: There is no official mechanism — not even a roadmap proposal — for migrating from Ed25519 to PQC or hybrid signatures. The network lacks the governance, tooling, coordination framework, and cryptographic agility needed to execute a migration before a quantum threat materializes. ## POL (ex-MATIC) (POL) - Project page: https://qrindex.org/projects/polygon-ecosystem-token/ - Complete report JSON: https://qrindex.org/projects/polygon-ecosystem-token/report.json - Official project website: https://polygon.technology/ - Project type: L2 network token - Evaluated network: Polygon PoS (Bor + Heimdall v2) with ERC-20 representation on Ethereum L1 - Evaluated scope: Native gas/staking token on Polygon PoS and ERC-20 token on Ethereum L1. Evaluation covers Polygon PoS production consensus, spend authorization, bridge paths, and L1 token dependency. Polygon zkEVM sunset (2026-07-01) confirmed and excluded from primary production scope. AggLayer uses SP1 zkVM with Plonky3 proving system. - QRI score: 10/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Partial Protection, Quantum-vulnerable consensus, Quantum-vulnerable spend authorization, L1-dependent, Two-way bridge exposure ### Summary POL (ex-MATIC) is the native gas and staking token of Polygon PoS, an Ethereum L2 scaling network. As of June 2026, all production cryptographic mechanisms on Polygon PoS rely entirely on quantum-vulnerable classical cryptography: secp256k1 ECDSA for spend authorization (Bor block production, Heimdall account authentication) and BLS signatures for Heimdall checkpoint consensus. POL also exists as a standard ERC-20 token on Ethereum L1, inheriting Ethereum's full ECDSA vulnerability for L1 transfers and staking. The Polygon zkEVM — which had a partially PQ-safe STARK proof foundation — is confirmed to be sunset on July 1, 2026. AggLayer uses SP1 zkVM with Plonky3 SNARK-based proving with pairing-dependent cryptography. ERC-4337 account abstraction provides an optional theoretical path to PQ signatures via smart-contract wallets, but no Polygon-provided PQ implementation, tooling, or migration guidance exists. Polygon Labs has published no quantum risk assessment, cryptographic inventory, PQ roadmap, migration plan, or quantum-specific incident-response process. The Least Authority audit (2023) predates Heimdall v2 and contains no quantum scope. Score of 10/100 reflects Stage 1 (Quantum Risk Assessed) with no meaningful production protection, capped by the absence of any PQ spend authorization, complete ECC/BLS dependence across all consensus and transaction layers, unrestricted two-way bridge to quantum-vulnerable Ethereum L1, and material long-exposure value-at-risk with no migration path. ### Critical quantum blockers - All production spend authorization on Polygon PoS uses secp256k1 ECDSA exclusively — fully quantum-vulnerable to Shor's algorithm (Cap: 40) - All consensus-critical authentication uses secp256k1 (Bor block producers) and BLS (Heimdall checkpoint signatures) — fully quantum-vulnerable (Cap: 70) - POL exists as an ERC-20 on Ethereum L1 and inherits Ethereum's ECDSA vulnerability for all L1 transfers and staking operations (Cap: 40) - Two-way POL bridge between Ethereum L1 and Polygon PoS allows unrestricted value flow between quantum-vulnerable systems with no PQ restrictions (Cap: 50) - Material long-exposure quantum-vulnerable value exists across all transacted EOAs, staked POL, bridge contracts, and validator keys with no migration, freeze, deprecation, or recovery path (Cap: 55) - No public quantum risk assessment, cryptographic inventory, or mitigation roadmap has been published by Polygon Labs (Readiness & Risk Cap: 10) ### Principal risks - Quantum-enabled theft: All POL on both Polygon PoS and Ethereum L1 is secured by secp256k1 ECDSA. Any account that has sent a transaction has an exposed public key on-chain, vulnerable to offline attack via Shor's algorithm. This includes staked POL, bridge contracts, exchange wallets, and all transacted EOAs. - Consensus compromise: Bor block producers sign with secp256k1 and Heimdall validators sign checkpoints with BLS. A quantum adversary could forge validator signatures to finalize fraudulent checkpoints or produce malicious blocks, potentially enabling double-spend attacks, bridge theft, or chain reorganization. - Bridge vulnerability: The two-way POL bridge between Ethereum L1 and Polygon PoS has no PQ restrictions. A quantum attacker compromising either side could drain bridge contracts. The AggLayer's Plonky3/SP1 proving system relies on pairing-based cryptography that is quantum-vulnerable. - L1 inheritance risk: POL's ERC-20 representation on Ethereum L1 means all L1 staking, governance, and transfer operations are secured by Ethereum's ECDSA, which is quantum-vulnerable. Polygon PoS cannot independently mitigate this exposure. - No migration path: There is no public plan, timeline, governance proposal, or technical specification for migrating Polygon PoS validators, users, or bridge infrastructure to PQ cryptography. In the event of a quantum breakthrough, all value on Polygon PoS would be at immediate risk with no coordinated response mechanism. - Dormant and unmigratable value: Long-dormant POL holdings, abandoned contracts, lost keys, and unresponsive staking delegations have no identified deprecation, freeze, or salvage policy, representing permanently quantum-vulnerable value. - zkEVM sunset eliminates partial PQ protection: The zkEVM's STARK-based proof system offered partial PQ safety for proof generation. Its confirmed sunset on July 1, 2026 removes this limited protection from the ecosystem without a replacement. ## Polkadot (DOT) - Project page: https://qrindex.org/projects/polkadot/ - Complete report JSON: https://qrindex.org/projects/polkadot/report.json - Official project website: https://www.coingecko.com/en/coins/polkadot - Project type: blockchain network - Evaluated network: Polkadot Relay Chain - Evaluated scope: Native asset (DOT) on Polkadot Relay Chain mainnet as of 2026-06-05 - QRI score: 15/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ECC-Only Production, PoS, L1 ### Summary Polkadot has produced one of the most detailed and technically credible post-quantum roadmaps among major L1 blockchains, including a 2025 Web3 Foundation roadmap by Jeff Burdges and a 2026 Draft RFC-0000 for hybrid post-quantum accounts selecting NIST-standardized Falcon (FN-DSA) and Dilithium (ML-DSA). However, as of the June 2026 evaluation date, the Polkadot Relay Chain mainnet uses entirely ECC-based cryptography (sr25519, ed25519, ECDSA) for account signatures, consensus authentication, VRF randomness, and P2P transport. Zero mainnet PQ or hybrid-PQ protection exists. All DOT that has ever been transacted has exposed public keys on-chain, creating a material long-exposure quantum-vulnerable value pool. The RFC explicitly states deployment cannot begin until NIST finalizes Falcon key-derivation standards (estimated 2028). No PQ testnet, prototype code in the official Polkadot SDK, or migration tooling has been publicly identified. The project earns credit for its thorough risk assessment, detailed mitigation design, and NIST-aligned algorithm selection, but these are roadmap artifacts that do not materially protect production users. Polkadot is squarely in Stage 2 (Mitigation/Development) with a QRI Score of 15/100. ### Critical quantum blockers - Active production spend authorization remains entirely ECC-based (sr25519, ed25519, ECDSA) — all DOT balances are quantum-vulnerable to key-recovery attacks (Readiness & Risk Cap: 40). - All Polkadot accounts that have ever broadcast a transaction have exposed their public keys on-chain, creating a material long-exposure quantum-vulnerable value pool with no active migration, freeze, deprecation, or recovery path (Readiness & Risk Cap: 55). - Consensus authentication (BABE/GRANDPA validator signatures, VRF) is entirely ECC-based — a quantum-capable adversary could forge finality signatures and compromise consensus (Readiness & Risk Cap: 70 if isolated; ECC-only spend authorization is the binding cap at 40). ### Principal risks - All DOT circulating supply is protected only by ECC signatures (sr25519, ed25519) that are broken by Shor's algorithm. A sufficiently large quantum computer could recover private keys from exposed public keys and steal any DOT balance. - The VRF used for BABE block-production slot allocation is ECC-based. A quantum adversary with sufficient capability could predict or manipulate validator selection, undermining liveness and potentially enabling long-range attacks. - GRANDPA finality signatures are ECC-based. Quantum forgery of finality votes could cause consensus splits or finality reversions without slashing recourse, as slashing authorization itself relies on the same vulnerable key material. - BEEFY bridge finality proofs to other chains (e.g., Ethereum) rely on ECC validator signatures. Quantum compromise of these signatures could enable fraudulent bridge messages and theft from bridged asset pools. - The FRI-based SNARK migration proof design (100s of KB per proof) has no known production-ready implementation and the roadmap author notes that current STARK implementations 'mostly neglect zero-knowledge' — this is a material implementation risk for the core migration mechanism. - Deployment of Falcon-based accounts is blocked on NIST standardizing deterministic key derivation for FN-DSA, which the RFC projects may not be complete until 2028, creating an indefinite timeline for production PQ account support. - No quantum-specific incident-response process, emergency governance procedure, or validator coordination plan exists for a quantum-emergency scenario. - Dormant, lost, and unresponsive accounts with exposed public keys have no identified salvage, freeze, or burn policy path, creating a permanent quantum-vulnerable value pool even after migration begins. ## Provenance Blockchain (HASH) - Project page: https://qrindex.org/projects/hash-2/ - Complete report JSON: https://qrindex.org/projects/hash-2/report.json - Official project website: https://www.coingecko.com/en/coins/hash-2 - Project type: AI network token - Evaluated network: Provenance Blockchain Mainnet (pio-mainnet-1) - Evaluated scope: Native asset (HASH) and base-layer protocol on Provenance Blockchain mainnet - QRI score: 3.25/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Dependent, Cosmos SDK, IBC-Connected, PoS ### Summary Provenance Blockchain (HASH) is a Cosmos SDK-based Layer-1 Proof-of-Stake blockchain purpose-built for financial services and real-world asset tokenization. As of the evaluation date, the project has no post-quantum or hybrid-PQC protection in production. All critical cryptographic layers—spend authorization (secp256k1 user keys), validator consensus authentication (Ed25519 via CometBFT), and state binding (BLS signatures)—rely entirely on quantum-vulnerable classical elliptic-curve cryptography. The project's whitepaper acknowledges quantum risk through a future research item ('Quantum-Resistant Protocol Evolution') but no public cryptographic inventory, quantum threat model, PQC testnet, migration mechanism, or production PQC code exists. Approximately $500M-$970M in market capitalization (~54B HASH circulating) is secured by quantum-vulnerable cryptography. The QRI Score of 3.25 reflects that quantum risk has been acknowledged at a roadmap level (Stage 1) but no meaningful production protection or migration infrastructure exists. The score is capped by the absence of a public cryptographic inventory with quantum threat model (Readiness & Risk Cap: 10) and is ultimately limited by the near-zero Factor Score across all categories. ### Critical quantum blockers - Active production spend authorization remains entirely secp256k1/EdDSA-only; no PQC or hybrid-PQC transaction path exists on mainnet. - Consensus-critical validator authentication uses quantum-vulnerable Ed25519 signatures via CometBFT. - BLS signatures used for validator signature aggregation are quantum-vulnerable. - No public cryptographic inventory with quantum threat model covering attack assumptions, affected assets, and affected layers. - No migration mechanism, PQC testnet, or production PQC code exists; all ~$500M-$970M in market cap is quantum-exposed. ### Principal risks - QUANTUM-CRITICAL: All user transaction signatures use secp256k1 ECC, which Shor's algorithm can break on a sufficiently powerful quantum computer. Every on-chain transaction exposes the sender's public key, creating a permanent Harvest-Now-Decrypt-Later attack surface. - QUANTUM-CRITICAL: Validator consensus signatures use Ed25519. A quantum adversary compromising validator keys could forge blocks, break consensus finality, execute double-sign attacks, and potentially halt or corrupt the network. - QUANTUM-CRITICAL: BLS signature aggregation for validator votes is quantum-vulnerable. Compromise could enable validator impersonation and consensus manipulation. - QUANTUM-CRITICAL: IBC light-client verification and cross-chain packet authentication rely on the same classical cryptographic assumptions. A quantum break of the host chain's validator signatures could compromise bridged asset security across all IBC-connected chains. - Approximately $500M-$970M in market cap is fully exposed with no migration path, freeze mechanism, or PQC fallback. - No public cryptographic inventory means the full quantum attack surface (all key types, all layers, all exposure windows) is not systematically documented or assessed. - The project has no published quantum-specific incident-response process. While general emergency governance exists, there is no evidence of preparedness for a quantum-enabled consensus or signature-forgery event. ## Pump.fun (PUMP) - Project page: https://qrindex.org/projects/pump-fun/ - Complete report JSON: https://qrindex.org/projects/pump-fun/report.json - Official project website: https://www.coingecko.com/en/coins/pump-fun - Project type: meme token - Evaluated network: Solana - Evaluated scope: SPL token (PUMP) on Solana mainnet, inheriting Solana L1 cryptographic posture; token-specific admin/governance keys evaluated separately per QRI §7.2 Token Inheritance rule - QRI score: 3.5/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Inherits L1 Score [Solana], SPL Token, Meme/Utility Token, Partial Protection (PDA state only) ### Summary Pump.fun (PUMP) is a standard SPL token on Solana with no custom cryptographic or cross-chain dependencies. Per QRI §7.2 Token Inheritance, it shares Solana's base-layer (L1) quantum posture. As of 2026-06-05, Solana has no production post-quantum cryptographic protection: all spend authorization uses Ed25519, consensus uses BLS12-381, and all account addresses are exposed Ed25519 public keys (long-exposure attack surface). Token-specific admin authorities (global authority, fee recipients, withdraw authority, set_creator_authority, fee sharing config admins) are all standard Ed25519 keypairs, creating an additional quantum-critical vulnerability independent of the base layer. Solana's quantum research is well-documented (Falcon-512 identified as leading PQC candidate, Anza migration proof-of-concept at ~400kB/55ms, Blueshift Winternitz Vault opt-in on mainnet, SIMD-0461 Falcon syscall proposed), but none of this constitutes material production protection. The QRI Score of 4 reflects Stage 1 (Quantum Risk Assessed): quantum risk is acknowledged through Solana ecosystem work, but there is no meaningful production protection for PUMP token holders or admin authorities. Approximately $642M in market cap and $74M daily volume remain protected only by quantum-vulnerable Ed25519 signatures. Confidence is Medium: the quantum-critical vulnerabilities are well-established from primary sources (public code, official documentation, Solana research publications), but no Pump.fun-specific quantum assessment or PQC migration work exists. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519-only (inherited from Solana L1). Every PUMP token transfer, buy, sell, and migration instruction is authorized by quantum-vulnerable Ed25519 signatures. - Token admin/authority keys (Global authority FFWtrEQ4B4PKQoVuHYzZq8FabGkVatYzDpEVHsK5rrhF, fee recipients, withdraw authority, admin_set_creator_authority, set_creator_authority, and fee sharing authorities) are all standard Ed25519 keypairs. A quantum adversary recovering these keys could update global configuration, redirect fees, manipulate bonding curves, override creator assignments, drain creator vaults, or compromise migration authority. - Solana L1 consensus authentication uses BLS12-381 signatures (quantum-vulnerable). While consensus compromise is an L1 concern, it directly affects PUMP token finality and settlement. ### Principal risks - All PUMP token transfers, bonding-curve buy/sell operations, and liquidity migrations are authorized by Ed25519 signatures. A cryptographically relevant quantum computer could recover private keys from on-chain public keys and forge spend-authorizing signatures for any PUMP holder account. - Pump.fun Global authority (FFWtrEQ4B4PKQoVuHYzZq8FabGkVatYzDpEVHsK5rrhF) and related admin keys control protocol-wide configuration including fee parameters, fee recipients, creator assignment, and migration logic. Compromise would enable fee redirection, creator override, and potential drainage of creator vaults. - All Solana account addresses are Ed25519 public keys with no hash-based address shielding. Every PUMP holder address that has ever signed a transaction has an exposed, long-exposure public key vulnerable to offline quantum attack with no time constraint. - Solana's Alpenglow consensus uses BLS12-381 signatures. A quantum adversary compromising consensus could disrupt PUMP transaction finality, enable double-spend attacks affecting PUMP settlement, or censor PUMP transactions. - No evidence exists that Pump.fun has adopted Blueshift Winterwallet, Winternitz Vaults, or any PQC mechanism for its admin authorities, treasury, or protocol-controlled accounts. - PUMP token exists in a ~$642M market with ~$74M daily trading volume. All of this value-at-risk is currently unprotected against quantum key-recovery attacks. No migration timeline, freeze mechanism, deprecation policy, or salvage plan exists for PUMP-specific value. - Solana's migration path (Falcon-512, seed-based ZK migration proofs) is contingent on protocol upgrades (SIMD-0296, SIMD-0461, Agave 4.1+) that have not yet reached mainnet. The timeline for these upgrades is uncertain and the PUMP token has no independent migration capability. ## QANplatform (QANX) - Project page: https://qrindex.org/projects/qanplatform/ - Complete report JSON: https://qrindex.org/projects/qanplatform/report.json - Official project website: https://qanplatform.com - Project type: Quantum-resistant L1 smart-contract platform - Evaluated network: Ethereum / BNB Smart Chain (ERC-20/BEP-20 token); QAN TestNet v4 (pre-production L1) - Evaluated scope: QANplatform quantum-resistant L1 smart-contract platform, including the production ERC-20/BEP-20 QANX token (0xAAA9214F675316182Eaa21C85f0Ca99160CC3AAA on Ethereum and BSC) and the pre-production QAN TestNet. Native L1 mainnet has not launched as of the evaluation date. - QRI score: 21/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Testnet Only, PQ Design Audited ### Summary QANplatform has a publicly documented quantum-resistant design centered on its XLINK cross-signer protocol, which binds ECDSA (secp256k1) keys to NIST-standardized ML-DSA-65 (CRYSTALS-Dilithium, FIPS 204) post-quantum keys. The XLINK library and QVM have been independently audited by Hacken (November 2025 and July 2025 respectively), with most findings resolved. However, as of 2026-06-01 the QAN L1 mainnet has not launched: the only production asset is the QANX ERC-20/BEP-20 token on Ethereum and BSC, secured entirely by classical ECDSA with no PQ protection. The core L1 protocol source code remains closed in a private GitLab, and a May 2026 strategic update announced a controlled architectural rebase onto Ethereum's official implementation, adding design uncertainty. The project earns strong credit for its NIST-aligned algorithm choice and audited PQ design (Category 5: 14.25/20) but receives minimal scores in production protection (0/35) and migration status (1.5/25) because no production PQ-secure system exists. Both the Stage 2 cap and the Readiness & Risk cap for testnet-only / production-ECC-only set the ceiling at 40, and the conservative factor score of 21 places the final QRI Score at 21/100. ### Critical quantum blockers - No production L1 mainnet: the QAN L1 mainnet has not launched. All production QANX value (~$24M market cap) resides on the ERC-20/BEP-20 token on Ethereum and BSC, secured entirely by classical ECDSA (secp256k1) with no PQ-protected production transaction path. - QANX token exists as an ERC-20/BEP-20 on quantum-vulnerable Ethereum and BSC host chains; production spend authorization is entirely ECC-only. The 2022 bridge hack demonstrated the classical ECDSA exposure of the project's bridge infrastructure. - Core L1 protocol source code is not publicly available, preventing independent verification of quantum-critical claims beyond the audited XLINK/QVM libraries. - Consensus-layer (validator authentication) quantum resistance is undocumented and unverified for the planned PoS MainNet Beta; PoR is described as experimental and the quantum properties of its VRF/randomness components are not specified. ### Principal risks - All production QANX value (~$24M market cap) is secured by classical ECDSA on Ethereum and BSC; any holder address that has sent a transaction has an exposed public key vulnerable to quantum key-recovery attacks. No PQ-protected production path exists. - No mainnet launch date has been announced. The Integration Audit is still in progress and the May 2026 architectural rebase to Ethereum's official implementation may extend timelines and reduce the applicability of existing component audits to the eventual production system. - Core L1 protocol source code is closed-source in a private GitLab, preventing independent code-level verification of quantum-critical claims. Public evidence is limited to audits of the XLINK and QVM libraries, testnet explorer data, and documentation. - The consensus mechanism for MainNet Beta will be Proof-of-Stake rather than the originally planned Proof-of-Randomness. The quantum resistance of validator authentication signatures in the PoS design is not publicly specified. - When the native L1 mainnet launches, the ERC-20/BEP-20 QANX token will need to be migrated via a bridge mechanism. The bridge design, security model, and quantum resistance of the future cross-chain bridge are not yet specified. The 2022 bridge hack (Profanity vanity-address vulnerability) demonstrates historical exposure of the project's bridge administration to classical ECDSA weaknesses. - A May 2026 secondary-source claim (Tangem) that QANplatform is 'quantum-resistant at mainnet today' conflicts with the project's own roadmap (TestNet v4, MainNet pending Integration Audit) and with another secondary source (LBank, January 2026). This disagreement is consistent with marketing overstatement rather than production mainnet launch; nonetheless, the project should be re-evaluated once an independent mainnet-launch announcement is verified. ## Quant (QNT) - Project page: https://qrindex.org/projects/quant-network/ - Complete report JSON: https://qrindex.org/projects/quant-network/report.json - Official project website: https://www.quant.network - Project type: tokenized asset - Evaluated network: Ethereum - Evaluated scope: QNT token as ERC-20 on Ethereum mainnet (0x4a220E6096B25EADb88358cb44068A3248254675), with token-specific evaluation of treasury/admin keys and Overledger gateway cryptographic dependencies. Base-layer spend authorization, account exposure, and state integrity inherit Ethereum L1 risk profile per QRI Token Inheritance rule (Section 7.2). - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance: Ethereum L1, ECC-Only, No Cryptographic Inventory, No Migration Path, ERC-20 Standard Token, Roadmap Only (Unverified) ### Summary Quant (QNT) is a standard ERC-20 token on Ethereum mainnet with no independent cryptographic layers, no post-quantum protection, and no published quantum risk assessment. Per the QRI Token Inheritance rule (Section 7.2), QNT inherits Ethereum's entirely ECDSA-based quantum risk profile for spend authorization, account exposure, and state integrity. The token contract itself has no ownership controls and cannot be upgraded. Token-specific treasury contracts use ECDSA operator addresses with no quantum-resistant alternatives. A reported Naoris Protocol partnership for Overledger quantum security could not be verified from primary sources and would not protect the QNT token itself. The recently launched Fusion Rollup (June 2026) contains no documented quantum-resistant features. With approximately $900M in quantum-vulnerable value and no migration path, QNT scores 0/100. The project has not published a cryptographic inventory, a quantum threat model, a migration roadmap, or any evidence of post-quantum development for the QNT token. All five scoring categories earn zero points. The QRI Score is capped at 10 by the absence of a public cryptographic inventory (Readiness & Risk Cap). Holders should monitor Ethereum's quantum migration progress, as QNT cannot independently migrate. ### Critical quantum blockers - No public cryptographic inventory: Quant has not published an inventory of quantum-vulnerable cryptographic mechanisms for QNT, Overledger, treasury, or Fusion Rollup. (Readiness & Risk Cap: 10) - Active production spend authorization remains entirely ECDSA-only via Ethereum L1 inheritance. All QNT transfers, approvals, and treasury operations rely on Ethereum's secp256k1 ECDSA, which is vulnerable to quantum attack via Shor's algorithm. (Readiness & Risk Cap: 40) - Material long-exposure quantum-vulnerable value exists: approximately $900M market cap (~12M QNT circulating) with all transactions visible on-chain and EOAs that have sent transactions exposing public keys. No migration, freeze, deprecation, or recovery path exists. (Readiness & Risk Cap: 55) - Treasury proxy contracts rely on ECDSA operator addresses. If these keys are long-exposure (have sent transactions), they represent a direct quantum-attack surface for treasury-controlled QNT. ### Principal risks - Complete quantum vulnerability: All QNT spend authorization depends on Ethereum's ECDSA (secp256k1). A cryptographically relevant quantum computer running Shor's algorithm could derive private keys from exposed public keys of any Ethereum EOA that has sent a transaction. - Long-exposure attack surface: QNT has been actively traded since 2018. Millions of transactions have exposed sender public keys on-chain. These public keys are permanently visible and can be attacked offline with no time constraint once quantum capability matures. - No migration path: As a standard ERC-20 token with no admin controls, QNT cannot independently migrate to quantum-resistant signatures. Migration depends entirely on Ethereum's upgrade to post-quantum cryptography, which is still in early research/roadmap stages. - Treasury key exposure: Treasury proxy contracts use operator addresses that sign ECDSA transactions. If these operator addresses have sent on-chain transactions, their public keys are exposed and vulnerable to future quantum key recovery. The multisig configuration and key management practices are not publicly documented. - Harvest now, decrypt later: All historical QNT transactions with exposed ECDSA public keys are permanently recorded on Ethereum. Attackers can collect this data today and decrypt it once quantum capability matures, potentially compromising any address that has ever sent a transaction. - Fusion Rollup quantum posture unaddressed: The newly launched Fusion Rollup (June 2, 2026) uses QNT as its native token but contains no quantum-resistant features. This could create additional quantum-vulnerable value if significant QNT migrates to the rollup. - Smart contract exploit precedent: An EIP-7702 delegation exploit drained ~1,974 QNT from a pool in April 2026, demonstrating that QNT pool admin keys can be compromised through non-quantum vectors. - Unverifiable partnership claim: The reported Naoris Protocol partnership for quantum-resistant Overledger features cannot be verified from primary sources. Even if real, it does not address QNT token vulnerability on Ethereum. - No governance mechanism for emergency quantum response: Quant has no published process for freezing, migrating, or recovering QNT in the event of a quantum breakthrough. The decentralized token contract limits emergency response options. ## Quantum Resistant Ledger (QRL) - Project page: https://qrindex.org/projects/quantum-resistant-ledger/ - Complete report JSON: https://qrindex.org/projects/quantum-resistant-ledger/report.json - Official project website: https://www.theqrl.org - Project type: Post-quantum L1 chain - Evaluated network: QRL mainnet (native Proof-of-Work chain) - Evaluated scope: Current production QRL Layer 1 mainnet and native QRL asset as of 2026-08-20, including transaction authorization, address exposure, consensus, state integrity, P2P, wallet/custody, migration, governance, and assurance. The legacy Ethereum ERC-20 token, external wrappers or bridges, and future Project Zond are excluded from production scope and considered only as caveats or roadmap evidence. - QRI score: 98.5/100 - Readiness stage: 4 (Migration Complete / Quantum-Ready) - Evidence confidence: Medium - Evaluation date: 2026-08-20 - Review status: draft - User urgency: [No Action Needed] for native QRL mainnet holders; [Monitor for Updates] regarding assurance documentation and future Project Zond - Readiness tags: PQ-Native, PQ-Resistant, Migration Complete by Design, Hash-Based Signatures (XMSS), PoW L1 ### Summary QRL mainnet is a post-quantum-native Proof-of-Work chain whose native addresses and transactions use mandatory XMSS hash-based signatures. Documentation, protocol definitions, source code, and mainnet observations support that no classical native ownership namespace or fallback transaction path exists. Native-asset migration is therefore complete by design, including for critical on-chain wallets. Proof-of-Work does not introduce validator-signature authentication, and no current quantum-vulnerable bridge, proof system, or other critical dependency was identified in the supplied record. Overall confidence is Medium because production XMSS audit coverage is old, the recent audit concerns future ML-DSA libraries, and detailed state-integrity and P2P documentation was not supplied. These gaps remain assurance limitations rather than identified current quantum-critical blockers. ### Critical quantum blockers No critical quantum blockers are recorded. ### Principal risks - XMSS signing requires reliable OTS-index state management; signer-state reuse or rollback can compromise an affected wallet even though it does not create a classical quantum-vulnerable fallback. - Detailed documentation of current state-integrity, supply-binding, data-availability, and P2P mechanisms is limited, so these layers merit additional public review despite no identified quantum-vulnerable dependency. - Any production deployment of Project Zond should be reassessed for PoS validator authentication, EVM account ownership, state commitments, bridges, and migration of existing XMSS-controlled accounts. ## QuantumCoin (Q) - Project page: https://qrindex.org/projects/quantumcoin/ - Complete report JSON: https://qrindex.org/projects/quantumcoin/report.json - Official project website: https://quantumcoin.org - Project type: Post-quantum PoS smart-contract L1 - Evaluated network: QuantumCoin Mainnet (NetworkID 123123) - Evaluated scope: Native asset (Q) on QuantumCoin L1 mainnet, launched 2023-12-31, plus multi-fork migration from Bitcoin, Ethereum, Dogecoin, and DogeP tokens - QRI score: 55/100 - Readiness stage: 3 (Migration Live) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Hybrid-PQ, Partial Protection ### Summary QuantumCoin (Q) is a hybrid-PQ Layer-1 smart-contract blockchain launched on mainnet December 31, 2023. The native asset uses mandatory hybrid signatures (ML-DSA FIPS 204 + SLH-DSA FIPS 205 + Ed25519) for all transaction and consensus authentication, and hybrid X25519 + ML-KEM-768 (FIPS 203) for all P2P node sessions. Addresses are 32 bytes, providing additional collision resistance. Because the chain launched with hybrid-PQC from genesis and has no classical-native ownership namespace, native-asset migration from ECC is complete by design. However, the multi-fork migration model from Bitcoin, Ethereum, and Dogecoin creates a critical quantum vulnerability: unclaimed balances on legacy chains remain exposed to quantum attacks with no deprecation, freeze, or burn policy, and the claim process itself requires classical Ethereum signatures. The final QRI score is capped at 55 due to material long-exposure quantum-vulnerable value with no mitigation path. No independent cryptographic audit exists, which limits confidence to Medium. ### Critical quantum blockers - Material long-exposure quantum-vulnerable value exists in unclaimed multi-fork balances on legacy chains (Bitcoin, Ethereum, Dogecoin) with no deprecation, freeze, burn, or policy path. Invokes Readiness & Risk Cap at 55. - Migration claim process requires classical Ethereum signatures, creating a quantum-vulnerable path for unmigrated value during the claim process. ### Principal risks - Unclaimed multi-fork balances on BTC/ETH/DOGE chains are quantum-vulnerable with no deprecation, freeze, or burn policy. A quantum attacker could steal these funds if they can derive private keys from public keys before users claim them. - Migration claim process uses classical Ethereum signatures, exposing users to quantum attacks during the claim window. Users must sign with their Ethereum wallet to claim Q tokens. - No independent audit exists for the hybrid PQC implementation, CIRCL fork, consensus modifications, or P2P protocol. A subtle implementation flaw in signature verification, KEM derivation, or consensus message authentication could create a quantum-exploitable path despite correct algorithm selection. - The project's modified EVM with 32-byte addresses and Solidity 7.6 compatibility has not been independently reviewed for state-integrity or address-collision edge cases under adversarial conditions. - No documented deprecation timeline or enforcement mechanism for unclaimed multi-fork balances. The cut-off time mentioned in the snapshot portal is unspecified. - Low market capitalization and limited exchange support may affect liquidity and institutional custody availability, but do not directly impact quantum-attack readiness. ## Qubic (QUBIC) - Project page: https://qrindex.org/projects/qubic/ - Complete report JSON: https://qrindex.org/projects/qubic/report.json - Official project website: https://qubic.org - Project type: Feeless L1 smart-contract and decentralized-compute platform - Evaluated network: mainnet - Evaluated scope: Qubic L1 native asset (QUBIC) and core protocol - QRI score: 5.97/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, ECC-Only, Quantum-Vulnerable ### Summary 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. ### 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. ### Principal 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. ## Qubitcoin (QTC) - Project page: https://qrindex.org/projects/qubitcoin-2/ - Complete report JSON: https://qrindex.org/projects/qubitcoin-2/report.json - Official project website: https://superquantum.io/qubitcoin - Project type: blockchain network - Evaluated network: mainnet - Evaluated scope: Native asset (QTC) on Qubitcoin Layer-1 blockchain network, production mainnet since October 2024 - QRI score: 5/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-07 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Classical ECC, Quantum-Vulnerable ### Summary Qubitcoin (QTC) scores 5/100 on the Quantum Readiness Index, placing it at Stage 0 (Unassessed / No Evidence). The project is a Bitcoin Core fork whose 'quantum' branding refers exclusively to its Quantum Proof of Work (qPoW) consensus mechanism—miners simulate 16-qubit quantum circuits on GPUs as part of the block hashing process. This provides zero cryptographic protection against quantum attacks on transaction signatures. All spend authorization relies on classical ECDSA/secp256k1, inherited unchanged from Bitcoin and confirmed by the official wallet code (deterministic ECDSA per RFC 6979). The project has published no cryptographic inventory, no quantum threat model, no PQC migration plan, and has undergone no independent security audit. The state-integrity layer (SHA256 Merkle commitments) is quantum-safe, earning partial credit in Production Cryptographic Protection (4.04/35), but the critical spend-authorization layer is entirely quantum-vulnerable. Approximately 100% of on-chain value is held in ECDSA-secured addresses with no migration path. Secondary claims that Qubitcoin implements post-quantum transaction validation are contradicted by all primary sources and stem from confusion with a separate project (QubitCoin/QBTC by qubitcoin-finance, which does use ML-DSA-65 Dilithium). The QRI Score is capped at 5 by the Stage Cap for Stage 0. ### Critical quantum blockers - All transaction spend authorization uses classical ECDSA/secp256k1 with no PQC or hybrid-PQC alternative. A quantum attacker running Shor's algorithm can recover private keys from exposed public keys and steal all funds. - No public cryptographic inventory or quantum threat model has been published by the project. The quantum vulnerability of ECDSA signatures is not acknowledged in any official documentation. - No PQC migration roadmap, prototype, testnet, or design proposal exists. There is no path for users to protect funds from quantum key-recovery attacks. - All account addresses follow standard Bitcoin address types (P2PKH, P2WPKH, P2TR, Bech32, SegWit). Public keys are exposed on-spend for P2PKH/P2WPKH and at-rest for P2PK outputs and reused addresses. Long-exposure quantum-vulnerable value exists with no mitigation, freeze, deprecation, or migration mechanism. ### Principal risks - QUANTUM-CRITICAL: All transaction signatures use ECDSA/secp256k1. A cryptographically relevant quantum computer (CRQC) running Shor's algorithm can recover private keys from public keys exposed during spending (P2PKH, P2WPKH) or already visible on-chain (P2PK outputs, reused addresses). This enables complete theft of all funds in quantum-vulnerable addresses. - QUANTUM-CRITICAL: Public keys are exposed on-spend for all standard address types, creating a short-exposure attack window during transaction broadcast. For P2PK outputs and reused addresses, public keys are already on-chain, enabling offline at-rest attacks with no time constraint. - QUANTUM-CRITICAL: No PQC migration path exists. Users cannot opt in to quantum-safe signatures, create PQ addresses, or migrate funds to quantum-resistant outputs. If a CRQC emerges, all QTC holders are defenseless. - QUANTUM-CRITICAL UNCERTAINTY: The project has not published a cryptographic inventory or quantum threat model. The quantum vulnerability of ECDSA signatures is not acknowledged in any official documentation. The project's 'quantum' branding may mislead users into believing their funds are quantum-protected when they are not. - ASSURANCE: No independent cryptographic audit has been performed. The codebase (forked from Bitcoin Core with qPoW modifications) has not been reviewed for quantum-specific vulnerabilities. - OPERATIONAL: The project conflates quantum computing simulation (useful computation for PoW) with quantum cryptographic security. Users may incorrectly assume that qPoW provides protection against quantum attacks on their funds. - CONFUSION RISK: A separate project named QubitCoin (QBTC, qubitcoin-finance) uses actual PQC (ML-DSA-65/Dilithium). Exchanges, data aggregators, and users may confuse QTC with QBTC, leading to incorrect quantum-safety assumptions. ## Quranium (QRN) - Project page: https://qrindex.org/projects/quranium/ - Complete report JSON: https://qrindex.org/projects/quranium/report.json - Official project website: https://www.quranium.org/ - Project type: blockchain network - Evaluated network: Quranium L1 - Evaluated scope: Native asset and Layer 1 protocol - QRI score: 25/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Very Low - Evaluation date: 2026-06-18 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Prototype, PQ-Native Claim (Unverifiable), Roadmap Only ### Summary Quranium claims to be a PQ-native Layer 1 blockchain using SLH-DSA (SPHINCS+) for transaction signatures with EVM compatibility. A verifiable public testnet exists with active transaction activity, and developer tooling (QSafe wallet documentation, Hardhat deploy scripts) demonstrates SLH-DSA signing capabilities. However, the project's mainnet status is unverifiable and contradicted by its own roadmap, press releases, and CoinMarketCap data (0 circulating supply). Core node software, consensus mechanisms, and protocol specifications remain closed-source. The claimed CertiK audit has no publicly accessible report. EVM compatibility raises unresolved questions about classical fallback paths. The project is currently at Stage 2 (Mitigation / Development) with a score of 25, reflecting the verifiable testnet prototype but severe quantum-critical uncertainty regarding production enforcement. ### Critical quantum blockers - No verifiable public mainnet or open-source node software to confirm SLH-DSA enforcement or absence of classical fallback paths. - Unverifiable CertiK audit claims; no public audit report available for core protocol or PQC integration. - EVM compatibility introduces potential classical ECC paths (e.g., ecrecover) that are not documented as disabled or overridden. ### Principal risks - Closed-source core protocol prevents independent verification of SLH-DSA enforcement and absence of classical ECC fallback paths. - EVM compatibility may expose quantum-vulnerable smart contract interactions if classical opcodes like ecrecover are not disabled. - Unverifiable audit claims create false assurance for institutional investors and users. - Contradictory mainnet launch announcements across different sources suggest unclear production readiness. - No verifiable mainnet explorer or transaction telemetry exists to confirm PQ signatures are mandatory on all spend paths. ## QuStream (QST) - Project page: https://qrindex.org/projects/qustream/ - Complete report JSON: https://qrindex.org/projects/qustream/report.json - Official project website: https://qustream.com - Project type: Quantum-safe encryption and blockchain network - Evaluated network: Solana (current); native QuStream L1 (roadmap only) - Evaluated scope: QST token (Solana SPL) and planned native QuStream L1 blockchain ecosystem - QRI score: 6.25/100 - Readiness stage: 1 (Unspecified) - Evidence confidence: Low - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Quantum Risk Assessed, Bespoke Cryptography ### Summary QuStream is a pre-mainnet quantum-safe blockchain project whose QST token currently operates as an SPL token on Solana, inheriting Solana's quantum-vulnerable Ed25519 spend authorization. The project has published research describing a proprietary Operational Perfect Secrecy (OPS) / Symmetric Key Infrastructure (SKI) design with information-theoretic security claims, and maintains a devnet encryption manager. However, as of 2026-06-01, the native L1 blockchain—planned for Q1 2026 launch—remains 'In Progress' on the official roadmap with no mainnet genesis, explorer, or verifiable transaction history. The published cryptographic design focuses on symmetric encryption for data-in-transit and does not specify a standardized or broadly reviewed post-quantum digital signature algorithm for blockchain spend authorization or consensus. The Halborn audit covers only the Solana staking contract and is scope-mismatched for quantum-critical claims. All quantum-safe protection for blockchain layers remains roadmap/design only, with zero production migration coverage. The QRI Score of 6.25 reflects the project's Stage 1 (Quantum Risk Assessed) status: meaningful quantum risk assessment and research exist, but no production PQC protection is live, and the current production scope is entirely quantum-vulnerable. ### Critical quantum blockers - QST token production spend authorization relies entirely on Solana's Ed25519 signatures, which are quantum-vulnerable. No PQ/hybrid-PQC protection exists for the current production scope. - The native QuStream L1 blockchain—claimed to provide quantum-safe encryption and consensus—has not launched on mainnet. The roadmap shows native infrastructure as 'In Progress' with no mainnet genesis, explorer, or independently verifiable transaction history as of 2026-06-01. - No standardized, standards-track, or broadly independently reviewed post-quantum digital signature algorithm has been specified for blockchain spend authorization or consensus on the planned native chain. The published OPS/SKI design focuses on symmetric encryption for data-in-transit and does not address the non-repudiation and public-verifiability requirements of blockchain transaction signing. ### Principal risks - QST token holders are fully exposed to quantum key-recovery attacks via Solana's Ed25519 signatures for all current production transactions, staking, and custody operations. - The planned 1:1 migration from Solana to the native chain relies on a bridge/snapshot mechanism whose design and quantum security properties are unpublished, creating uncertainty about migration-path integrity under quantum threat models. - The proprietary OPS/SKI cryptographic design has not been subjected to broad independent cryptographic review for blockchain-specific use cases (digital signatures, consensus, public verifiability). The security claims rest primarily on IACR ePrint preprints and a single peer-reviewed conference paper, with no NIST or standards-body evaluation. - No public source code exists for the core blockchain protocol, consensus mechanism, or quantum-safe encryption implementation. Verification of quantum-security claims is impossible from public artifacts alone. - If the native L1 launch is delayed or the migration mechanism proves vulnerable, all QST value remains indefinitely exposed on Solana with no fallback protection. - The project's emphasis on symmetric-key encryption (OTP/Q-Blocks) for data-in-transit does not natively solve the public-verifiability and non-repudiation requirements of blockchain transaction authorization. The mechanism for quantum-safe digital signatures on the planned native chain remains unspecified. ## Rain (RAIN) - Project page: https://qrindex.org/projects/rain/ - Complete report JSON: https://qrindex.org/projects/rain/report.json - Official project website: https://rain.one - Project type: DeFi prediction-market token - Evaluated network: Arbitrum One - Evaluated scope: ERC-20 governance token on Arbitrum L2; inherits host-chain cryptographic posture. Evaluation covers token-specific admin/governance keys and inherited Arbitrum/Ethereum ECDSA exposure. - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Inherits L1 Score [Arbitrum], ECC-Only ### Summary Rain (RAIN) is a standard ERC-20 governance token deployed on Arbitrum One, a Layer-2 optimistic rollup on Ethereum. The token uses a UUPS-upgradeable proxy pattern with single-owner admin controls for minting, oracle configuration, and proxy upgrades. Per QRI Section 7.2 (Token Inheritance), RAIN inherits the full quantum vulnerability profile of its host chain: all transaction authorization, account ownership, and admin key operations rely on ECDSA/secp256k1 signatures verified by the Arbitrum/Ethereum execution layer. The project has published no cryptographic inventory, quantum threat model, PQC migration roadmap, or post-quantum design work of any kind. The Hacken audit (August 2025) confirms standard ERC-20 compliance and classical smart contract security but contains no quantum-specific review. Account abstraction via ERC-4337 (Alchemy smart accounts) provides gas sponsorship but does not alter the underlying ECDSA signature scheme. Arbitrum itself is independently assessed as Migration Stage 0 (Unaware) with QRI 26/100. The RAIN token has zero post-quantum protection at any layer and zero documented quantum readiness work. ### Critical quantum blockers - All transaction authorization and token admin functions rely on ECDSA/secp256k1 inherited from Arbitrum/Ethereum — no PQC or hybrid-PQC protection at any layer. - No public cryptographic inventory or quantum threat model has been published by the project. - No PQC migration roadmap, design, prototype, or testnet exists. ### Principal risks - All RAIN token holdings and admin keys are exposed to future quantum key-recovery attacks via ECDSA/secp256k1 — long-exposure risk for any address that has sent a transaction (public key revealed on-chain). - Single-owner admin key controls daily minting ($50,000 USD equivalent), oracle configuration, treasury updates, and proxy upgrades — a quantum-compromised admin key could enable unlimited inflation and contract takeover. - Cross-chain bridge dependencies (Ethereum, BNB Chain, Base) introduce additional quantum-vulnerable settlement paths. - No migration mechanism exists to protect value in the event of a quantum computing breakthrough — no freeze, deprecation, burn, or recovery policy is documented. - Upgradeable proxy pattern means contract logic can be changed at any time by the owner, but this does not address the underlying ECDSA vulnerability of the owner key itself. ## Render (RENDER) - Project page: https://qrindex.org/projects/render-token/ - Complete report JSON: https://qrindex.org/projects/render-token/report.json - Official project website: https://www.coingecko.com/en/coins/render-token - Project type: AI network token - Evaluated network: Solana - Evaluated scope: SPL Token on Solana (and legacy ERC-20 on Ethereum) - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance, Roadmap Only, Quantum Risk Assessed ### Summary Render (RENDER) is a standard SPL token on Solana, migrated from Ethereum (RNDR) in November 2023 via a Wormhole-powered one-way upgrade bridge. Under the QRI Token Inheritance rule (Section 7.2), RENDER inherits Solana's cryptographic posture: all spend authorization uses Ed25519 elliptic-curve signatures, which are vulnerable to Shor's algorithm. The Render Network Foundation has published no cryptographic inventory, no quantum risk assessment, and no post-quantum migration plan. Governance multisigs controlling node emissions and burns use classical Ed25519. The Wormhole bridge dependency introduces additional quantum-vulnerable Guardian signatures (ECDSA secp256k1). Solana L1 has active quantum research (Falcon implementations on GitHub, Blueshift Winternitz Vault, Jump Crypto migration analysis) but nothing in production. RENDER's QRI Score of 1.00 reflects near-total absence of quantum readiness: ~$1B+ in market cap is entirely secured by quantum-vulnerable cryptography with no protection, no migration path, and no assessment at the token-project level. ### Critical quantum blockers - Active production spend authorization remains entirely Ed25519 (ECC) on Solana — all RENDER transfers and governance actions are quantum-vulnerable. - No public cryptographic inventory or quantum risk assessment published by the Render Network Foundation. - Governance multisigs (Node Emissions ATA: DUAv3AyTzJhDuPexKTJSj82wgb7X6AghjifbVC8NYQCd; Burn ATA: GqE7wcwRw86xxMz4pNq5cV3BkM64h3bvajQRQbigYqTX) use classical Ed25519 signatures. - Wormhole upgrade bridge Guardian network (19 Guardians, 13-of-19 threshold) uses ECDSA secp256k1 signatures — quantum-vulnerable bridge dependency for legacy RNDR-to-RENDER migration path. - Material long-exposure quantum-vulnerable value (~$1B+ market cap) exists with no migration, freeze, deprecation, burn, recovery, or policy path at the token level. ### Principal risks - All RENDER spend authorization depends on Solana's Ed25519 signatures — a quantum attacker recovering private keys from on-chain public keys could steal any RENDER balance. - Governance takeover risk: token-weighted voting on Nation.io uses classical signatures. A quantum attacker could forge votes or compromise the Foundation's multisig keys to push malicious protocol upgrades. - Wormhole Guardian compromise: the 19-Guardian network uses ECDSA secp256k1. A quantum attacker compromising 13 of 19 Guardians could forge cross-chain messages affecting the integrity of locked/burned RNDR during upgrades. - Long-exposure public keys: every Solana address that has signed a transaction has exposed its Ed25519 public key on-chain. Over 60% of funded Solana addresses have made at least one outgoing transaction (per Solana Beach data cited in secondary analysis), meaning most RENDER holders have exposed public keys vulnerable to offline quantum attack. - Legacy RNDR on Ethereum remains tradable on some exchanges with exposed ECDSA public keys — bifurcated exposure across two quantum-vulnerable chains. - No freeze, deprecation, burn, or emergency migration mechanism exists at the token level to address quantum-vulnerable value if a cryptographically relevant quantum computer emerges. - Dormant unmigrated RNDR on Ethereum and Polygon represents quantum-vulnerable value with no enforced upgrade deadline and no policy mechanism to address it. ## Ripple USD (RLUSD) - Project page: https://qrindex.org/projects/ripple-usd/ - Complete report JSON: https://qrindex.org/projects/ripple-usd/report.json - Official project website: https://www.coingecko.com/en/coins/ripple-usd - Project type: stablecoin - Evaluated network: XRPL, Ethereum, Base (via Wormhole NTT) - Evaluated scope: RLUSD stablecoin token across all production deployments (XRPL native issuance, Ethereum ERC-20, L2s via Wormhole NTT) - QRI score: 7/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Token Inherits Host-Chain Risk, PQ-Recoverable, Partial Protection ### Summary Ripple USD (RLUSD) is a fiat-backed stablecoin with ~$1.75B circulating supply, natively issued on XRP Ledger and Ethereum, with recent expansion to L2s (Base, Optimism) via Wormhole NTT. The token is a standard ERC-20 / XRPL issued currency with no custom cryptographic primitives — it inherits the classical ECC-based security of all its host chains. Ripple has published a substantive 4-phase PQ roadmap for the XRP Ledger (targeting 2028) with Phase 2 ML-DSA testing on AlphaNet underway in H1 2026, but this covers only the base ledger, not RLUSD specifically. On Ethereum, admin control relies on classical ECDSA multisigs (7-of-7 for critical roles, 2-of-32 for operational roles). The Wormhole NTT bridge dependency introduces another classical-signature vulnerability surface. RLUSD's centralized freeze and clawback capabilities provide a meaningful quantum-recoverability path — the issuer could freeze compromised accounts and claw back tokens in a Q-Day scenario — but this is recoverability, not resistance. With 0% of value-at-risk protected by PQC or hybrid-PQC and no token-specific quantum mitigation, RLUSD scores 7/100 (Stage 1: Quantum Risk Assessed). Users should monitor Ripple's XRPL PQ roadmap and any future token-specific migration announcements. ### Critical quantum blockers - All production spend authorization remains entirely classical (ECDSA on Ethereum, Ed25519/secp256k1 on XRPL) with no production PQC or hybrid-PQC protection. - RLUSD Ethereum admin multisigs (UPGRADER, DEFAULT_ADMIN roles use 7-of-7 thresholds; MINTER, PAUSER, CLAWBACKER use 2-of-32) use classical ECDSA; compromise via quantum key recovery could allow unlimited minting, contract upgrades, and fund clawback. - ~82% of RLUSD supply sits on Ethereum, which has no published PQC migration roadmap or production PQC support. - Wormhole NTT bridge uses classical Guardian signatures (ECDSA); cross-chain transfers to L2s and XRPL EVM Sidechain are quantum-vulnerable at the bridge verification layer. - No RLUSD-specific quantum migration plan exists for Ethereum deployment or Wormhole bridge dependency. ### Principal risks - Host-chain dependency risk: RLUSD's quantum security is entirely dependent on XRPL and Ethereum base-layer migration timelines. Neither chain has production PQC today. - Admin key compromise risk: The 7-of-7 multisig controlling Ethereum contract upgrades and 2-of-32 multisigs for minting/burning/clawback use classical ECDSA. If threshold signer keys are compromised by a quantum attacker, the entire token contract can be upgraded maliciously or unlimited tokens minted. - Bridge risk: Wormhole NTT Guardian signatures (13-of-19 classical ECDSA) secure cross-chain RLUSD transfers to L2s. A quantum break of the Guardian set could enable theft of bridged RLUSD value. - Long-exposure risk: ERC-2612 permit signatures, transacted EOAs, and XRPL accounts with visible public keys create 'harvest now, decrypt later' exposure for long-held RLUSD positions. - Value concentration risk: ~82% of RLUSD supply is on Ethereum where no protocol-native key rotation exists, making large-value migration operationally harder than on XRPL. - No token-specific migration plan: Even if XRPL achieves PQ readiness by 2028, the Ethereum deployment (~$1.4B) and Wormhole-dependent L2 deployments have no published quantum migration path from Ripple. ## Shiba Inu (SHIB) - Project page: https://qrindex.org/projects/shiba-inu/ - Complete report JSON: https://qrindex.org/projects/shiba-inu/report.json - Official project website: https://www.coingecko.com/en/coins/shiba-inu - Project type: meme token - Evaluated network: Ethereum (ERC-20) / Shibarium L2 - Evaluated scope: SHIB ERC-20 token on Ethereum mainnet, including Shibarium L2 bridge dependency and ecosystem governance - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Very Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Roadmap Only, Token Inheritance: Ethereum L1, ECC-Only Spend Authorization, Quantum-Vulnerable Bridge, No Cryptographic Inventory ### Summary Shiba Inu (SHIB) is a standard, immutable ERC-20 token on Ethereum with no custom cryptography, admin keys, or upgrade authority in the token contract. Under QRI Section 7.2 (Token Inheritance), SHIB inherently shares Ethereum L1's quantum-vulnerable ECDSA/secp256k1 security model for spend authorization and state integrity. The Shiba Inu ecosystem extends to Shibarium, a Polygon Edge/Plasma-fork L2 sidechain using classical ECDSA for consensus and bridge validation — both quantum-vulnerable. The Shibarium bridge suffered a major classical exploit in September 2025, underscoring the fragility of its signature-based security. While the ecosystem has acknowledged quantum risk in official publications and announced a Zama FHE partnership (privacy/confidentiality, not spend-authorization replacement), no formal cryptographic inventory, quantum threat model, PQ migration plan, or production PQ protection exists. The project scores 0 on all five QRI categories. Stage 0 cap (5) and Readiness & Risk caps (10 for no cryptographic inventory, 50 for vulnerable two-way bridge, 40 for ECC-only spend authorization) all exceed the Factor Score of 0, yielding a QRI Score of 0. The ecosystem has shown awareness of quantum risk through official publications, but this awareness does not constitute a formal risk assessment and provides no production protection. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published by the project team (Stage 0 cap: 5) - All SHIB spend authorization relies entirely on Ethereum L1 ECDSA/secp256k1 signatures — fully quantum-vulnerable with long-exposure public keys for all transacted EOAs - Shibarium L2 consensus and validator authentication use classical ECDSA signatures with no documented PQ mitigations - Shibarium bridge relies on classical validator multisig/checkpoint signatures; a quantum adversary could forge bridge exits to drain locked L1 assets (two-way bridge cap: 50) - Shibarium bridge critical contracts upgradeable by EOA with no delay, creating additional quantum-era governance risk - No migration mechanism, PQ wallet support, or quantum-safe transaction path exists for SHIB holders ### Principal risks - SHIB token balances (~$X billion market cap) are secured exclusively by Ethereum ECDSA/secp256k1 signatures. A quantum computer capable of breaking secp256k1 could derive private keys from the ~1.58M+ EOAs that have transacted SHIB, enabling theft of all exposed balances with no time constraint (long-exposure attack window). - Shibarium L2 validators use classical ECDSA signatures for consensus. Quantum compromise of validator keys could finalize fraudulent state transitions, including malicious bridge exits that drain all locked L1 assets. - The Shibarium bridge (Plasma/PoS bridge) relies on 2/3+1 validator checkpoint signatures. A quantum attacker controlling or forging validator signatures could authorize unauthorized withdrawals of bridged SHIB, ETH, BONE, LEASH, and other assets from Ethereum escrow contracts. - Shibarium critical contracts (RootChain, StakeManager, WithdrawalManager, Governance, all Predicate escrows) are upgradeable by a single EOA with no timelock (per L2BEAT), creating a quantum-era governance risk where a compromised admin key could drain all bridge-escrowed value. - SHIB has cross-chain representations (BSC BEP-20, potentially others) secured by separate bridge validator sets, each introducing independent quantum-vulnerable signature surfaces. - There is no migration path, PQ wallet support, hybrid signature scheme, or quantum-safe transaction mechanism available to SHIB holders. In a quantum emergency, there would be no way to protect SHIB balances beyond hoping Ethereum L1 deploys PQ signatures in time. - The project has not published a cryptographic inventory, making it impossible to independently verify the full scope of quantum-vulnerable surfaces across the ecosystem (ShibaSwap, BONE/LEASH/TREAT contracts, Shib Identity, Shib Alpha Layer, etc.). ## Siren (SIREN) - Project page: https://qrindex.org/projects/siren-2/ - Complete report JSON: https://qrindex.org/projects/siren-2/report.json - Official project website: https://sirenai.me/ - Project type: meme token - Evaluated network: BNB Chain - Evaluated scope: BEP-20 token inheriting L1 quantum security posture; token-specific admin/governance keys evaluated separately - QRI score: 7.71/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Inherits L1 Score [BNB Chain], Roadmap Only, Meme Token, BEP-20 ### Summary Siren (SIREN) is a standard BEP-20 meme token on BNB Chain with renounced ownership. Under QRI Section 7.2 (Token Inheritance), it inherently shares BNB Chain's QRI score of 19/100 (Stage 1: Quantum Risk Assessed) per external reference (LayerQu). BNB Chain has acknowledged quantum risk and published a detailed PQC migration research report in May 2026 testing ML-DSA-44 and pqSTARK, but no PQC protection is deployed on mainnet. All production spend authorization remains ECDSA-only and consensus remains BLS-only — both quantum-vulnerable. The token's renounced ownership eliminates token-specific admin-key quantum risk, but all token value (~$344M market cap) is exposed through the L1's quantum-vulnerable transaction path. The score reflects early-stage research preparedness without any meaningful production quantum protection. ### Critical quantum blockers - BNB Chain mainnet spend authorization remains entirely ECDSA (secp256k1) — quantum-vulnerable. All SIREN token transfers inherit this vulnerability. - BNB Chain consensus (BLS12-381 validator signatures) remains quantum-vulnerable with no mainnet PQC deployment. - No token-level or L1-level mainnet PQC protection exists as of evaluation date. ### Principal risks - All SIREN token transfers rely on BNB Chain's ECDSA (secp256k1) transaction signatures, which are vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. - BNB Chain's BLS12-381 validator consensus signatures are quantum-vulnerable; a compromise could affect chain finality and all dependent tokens including SIREN. - No mainnet PQC deployment timeline exists for BNB Chain. The May 2026 migration report is research-only with no committed activation date. - SIREN has no independent quantum risk assessment, cryptographic inventory, or migration plan — it is entirely dependent on BNB Chain's quantum readiness trajectory. - Value-at-risk is substantial (~$344M market cap) with zero quantum protection for any holder. ## Sky (SKY) - Project page: https://qrindex.org/projects/sky/ - Complete report JSON: https://qrindex.org/projects/sky/report.json - Official project website: https://www.coingecko.com/en/coins/sky - Project type: DeFi protocol token - Evaluated network: Ethereum - Evaluated scope: Sky Protocol governance token (SKY), USDS stablecoin, governance contracts, oracle feeds, and cross-chain bridge dependencies on Ethereum mainnet - QRI score: 1/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Token Inheritance: Ethereum L1, Classical Admin Keys, Classical Bridge Dependency ### Summary Sky (SKY), formerly MakerDAO, is a DeFi governance protocol on Ethereum with approximately $7.9 billion in stablecoin liabilities (USDS). The protocol has performed zero quantum readiness work: no public cryptographic inventory, no quantum threat model, no post-quantum roadmap, no prototype or testnet, and no production PQC or hybrid-PQC protection. All spend authorization, governance voting, oracle feeds, admin keys, multi-sigs, and bridge dependencies (Skylink/LayerZero, Unichain, Optimism native bridges) rely entirely on classical ECDSA/BLS cryptography inherited from Ethereum L1. The MKR-to-SKY rebrand was a tokenomics migration, not a cryptographic one. Two classical smart-contract audits exist (ChainSecurity, Cantina) but address zero quantum scope. The Eternax industry report (April 2026) explicitly confirms Sky has no disclosed post-quantum migration roadmap. The protocol scores 1.0/100 (Stage 0), reflecting that quantum risk has not been assessed or acknowledged by the project, and no mitigation work exists. ### Critical quantum blockers - No public cryptographic inventory: Sky has not published any inventory of critical public-key mechanisms, quantum threat model, or affected assets/layers. - Active production spend authorization entirely ECC-only: All SKY/USDS token transactions, governance votes, and protocol operations rely on Ethereum ECDSA signatures. - Governance multisigs, admin keys, oracle feeds, and bridge signer sets are entirely dependent on classical (ECC) cryptography with no disclosed migration path. - No post-quantum migration roadmap, prototype, testnet, or mainnet support exists for any Sky Protocol component. - Approximately $7.9 billion in stablecoin liabilities (USDS) plus additional governance-controlled assets are fully exposed to quantum key-recovery attacks. ### Principal risks - Approximately $7.9 billion in USDS stablecoin value plus additional governance-controlled assets are fully exposed to quantum key-recovery attacks with no disclosed protection or migration path. - Governance multisigs (Chief contract, Pause Proxy, SubDAO admin keys) are entirely ECC-dependent. A quantum compromise of governance keys could lead to malicious parameter changes, unauthorized minting, collateral seizure, or protocol insolvency. - Oracle feeds (Chronicle/Scribe oracle nodes) rely on classical signatures. Compromised oracle data could trigger false liquidations or manipulate collateral valuation at scale. - Skylink (LayerZero-based), Unichain, and Optimism native bridges rely on classical cryptographic security models. A quantum break of bridge signer sets or light-client verification could enable cross-chain theft of bridged USDS/sUSDS. - No quantum incident-response process, emergency governance playbook, or disclosure mechanism exists for quantum-specific threats, leaving the protocol without a coordinated defense if quantum attacks materialize before migration. - Real-world asset (RWA) custodians and off-chain legal agreements may rely on classical digital signatures, creating additional quantum risk to the protocol's collateral base that is outside the scope of on-chain mitigation. - Dormant/legacy MKR and DAI holders who have not upgraded to SKY/USDS remain exposed, and the parallel DAI/MKR system creates additional quantum-vulnerable surface area. ## Solana (SOL) - Project page: https://qrindex.org/projects/solana/ - Complete report JSON: https://qrindex.org/projects/solana/report.json - Official project website: https://solana.com - Project type: PoS smart-contract platform - Evaluated network: mainnet-beta - Evaluated scope: Native asset (SOL) and base-layer protocol - QRI score: 23.8/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-13 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection ### Summary Solana scores 24/100 (Stage 2: Mitigation / Development). The project has published one of the most comprehensive quantum risk assessments in the blockchain industry, with detailed cryptographic inventories, formal migration roadmaps, and prototype Falcon implementations from both Anza and Firedancer. The SHA-512 Ed25519 seed derivation provides a credible theoretical migration path via ZK proofs. However, none of this changes the production reality: all native transaction signatures on mainnet use Ed25519 (broken by Shor's algorithm), TowerBFT consensus uses Ed25519 votes, BLS pubkey registration (SIMD-0387) is already live on mainnet for the upcoming Alpenglow consensus which will use BLS12-381 (also quantum-vulnerable). The opt-in Winterwallet (Winternitz Vault) provides application-layer quantum resistance on mainnet but protects negligible value (<300 accounts). SIMD-0461 (Falcon syscall) was closed/paused in June 2026; the team is exploring a Keccak-f1600 syscall approach instead. SIMD-0296 (larger transactions to 4096 bytes) is activating imminently as prerequisite infrastructure. No independent cryptographic audit of any quantum-critical component exists. No protocol-level PQ spend authorization or consensus authentication exists. Solana is well-prepared on paper but has no material production quantum protection today. ### Critical quantum blockers - All production transaction signatures use Ed25519, which is broken by Shor's algorithm. No protocol-level PQ or hybrid-PQ spend authorization path exists on mainnet. - Consensus authentication (TowerBFT Ed25519 vote transactions; upcoming Alpenglow BLS12-381 aggregated certificates) remains quantum-vulnerable. BLS pubkey registration is already live on mainnet. - Material long-exposure quantum-vulnerable value exists across all SOL accounts, SPL tokens, DeFi protocols, bridges, and treasuries with no migration, freeze, deprecation, burn, recovery, or policy path. - SIMD-0461 (Falcon syscall) was closed/paused. The alternative Keccak-f1600 syscall approach (SIMD-0563) is exploratory and does not yet provide native PQ verification. ### Principal risks - All SOL and SPL token accounts with exposed public keys are vulnerable to offline quantum attack via Shor's algorithm. This includes every account that has ever signed a transaction, every stake account, every vote account, every token mint authority, every program upgrade authority, and every multisig. - Consensus finality is quantum-vulnerable. A quantum adversary could forge Ed25519 vote transactions to compromise TowerBFT consensus. The planned Alpenglow upgrade (BLS12-381) does not resolve this — it introduces a different quantum-vulnerable primitive. - BLS pubkey registration (SIMD-0387) is already live on mainnet, and Alpenglow consensus activation is expected in Agave 4.3 (October 2026). This means near-term protocol upgrades are deepening classical cryptographic assumptions. - No migration, freeze, deprecation, or burn mechanism exists for quantum-vulnerable accounts. If a CRQC (cryptographically relevant quantum computer) emerges before migration is complete, all exposed value is at immediate risk with no protocol-level recourse. - SIMD-0461 (Falcon syscall) was closed/paused, and the alternative Keccak-f1600 syscall approach (SIMD-0563) is exploratory. The final PQC algorithm choice and activation timeline remain uncertain. - Bridge dependencies (e.g., Wormhole) may allow value to flow between Solana and non-PQ-secure systems. The quantum security of wrapped/bridged assets depends on both chains and the bridge's own signer-set security. - No hardware wallet, HSM, or institutional custody solution supports PQ signatures for Solana. Even if protocol-level PQ support were activated tomorrow, the custody infrastructure is unprepared. - The Winterwallet's WOTS scheme is one-time-use, creating UX and key-management challenges that limit its suitability as a general-purpose replacement for Ed25519. ## Spiko Amundi Overnight Swap Fund (EUR) (EURSAFO) - Project page: https://qrindex.org/projects/spiko-amundi-overnight-swap-fund-eur/ - Complete report JSON: https://qrindex.org/projects/spiko-amundi-overnight-swap-fund-eur/report.json - Official project website: https://www.spiko.io/spiko-euro - Project type: tokenized asset - Evaluated network: Ethereum, Polygon, Arbitrum, Base, Stellar - Evaluated scope: Tokenized UCITS fund shares (ERC-20 on EVM chains; native asset on Stellar) with token-specific admin/governance keys. Host-chain spend authorization and consensus are inherited per QRI Section 7.2. - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Token Inheritance, PQ-Recoverable, Roadmap Only, Classical ECC ### Summary EURSAFO is a tokenized UCITS fund deployed as standard ERC-20 tokens on Ethereum, Polygon, Arbitrum, and Base, and as a native asset on Stellar. It inherits the classical ECC cryptography (ECDSA secp256k1 / Ed25519) of all five host chains for spend authorization. Token-specific admin functions — including contract upgrades (UUPS proxy), minting, burning, pausing, KYC allowlisting, and permission management — are controlled by a multisig super-admin and Dfns MPC wallets that also rely on classical signature schemes. No quantum risk assessment, cryptographic inventory, PQC implementation, migration plan, or quantum-specific incident-response process has been published by Spiko. The regulated, KYC-gated fund structure with CACEIS as depositary provides a credible off-chain recoverability path, but this does not constitute on-chain quantum resistance. The QRI Score is 0, capped by the absence of any public cryptographic inventory (Readiness & Risk Cap: 10) and a Factor Score of 0 across all five categories. ### Critical quantum blockers - No public cryptographic inventory: Spiko has not published a quantum-focused inventory of critical public-key mechanisms, attack assumptions, affected assets, or affected layers. Readiness & Risk Cap: 10. - Active production spend authorization remains entirely ECDSA (EVM chains) / Ed25519 (Stellar) only. All token-holder transactions rely on host-chain classical signature schemes. - Admin multisig super-admin keys rely on classical ECDSA/Ed25519 and control contract upgrades, minting, burning, pausing, KYC allowlisting, and permission management. A quantum compromise of these keys would enable theft, inflation, and supply manipulation. - Dfns MPC wallet infrastructure for treasury and operations uses classical threshold ECDSA/EdDSA with no confirmed production PQC deployment for Spiko. - Material long-exposure quantum-vulnerable value (~$422M) exists with no migration, freeze, deprecation, burn, recovery, or policy path. ### Principal risks - Admin key compromise via quantum attack: The multisig super-admin controls UUPS upgrades, permission management, minting, burning, and pausing across all deployments. A Shor-enabled attacker recovering the admin ECDSA/Ed25519 private keys could upgrade the token implementation to a malicious contract, mint unlimited tokens, or freeze all transfers. - Dfns MPC wallet compromise: Spiko's treasury and operational wallets use Dfns threshold ECDSA/EdDSA. While MPC raises the bar against classical attacks, a cryptographically relevant quantum computer could break the underlying elliptic curve assumptions regardless of share distribution. - Host-chain dependency: EURSAFO inherits the quantum vulnerability of five host chains (Ethereum, Polygon, Arbitrum, Base, Stellar). Even if Spiko migrated its admin keys, token-holder spend authorization would remain classically vulnerable until the underlying L1s adopt PQC. - Long-exposure public keys: Any EURSAFO holder address that has sent a transaction on an EVM chain has an exposed public key. These are vulnerable to offline quantum attack with no time constraint. - No migration mechanism exists: There is no documented path for users or administrators to migrate to quantum-safe keys, no deprecation policy for vulnerable accounts, and no freeze/burn mechanism for quantum-compromised addresses beyond the general pause capability. - Supply at risk: approximately $422M total value across five chains (Stellar ~$241M, Polygon ~$52M, Arbitrum ~$50M, Ethereum ~$14M, Base ~$4M) is fully exposed to quantum key-recovery attacks on both holder and admin keys. ## Spiko EU T-Bills Money Market Fund (EUTBL) - Project page: https://qrindex.org/projects/eutbl/ - Complete report JSON: https://qrindex.org/projects/eutbl/report.json - Official project website: https://www.spiko.xyz - Project type: tokenized asset - Evaluated network: Multi-chain (Ethereum, Polygon, Arbitrum, Base, Etherlink, Stellar, StarkNet) - Evaluated scope: Tokenized fund share (ERC-20 / Stellar / StarkNet) with cross-chain bridge dependency - QRI score: 6.33/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-02 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: PQ-Recoverable, Token Inheritance, Classical Only, Centralized Issuer, Tokenized RWA ### Summary Spiko EU T-Bills Money Market Fund (EUTBL) is a ~$1B regulated tokenized RWA deployed across 7 chains with zero post-quantum cryptographic protection. All transaction authorization, admin key operations, bridge signing, and permit signatures rely entirely on classical ECDSA (EVM chains) or Ed25519 (Stellar). No PQC features exist in production, testnet, roadmap, or proposal form. The project has not published a quantum risk assessment or cryptographic inventory. However, as a KYC-gated UCITS fund with centralized issuer control (freeze, upgrade, reissue capabilities), EUTBL qualifies for the PQ-Recoverable tag: the issuer can legally reconstruct the ledger off-chain and re-deploy on a quantum-secure infrastructure after an attack. This recoverability is a meaningful mitigant but does not constitute quantum resistance—it does not prevent quantum-enabled theft, unauthorized minting, or bridge compromise in the current production system. Score: 6.33/100 (Stage 1: Quantum Risk Assessed, Medium confidence). ### Critical quantum blockers - Active production spend authorization is entirely ECDSA/EdDSA-only across all deployed chains. All ~$1B in token value is controlled by quantum-vulnerable classical signatures with no PQC or hybrid migration path deployed, proposed, or roadmapped. - Token admin keys (super-admin multisig, daily-operator, exceptional-operator) rely on classical ECC and control minting, burning, pausing, upgrading, and permission management. Compromise by a quantum adversary enables unauthorized minting and supply inflation. - Chainlink CCIP bridge for cross-chain transfers relies on classical threshold signatures/multisigs; bridge authorities represent a high-value quantum target. - No public cryptographic inventory, quantum threat model, or quantum risk assessment has been published by the project. - StarkNet deployment introduces additional classical cryptographic dependencies through the StarkNet L2 architecture. ### Principal risks - QUANTUM-CRITICAL: All ~$1B in EUTBL token value across 7 chains is secured exclusively by ECDSA/EdDSA signatures. A Cryptographically Relevant Quantum Computer (CRQC) capable of breaking secp256k1 or Ed25519 can forge spend authorization for any EOA that has ever sent a transaction, or any Stellar account with a revealed public key. - QUANTUM-CRITICAL: The super-admin multisig (governing UUPS upgrades, permission management, minting, burning, pausing) is classical-ECC-based. Quantum compromise enables infinite unauthorized minting and supply inflation across all chains. - QUANTUM-CRITICAL: The Chainlink CCIP bridge signer set uses classical threshold signatures. Quantum compromise of the bridge allows unauthorized cross-chain minting of EUTBL on destination chains. - QUANTUM-CRITICAL: ERC-2612 permit signatures (gasless approvals) use ECDSA and are quantum-vulnerable, enabling unauthorized spending approvals. - QUANTUM-CRITICAL: ERC-2771 meta-transaction forwarder relies on classical ECDSA signatures. - QUANTUM-CRITICAL: StarkNet deployment adds L2-specific classical cryptographic dependencies (StarkNet's own bridging and proof system). - ASSURANCE: The Trail of Bits audit (2023) predates any potential PQC considerations and provides no quantum-security assurance. The Halborn Stellar audit (2025) is current for classical code but similarly quantum-unaware. - OPERATIONAL: No public quantum migration plan, cryptographic inventory, or quantum threat model exists. The regulated entity structure provides legal recovery pathways but no technical quantum protection. ## Stable (STABLE) - Project page: https://qrindex.org/projects/stable-2/ - Complete report JSON: https://qrindex.org/projects/stable-2/report.json - Official project website: https://www.coingecko.com/en/coins/stable-2 - Project type: cryptoasset - Evaluated network: StableChain Mainnet - Evaluated scope: Native L1 asset (STABLE governance token) and StableChain protocol; EVM-compatible Layer-1 blockchain with StableBFT (CometBFT-based) consensus - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Low - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Classical Cryptography, EVM-Compatible, CometBFT ### Summary Stable (STABLE) is a recently launched (December 2025) EVM-compatible Layer-1 blockchain optimized for USDT payments, utilizing a CometBFT-based consensus mechanism (StableBFT). The project relies entirely on classical cryptographic primitives: ECDSA (secp256k1) for spend authorization via EVM compatibility, and Ed25519 for validator consensus signatures. There is no public evidence of any post-quantum cryptography (PQC) implementation, hybrid protection, quantum risk assessment, or migration roadmap. The absence of public source code, audits, and cryptographic specifications limits verification to whitepaper and documentation claims, which confirm a purely classical architecture. The project's published roadmap (Autobahn, StableVM++, StableDB) contains zero quantum-security items. As a result, the project scores minimally on the QRI, reflecting Stage 0 (Unassessed / No Evidence) with critical quantum vulnerabilities across all applicable layers. ### Critical quantum blockers - All production spend authorization is ECDSA (secp256k1) only — fully quantum-vulnerable to Shor's algorithm; all transacted EOAs expose public keys creating long-exposure attack surface. - All consensus authentication (StableBFT/CometBFT) relies on classical Ed25519/ECDSA validator signatures — quantum-vulnerable; a quantum-capable adversary could forge validator signatures and compromise finality. - Confidential Transfer zero-knowledge proofs likely rely on quantum-vulnerable pairing-based cryptography (BN254 or similar); unverifiable without algorithm disclosure. - No quantum risk assessment, cryptographic inventory for quantum purposes, PQC roadmap, prototype, testnet, or migration plan exists. ### Principal risks - All user funds, governance tokens, and bridged assets (~$780M+ on-chain) are secured by ECDSA keys fully breakable by a cryptographically relevant quantum computer; every EOA that has sent a transaction has an exposed public key enabling offline attack with no time constraint. - StableBFT validator signatures (Ed25519/ECDSA) are quantum-vulnerable; a quantum adversary could forge validator signatures to compromise consensus finality, enabling double-spend attacks, censorship, or chain reorganization. - Confidential Transfer ZK proofs are likely based on quantum-vulnerable elliptic-curve pairings; a quantum attacker could forge privacy proofs to create inflation, break confidentiality, or compromise shielded state binding. - LayerZero bridge with 3/3 DVN configuration inherits the quantum vulnerability of each DVN operator's signing keys; quantum compromise of any single DVN combined with exploitation of implementation weaknesses could threaten cross-chain asset flows. - No open-source protocol code means quantum vulnerabilities cannot be independently verified, patched by the community, or assessed by third-party researchers without project cooperation. - The project's roadmap contains no quantum-security milestones, suggesting quantum risk is not on the development agenda despite Google's March 2026 recommendation to migrate by 2029. ## Starknet (STRK) - Project page: https://qrindex.org/projects/starknet/ - Complete report JSON: https://qrindex.org/projects/starknet/report.json - Official project website: https://www.starknet.io - Project type: Ethereum L2 validity-rollup smart-contract platform - Evaluated network: Starknet Mainnet (Ethereum L2 validity-rollup) - Evaluated scope: Native asset (STRK), L2 protocol, StarkGate bridge, and Ethereum L1 settlement dependency - QRI score: 35/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Partial Protection, Roadmap Only (spend/consensus) ### Summary Starknet scores 35/100 (Stage 2 — Mitigation / Development). The network benefits from quantum-resistant STARK proofs for state-transition integrity, and native Account Abstraction provides a technically viable path for users to adopt PQC signatures (Falcon-512 demonstrated on mainnet). However, as of June 2026, production spend authorization defaults to Stark curve ECDSA, consensus authentication uses Ed25519 via Malachite BFT, the StarkGate bridge permits unrestricted two-way flow to quantum-vulnerable Ethereum L1, data availability depends on quantum-vulnerable KZG commitments (EIP-4844), and the state commitment scheme still relies on ECC-based Pedersen hashing in contract tries. Essentially zero economic value is protected by PQC today. The project has published a credible quantum risk assessment (StarkWare, December 2024) and lists quantum-resistant cryptography on its Phase 4 roadmap, but production protection is not yet material. ### Critical quantum blockers - Default spend authorization uses Stark curve ECDSA (quantum-vulnerable); PQC path exists optionally via Account Abstraction + Falcon-512 but is not default, mandatory, or widely adopted. - Consensus authentication (Malachite BFT / Pathfinder consensus) uses Ed25519 signatures, which are quantum-vulnerable. - StarkGate two-way bridge allows unrestricted value flow back to Ethereum L1, which is not quantum-secure (ECDSA-based accounts, BLS-based consensus). - Data Availability relies on Ethereum EIP-4844 blobs using KZG polynomial commitments (BLS12-381), which are vulnerable to Shor's algorithm. - State commitment contract trie and Merkle-Patricia trie nodes use Pedersen hash (ECC-based), creating a quantum-vulnerable dependency in state binding. ### Principal risks - A quantum adversary capable of running Shor's algorithm could recover Stark curve ECDSA private keys from on-chain signatures, compromising all active user accounts and their assets. - Consensus compromise via Ed25519 key recovery could allow an adversary to forge validator attestations and potentially finalize malicious blocks once decentralized validation is fully deployed (Staking v3/v4). - KZG commitment forgery on Ethereum's EIP-4844 blob layer could corrupt Starknet's data availability verification, enabling invalid state updates to bypass L1 validation. - Pedersen hash collisions in the contract trie could theoretically enable state-binding attacks, though the STARK proof's quantum-resistant verification of state transitions provides a mitigating layer. - The StarkGate bridge exposes all bridged assets to Ethereum L1's quantum vulnerabilities; a compromise of L1 bridge contracts or L1 user accounts could drain bridge-held value. - Long-exposure risk: all Starknet accounts that have broadcast transactions have exposed their ECDSA public keys on-chain, creating a harvest-now-decrypt-later attack surface. ## Stellar (XLM) - Project page: https://qrindex.org/projects/stellar/ - Complete report JSON: https://qrindex.org/projects/stellar/report.json - Official project website: https://www.stellar.org/ - Project type: tokenized asset - Evaluated network: Stellar Mainnet - Evaluated scope: Native asset (XLM), Stellar Core protocol, Soroban smart contract platform, and X-Ray privacy system as deployed on mainnet - QRI score: 14/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-10 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection, ECC-Only Spend Authorization, Exposed Public Keys, Ed25519 ### Summary Stellar remains fully dependent on Ed25519 for all production-critical cryptographic operations as of June 10, 2026, with zero post-quantum protection live on mainnet. The Stellar Development Foundation published a comprehensive Quantum Preparedness Plan (QPP) on June 9, 2026 — one day before this evaluation — outlining a well-structured three-stage migration roadmap targeting ML-DSA integration via Soroban host functions in 2026 and native classic-account PQ signer support via CAP in 2027. The QPP demonstrates serious institutional engagement with quantum risk: it identifies specific NIST-standard algorithms (ML-DSA-44, ML-DSA-65), provides a credible staged timeline, correctly diagnoses both the account-takeover and consensus-compromise threat vectors, and acknowledges unsolved problems (BN254 pairing dependency, dormant accounts). Stellar's architectural separation of account identity from signing keys represents a genuine structural advantage — once PQ signer types exist, users can add quantum-safe signers without changing addresses or migrating balances. However, Stellar's address format (G... addresses) directly encodes Ed25519 public keys, meaning 100% of the ~33.7B XLM circulating supply (~$6.6B market cap) is in the long-exposure attack window today. SCP consensus authentication also remains Ed25519-only. The X-Ray privacy system adds a separate BN254 pairing-based vulnerability with no defined mitigation path. The base ledger's SHA-256 hash chain provides PQ-safe state integrity, earning partial credit in Production Cryptographic Protection. CAP-77 (Quorum Freeze), live since May 2026, provides a protocol-native emergency governance tool that could potentially be applied to quantum scenarios. With no PQ code, testnet, prototype, or mainnet deployment, the project is correctly staged at Stage 2 (Mitigation/Development). The QRI score of 14 reflects strong assessment and planning work capped by the complete absence of production PQ protection. ### Critical quantum blockers - All production spend authorization is Ed25519-only — no PQ or hybrid signing path exists on mainnet (Readiness & Risk Cap 40: 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only'). - 100% of Stellar account addresses (G... addresses) directly encode the Ed25519 public key, placing all ~33.7B XLM circulating supply (~$6.6B market cap) in the long-exposure attack window with no migration, freeze, or deprecation mechanism live (Readiness & Risk Cap 55: 'Material long-exposure quantum-vulnerable value exists with no migration path'). - Stellar Consensus Protocol (SCP) validator authentication relies entirely on Ed25519 signatures — a quantum-capable adversary could forge validator signatures to compromise quorum intersection and network finality (Readiness & Risk Cap 70: 'Consensus finality, validator authentication... remains quantum-vulnerable'). - X-Ray privacy system uses BN254 pairing-based elliptic curve for zero-knowledge proofs — quantum-vulnerable to Shor's algorithm with no defined PQ migration path. QPP explicitly acknowledges this as an open research challenge (Readiness & Risk Cap 70: 'Application-layer proof systems... depend on quantum-vulnerable pairings'). ### Principal risks - All ~33.7B XLM in circulating supply is controlled by Ed25519-only keys with public keys directly exposed in account addresses from the moment of creation — a quantum adversary needs only to derive private keys from these exposed public keys to steal funds, and all accounts (including dormant ones that have never transacted) are perpetually vulnerable. - SCP consensus can be compromised if an attacker forges sufficient validator Ed25519 signatures to control quorum intersection. Unlike account takeover, this is a network-liveness and finality threat that could affect all users simultaneously. - Stellar's address format (G... addresses directly encoding Ed25519 public keys) is structurally more vulnerable than Bitcoin's or Ethereum's hashed-public-key approach, where keys are only exposed upon first spend. On Stellar, even accounts that have never transacted have fully exposed keys from the moment of creation. - Dormant accounts with unreachable holders represent a permanent quantum-vulnerable value pool. The QPP acknowledges this as an unresolved challenge requiring community governance, but no freeze, recovery, or deprecation mechanism exists yet. CAP-77 could potentially be used but has not been designed for this purpose. - X-Ray's BN254 dependency is quantum-vulnerable and has no defined mitigation path. The QPP explicitly acknowledges this as an open research challenge: 'there is no drop-in post-quantum replacement for pairing-based SNARKs with comparable performance.' While X-Ray is opt-in and does not threaten core asset ownership, any privacy-sensitive transactions could be retrospectively deanonymized by a future quantum adversary. - The QPP is a strategic announcement with no reviewable code, testnet deployment, or detailed technical specification. Execution risk is material — the plan requires coordinated upgrades across stellar-core, Soroban host functions, SDKs, wallets, anchors, and custodians. Technical specifications are promised 'over the coming weeks' but have not been published. - The QPP roadmap targets 2027 for native classic-account PQ support, but NIST guidance places the quantum danger zone at 2029+. If quantum capabilities advance faster than expected, the migration window could narrow dangerously. INRIA researchers recently showed breaking 256-bit ECC requires only 1,193 logical qubits — a 44% reduction from prior estimates. - Soroban SDK v26.0.0 (May 2026) expanded BN254 and BLS12-381 host functions (CAP-80), increasing the quantum-vulnerable pairing-based cryptography surface on mainnet even as the QPP acknowledges no PQ replacement exists for these primitives. ## Sui (SUI) - Project page: https://qrindex.org/projects/sui/ - Complete report JSON: https://qrindex.org/projects/sui/report.json - Official project website: https://www.coingecko.com/en/coins/sui - Project type: blockchain network - Evaluated network: Sui Mainnet - Evaluated scope: Sui base-layer network (native asset SUI, consensus, spend authorization, Move smart contracts, P2P, ZK proof layers) - QRI score: 16/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-16 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only ### Summary Sui is a Layer 1 blockchain with strong cryptographic agility infrastructure but zero post-quantum protection in production as of August 16, 2026. All production cryptographic layers remain classical: user spend authorization uses Ed25519/ECDSA secp256k1/secp256r1, validator consensus uses BLS12-381 aggregated signatures in Mysticeti's batched design, P2P identity uses Ed25519, and zkLogin depends on Groth16 proofs over pairing-based curves (BN254/BLS12-381). On August 6, 2026, Sui announced integration of NIST-standardized ML-DSA-65 (FIPS 204) for native accounts and SLH-DSA-SHA2-128s (FIPS 205) for Move smart-contract vaults. The core implementation is described as 'built and benchmarked' with independent audits underway. Quantum-safe vaults are targeted for mainnet by end of 2026, and native ML-DSA-65 accounts for testnet by end of 2026 with mainnet in Q1 2027. An early mainnet 'set_vault_enabled' framework artifact was observed on Aug 6, 2026, but no material PQ-protected value exists. The project is at Stage 2 (Mitigation/Development): a credible roadmap and prototype exist with excellent architectural preparedness, but production users are not materially protected. QRI Score 16 reflects strong risk-assessment preparedness and sound algorithm selection offset by zero production cryptographic protection and negligible migration coverage. The consensus-layer BLS12-381 aggregation path and Groth16 ZK proof system represent significant architectural gaps with no published PQ replacement specifications. ### Critical quantum blockers - Active production spend authorization remains entirely ECC/BLS/EdDSA-only (Ed25519, ECDSA secp256k1/secp256r1 for user transactions; BLS12-381 for validator consensus). No mainnet or public testnet PQC/hybrid signature support as of 2026-08-16. - Validator consensus authentication uses BLS12-381 aggregated signatures in Mysticeti batched design with no published PQ replacement specification for the aggregation path. - ZK proof layer (Groth16 over BN254/BLS12-381) is pairing-based and quantum-vulnerable with no announced migration plan. - PQ implementation exists as prototype only (built and benchmarked); no public testnet or mainnet deployment available as of evaluation date. ### Principal risks - All native SUI holdings are controlled by classical ECC keys (Ed25519, secp256k1, secp256r1) with long-exposure public keys visible on-chain, representing 100% value-at-risk to future quantum key recovery. - Validator consensus relies on BLS12-381 aggregated signatures in Mysticeti's batched design; a quantum adversary capable of breaking discrete log could forge validator signatures and compromise finality. - No published specification exists for replacing BLS12-381 in Mysticeti's consensus aggregation path, making this a significant architectural blind spot. - Groth16 ZK proofs over BN254/BLS12-381 used in zkLogin are pairing-based and quantum-vulnerable; compromise could allow unauthorized account access via forged JWT verification proofs. - PQ features will be opt-in, not mandatory; classical signing paths will remain available indefinitely, preserving quantum-vulnerable fallback unless enforcement mechanisms are introduced. - Timeline risk: announced mainnet deployments (vaults end of 2026, native accounts Q1 2027) are targets, not guarantees; audits are underway and timelines remain open per official statement. - Bridge dependencies to non-PQ-secure networks create cross-chain quantum exposure even after native PQ deployment. ## Superstate Short Duration U.S. Government Securities Fund (USTB) (USTB) - Project page: https://qrindex.org/projects/superstate-short-duration-us-government-securities-fund-ustb/ - Complete report JSON: https://qrindex.org/projects/superstate-short-duration-us-government-securities-fund-ustb/report.json - Official project website: https://www.coingecko.com/en/coins/superstate-short-duration-us-government-securities-fund-ustb - Project type: tokenized asset - Evaluated network: Ethereum (primary), Solana, Plume - Evaluated scope: USTB token (ERC-20 on Ethereum/Plume, SPL Token-2022 on Solana) including admin/governance keys, AllowList, and redemption contracts. Inherits host-chain (L1/L2) QRI score per QRI §7.2. - QRI score: 2.75/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: PQ-Recoverable, Inherits L1 Score, Tokenized Asset, Classical Cryptography, Centralized Admin ### Summary Superstate USTB (~$741M–$988M AUM) is a tokenized U.S. Treasuries fund deployed as a standard ERC-20/SPL token on Ethereum, Solana, and Plume. It inherits the quantum vulnerability of all three host chains and adds token-specific risk through 4 EOA-controlled admin keys (no multisig, no timelock). The project has published zero quantum-specific work: no cryptographic inventory, no quantum threat model, no PQC migration roadmap, no prototype, and no mainnet PQ support. All spend authorization is classical ECDSA/Ed25519. The admin EOAs have exposed on-chain public keys, making them long-exposure quantum targets. On the positive side, Superstate maintains redundant off-chain ownership records and can forcibly burn/remint tokens, making the system PQ-Recoverable. The fund benefits from 11 classical security audits, formal verification, institutional-grade custody (BNY Mellon), and a strong legal structure (bankruptcy-remote Delaware Trust, SEC regulated). However, per QRI rules, recoverability and classical audit coverage do not raise the quantum readiness score. The QRI Score of 3 reflects the minimal credit earned — partial credit for the documented PQ-Recoverable recovery mechanism (Category 4) and the upgradeable proxy pattern (Category 5) — capped at 10 by the absence of a public cryptographic inventory. Quantum risk has been identified by third parties (Eternax.ai, Yearn risk report) but not formally assessed or acknowledged by the project itself. ### Critical quantum blockers - No public cryptographic inventory published by the project (Readiness & Risk Cap: 10). - All spend authorization is ECDSA-only (Ethereum/Plume) or Ed25519-only (Solana) — fully quantum-vulnerable (Readiness & Risk Cap: 40). - Admin keys are 4 EOAs with ECDSA, all with exposed on-chain public keys; no multisig, no timelock, no PQC migration path. Quantum compromise of the USTB Token Owner EOA alone enables unlimited minting, adminBurn of any holder, contract upgrades, and oracle replacement with zero delay. - ~$741M–$988M in value-at-risk is 100% quantum-vulnerable with no migration, freeze-deprecation, or protection path for on-chain token holdings. - No PQC migration plan, roadmap, prototype, testnet, or mainnet support exists. - Harvest-now-decrypt-later risk: institutional transaction flows are publicly visible on-chain and cannot be retroactively protected by off-chain recovery. ### Principal risks - Quantum compromise of the USTB Token Owner EOA (0xad309bb6f13074128b4f23ef9ea2fe8552afca83) would enable unlimited minting, adminBurn of any holder's tokens, pausing all operations, replacing the price oracle, and upgrading the token implementation — all with no timelock and no multisig threshold. - Quantum compromise of the AllowList Owner EOA (0x7747940adbc7191f877a9b90596e0da4f8deb2fe) would enable mass freezing of institutional holders by removing addresses from the AllowList, with zero exit paths for affected holders. - Quantum compromise of the RedemptionIdle Owner EOA (0x8cf40e96e7d7fd8A7A9bEf70d3882fbBC4D40765) would enable pausing redemptions and withdrawing USDC from the redemption contract. - Quantum compromise of the Oracle Owner EOA (0x4B1df64357a5D484563c9b7c16a80eD8B8fB1395) would enable manipulation of NAV checkpoints, affecting subscription and redemption pricing for all holders. - All ~$741M in on-chain USTB value (plus ~$66M in Aave) is 100% exposed to quantum key-recovery attacks with no migration or protection path. - Harvest-now-decrypt-later: institutional transaction patterns and counterparty relationships are permanently recorded on public ledgers and cannot be retroactively protected, even if tokens are later recovered off-chain. - The EVM bridge function relies on Superstate backend to credit destination chains — quantum compromise of admin keys could disrupt or corrupt cross-chain reconciliation. ## Tether (USDT) - Project page: https://qrindex.org/projects/tether/ - Complete report JSON: https://qrindex.org/projects/tether/report.json - Official project website: https://tether.to - Project type: multi-chain stablecoin - Evaluated network: Multi-chain (Ethereum, TRON, Solana, Avalanche, Polygon, Aptos, TON, and others) - Evaluated scope: Multi-chain fiat-backed stablecoin token; token-specific admin/governance keys evaluated separately per QRI Token Inheritance rule (Section 7.2). Host-chain quantum posture evaluated separately. - QRI score: 3/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Token Inheritance, ECC-Only Admin Keys, Long-Exposure Public Keys ### Summary Tether (USDT) is a multi-chain fiat-backed stablecoin token with no native blockchain or custom cryptographic primitives. User-level transfer security inherits host-chain quantum posture (evaluated separately). This evaluation focuses on token-specific admin/governance keys per QRI Token Inheritance rule (Section 7.2). USDT admin keys (mint, burn, freeze, destroyBlackFunds) on all host chains are controlled by ECDSA-based addresses with permanently exposed public keys. On Ethereum, a 3-of-6 Gnosis Safe multisig (0xC6CDE7C39eB2f0F0095F41570af89eFC2C1Ea828) holds all admin authority; all six signer EOAs have transacted on-chain, permanently exposing their ECDSA public keys. Similar exposure exists on TRON, Solana, and all other host chains. The Google Quantum AI whitepaper (March 30, 2026) explicitly identifies USDT admin keys among approximately 70 high-value Ethereum contracts with exposed keys, estimating compromise in minutes on a fast-clock CRQC with fewer than 500,000 physical qubits. A quantum attacker compromising any major-chain admin key could mint unlimited unbacked tokens, collapsing the fiat peg across the entire approximately $200B ecosystem. Tether has published no quantum risk assessment, cryptographic inventory, PQ migration roadmap, or testnet. The CEO acknowledged the threat in February 2025 but characterized it as distant. As of 2026-06-01, no production PQC or hybrid-PQ protection exists anywhere in the USDT admin infrastructure. By contrast, Circle (USDC) published a comprehensive post-quantum security whitepaper and roadmap in May 2026. QRI Score: 3/100. Stage 1 (Quantum Risk Assessed). The score reflects zero quantum protection across all evaluated categories except that USDT contract code is publicly verifiable on-chain. ### Critical quantum blockers - USDT admin keys (mint, burn, freeze, destroyBlackFunds) on Ethereum, TRON, Solana, and all other host chains are controlled by ECDSA-based addresses with permanently exposed public keys. A quantum attacker compromising any major-chain admin key can mint unlimited unbacked USDT, collapse the fiat peg, freeze arbitrary accounts, and destroy blacklisted funds regardless of host-chain quantum readiness. - No public post-quantum migration roadmap, pilot, testnet, or governance proposal exists for rotating USDT admin keys to PQ or hybrid-PQ multisig schemes on any host chain. - Tether has not published a cryptographic inventory, quantum threat model, or evidence-backed risk assessment for its token-specific admin infrastructure. Third-party research (Google Quantum AI, March 2026) independently identifies USDT admin keys as among the highest-value quantum-vulnerable targets in the Ethereum ecosystem. ### Principal risks - Supply-integrity compromise: Compromise of any major-chain admin key enables unlimited minting of unbacked USDT. This is a systemic risk to the stablecoin peg that would cascade through all DeFi protocols, exchanges, and lending markets using USDT as collateral. - Long-exposure at-rest attack: All Ethereum multisig signer EOAs and TRON multisig signers have permanently exposed ECDSA public keys from past transactions. Attackers have unlimited offline time to derive private keys once sufficient quantum capability exists. - Centralization of admin authority: On Ethereum, a single 3-of-6 multisig controls mint, burn, freeze, pause, clawback, and fee parameters. On TRON, a 2-of-n multisig controls equivalent functions. Compromise of the required signer threshold grants full admin control with no separation of privileges. - Multi-chain contagion: USDT on all host chains (Ethereum approximately $96B, TRON approximately $88B, Solana approximately $3B, plus additional chains) depends on quantum-vulnerable admin keys. Compromise on any chain would destroy confidence in USDT across all chains. - No migration mechanism exists: No public design, prototype, testnet, or governance proposal exists for migrating USDT admin keys to PQ or hybrid-PQ multisig schemes. The contract's transferOwnership function provides a technical mechanism for key rotation, but no quantum-safe destination address scheme has been specified. - Freeze-gap exploitation: The documented timing gap between freeze proposal submission and execution on TRON (up to 44 minutes) could be exploited by a quantum attacker monitoring the multisig to extract funds before a freeze executes. - Regulatory and institutional risk: The GENIUS Act and NIST PQC deprecation timeline (2030) create regulatory pressure for quantum-safe financial infrastructure. USDT's lack of PQ readiness creates compliance risk for exchanges, custodians, and institutional holders. - Competitive displacement risk: Circle (USDC) published a comprehensive PQ roadmap in May 2026. Post-quantum-native chains and EVM-compatible PQ L2s create migration targets that could pull stablecoin activity away from quantum-vulnerable hosts. ## Tether Gold (XAUT) - Project page: https://qrindex.org/projects/tether-gold/ - Complete report JSON: https://qrindex.org/projects/tether-gold/report.json - Official project website: https://www.coingecko.com/en/coins/tether-gold - Project type: tokenized asset - Evaluated network: Ethereum, TRON, BNB Chain - Evaluated scope: Tokenized Asset (ERC-20 / TRC-20) including admin/governance keys - QRI score: 1.6/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Tokenized Asset, Admin-Key Critical Vulnerability, Inherits L1 Score (Ethereum) ### Summary Tether Gold (XAUT) is a tokenized physical-gold asset deployed as an ERC-20 token on Ethereum (primary), TRC-20 on TRON, and BEP-20 on BNB Chain. XAUT has published no quantum risk assessment, cryptographic inventory, migration roadmap, or PQ protection of any kind. As a standard smart-contract token, XAUT inherits the quantum vulnerability of its host chains for user transactions, but the critical independent finding is that the Tether Multisig (a 3-of-6 ECC-based custom MultiSigWallet) controls all privileged functions — mint, burn, proxy upgrade, blacklist, ownership transfer — and its signers' public keys are permanently exposed on-chain through executed transactions. A quantum adversary who recovers any 3 of 6 signer private keys can mint unlimited unbacked XAUT, upgrade the proxy to steal funds, or destroy the token's value entirely. This represents a quantum-critical vulnerability affecting the full ~$2.7B supply, independent of any host-chain migration timeline. The QRI Score of 1.6 reflects near-total absence of quantum readiness: no project-led assessment (Stage 0), no production cryptographic protection, negligible migration coverage (only a theoretical proxy upgrade path), and no published algorithmic assurance work. ### Critical quantum blockers - Admin keys (Tether Multisig 3-of-6 ECC-based) controlling minting, blacklisting, and proxy upgrades are entirely ECC-based and exposed on-chain, creating a quantum-critical vulnerability for supply integrity. - No public cryptographic inventory, quantum threat model, or migration roadmap published by Tether for XAUT or its underlying admin infrastructure. - Token inherits Ethereum and TRON base-layer quantum vulnerabilities (secp256k1 ECDSA) for all user spend authorization and account exposure. ### Principal risks - Admin-key quantum compromise: The 3-of-6 ECC multisig has exposed all signer public keys on-chain. A CRQC-capable adversary needs only 3 private keys to mint unlimited XAUT, upgrade the proxy, blacklist and destroy arbitrary holdings, or transfer ownership. This would decouple token supply from physical gold reserves instantly and irreversibly. - No migration path: Tether has published no plan, timeline, or design for migrating XAUT admin keys to PQ-safe multisig, threshold, or MPC schemes. The proxy upgrade mechanism could theoretically support migration, but no proposal exists. - Multi-chain exposure: XAUT is deployed on Ethereum, TRON, BNB Chain, and reportedly Mantle and TON. Each deployment may have independent admin-key surfaces with similar quantum vulnerabilities, multiplying the attack surface. - Systemic contagion: A compromise of the Tether Multisig would affect not only XAUT but also USDT (the multisig also serves as owner of the USDT contract on Ethereum, per Aave governance analysis), creating potential for cascading market-wide failure. - Long-exposure attack window: Admin keys have been exposed on-chain for years. The harvest-now-decrypt-later threat means recorded signatures are already collectable by adversaries. When a CRQC becomes available, there is zero time to react — the keys are already compromised. ## Tidecoin (TDC) - Project page: https://qrindex.org/projects/tidecoin/ - Complete report JSON: https://qrindex.org/projects/tidecoin/report.json - Official project website: https://tidecoin.org/ - Project type: blockchain network - Evaluated network: Tidecoin mainnet - Evaluated scope: Native TDC on the production Tidecoin Layer 1 as of 2026-08-20, covering spend authorization, address and key exposure, proof-of-work consensus, UTXO state integrity, P2P transport, first-party wallet workflows, and native-asset migration. The external wTDC representation on BNB Smart Chain is excluded from native-L1 scoring and treated as an unverified wrapper dependency. - QRI score: 90.75/100 - Readiness stage: 4 (Migration Complete / Quantum-Ready) - Evidence confidence: Medium - Evaluation date: 2026-08-20 - Review status: draft - User urgency: [No Action Needed] for native TDC; [Monitor for Updates] for wrapped representations, independent review, and FN-DSA upgrade details - Readiness tags: PQ-Native, PQ-Resistant ### Summary Tidecoin is assessed as a PQ-native production proof-of-work UTXO network for native TDC. Public code, protocol documentation, component repositories, and mainnet artifacts support mandatory Falcon-512 transaction authorization from genesis, no retained classical native-ownership namespace, hash-based state mechanisms, hardened PQ wallet derivation, and no validator-signature authentication layer. Native ECC-to-PQC migration is therefore complete by design. Confidence is Medium because no independent audit was supplied, PQHD and implementation-specific Falcon behavior lack located formal review, and operational assurance documentation is limited. A separate wTDC representation on BNB Smart Chain is outside the native scope and should not be assumed to inherit Tidecoin L1 protection. ### Critical quantum blockers No critical quantum blockers are recorded. ### Principal risks - Holders of the separate wTDC representation may depend on BNB Smart Chain accounts, contracts, administrators, custodians, or bridge signers using classical cryptography. The supplied evidence does not establish the wrapper's control model, activity, value-at-risk, or whether it supports unrestricted two-way flow. - The absence of independent cryptographic and implementation review leaves residual assurance risk around Falcon integration, PQHD derivation, SHA-512 witness extensions, and ML-KEM transport, although the principal native quantum-security properties are inspectable through public code and documentation. - Legacy Falcon-512 compatibility behavior, including documented nonce reuse across retries, warrants independent assessment. The canonical evidence does not show that it enables key recovery, forgery, or a current quantum attack. - A future backward-incompatible transition to finalized FN-DSA may require careful coordination, although current native quantum protection does not depend on completing that future PQ-to-PQ upgrade. - No documented quantum-specific emergency response process was located for a newly discovered weakness in Falcon, PQHD, ML-KEM integration, or related implementation code. ## Toncoin (TON) - Project page: https://qrindex.org/projects/toncoin/ - Complete report JSON: https://qrindex.org/projects/toncoin/report.json - Official project website: https://ton.org - Project type: PoS smart-contract platform - Evaluated network: The Open Network (mainnet) - Evaluated scope: Native asset (TON) on TON mainnet L1, including base-layer spend authorization, consensus, state integrity, P2P, and wallet infrastructure as of 2026-06-01. - QRI score: 12.7/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: ECC-Only Active Security, Long-Exposure Public Keys, No Quantum Roadmap, Ed25519 Spend Authorization, Ed25519 Consensus Signatures ### Summary Toncoin (TON) is a PoS smart-contract platform that relies entirely on Ed25519 elliptic-curve cryptography for all wallet transaction signatures, validator consensus signatures, and P2P node identity. Public keys are exposed on-chain for every wallet that has ever sent a transaction, creating a massive long-exposure attack surface vulnerable to 'harvest now, decrypt later' quantum attacks via Shor's algorithm. The TON Foundation has not published a quantum risk assessment, PQC migration roadmap, prototype, testnet, or mainnet path. TON's state-integrity layer uses hash-based Merkle proofs (SHA-256) which provides adequate quantum-resistant collision resistance, but this does not protect against the primary quantum attack vector: private key recovery from exposed Ed25519 public keys. TON's architecture (wallet-as-smart-contract, upgradeable system contracts, workchain model) provides genuine structural flexibility for future PQC adoption, but these are architectural properties, not deployed protection. The QRI Score of 13/100 reflects Stage 1 (Quantum Risk Assessed) status: the cryptographic inventory is publicly documented and the quantum risk can be assessed from available evidence, but there is zero production quantum protection across all critical layers. ### Critical quantum blockers - All wallet and transaction spend authorization is Ed25519-only (quantum-vulnerable via Shor's algorithm) with no PQC or hybrid path. - All validator/consensus signatures are Ed25519-only, making consensus finality quantum-vulnerable. - Public keys are exposed on-chain for every wallet that has ever sent a transaction, creating a massive long-exposure 'harvest now, decrypt later' attack surface. - No public PQC migration roadmap, prototype, testnet, or mainnet path exists. - No public quantum risk assessment has been published by the TON Foundation. ### Principal risks - All TON wallets (v1–v5, highload wallets) use Ed25519 signatures exclusively. A CRQC capable of running Shor's algorithm can recover private keys from any on-chain public key, enabling theft of all funds in wallets that have ever broadcast a transaction. - Public keys are permanently exposed on-chain from the moment a wallet sends its first transaction. This is a structural long-exposure vulnerability — keys published today can be collected and decrypted later ('harvest now, decrypt later'). - Consensus (Catchain BFT) relies on Ed25519 validator signatures. A quantum attacker could forge validator signatures to compromise block finality, enabling double-spend attacks or chain reorganization. - The TON Foundation has published no quantum migration roadmap through 2026. The official roadmap at ton.org/roadmap makes no mention of post-quantum cryptography. - No freeze, burn, deprecation, or salvage policy exists for quantum-vulnerable balances in wallets with exposed public keys. Dormant and lost wallets with exposed keys represent irretrievable quantum-vulnerable value. ## TRON (TRX) - Project page: https://qrindex.org/projects/tron/ - Complete report JSON: https://qrindex.org/projects/tron/report.json - Official project website: https://trondao.org - Project type: DPoS smart-contract platform - Evaluated network: mainnet - Evaluated scope: TRON native asset (TRX), DPoS consensus, smart-contract platform, TRC-20 tokens, shielded-transaction privacy layer - QRI score: 3/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, ECC-Only Spend Authorization, ECC-Only Consensus Authentication, Long-Exposure Public Keys, High Value-at-Risk, Shielded-Transaction Privacy Layer Quantum-Vulnerable ### Summary TRON's entire production cryptographic stack relies exclusively on ECDSA secp256k1 for transaction spend authorization, DPoS consensus block signing by 27 Super Representatives, and account key derivation. The network carries approximately $90.9B in stablecoin supply and ~$26B in TVL across ~380M accounts — all protected only by classical elliptic-curve cryptography that is fundamentally vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. Justin Sun announced a PQC roadmap in April 2026 targeting a Q2 2026 testnet and Q3 2026 mainnet deployment of NIST-standardized algorithms (ML-DSA, FN-DSA, SLH-DSA), but as of the evaluation date no formal governance proposal (TIP), technical specification, code, testnet deployment, or mainnet PQC path exists. The shielded-transaction zk-SNARK privacy layer additionally depends on quantum-vulnerable BLS12-381 pairings and Jubjub elliptic curve. The QRI Score of 3 reflects: (1) partial credit in Security Assessment & Evidence Preparedness for publicly documented ECDSA usage and source-code availability, (2) minimal credit in Migration Status for acknowledged but unprotected value-at-risk, (3) minimal credit in Migration Mechanism for a roadmap announcement, and (4) zero credit in Production Cryptographic Protection and Algorithm & Implementation Assurance since no PQC protection exists in production. The score is capped at 20 by Stage 1 (Quantum Risk Assessed) and further limited by the near-zero factor score. ### Critical quantum blockers - All production spend authorization is ECDSA secp256k1-only with no PQC or hybrid path on mainnet — quantum-enabled key recovery from exposed public keys would compromise all user funds. - All 27 Super Representatives sign blocks with ECDSA secp256k1 — quantum compromise of SR keys would enable chain-halting attacks, malicious block production, and consensus failure. - All account addresses are derived from ECDSA public keys via Keccak-256; public keys are exposed on-chain upon first outgoing transaction, creating a near-universal long-exposure attack surface for all active accounts. - Shielded-transaction zk-SNARK proofs rely on BLS12-381 pairings and Jubjub elliptic curve — both are quantum-vulnerable, threatening the privacy guarantees of the TRONZ shielded-transaction system. - No formal cryptographic inventory, quantum threat model, public migration proposal (TIP), PQC code, testnet deployment, or mainnet PQC path exists as of the evaluation date. Only a public statement and roadmap announcement from Justin Sun (April 2026). ### Principal risks - Quantum key-recovery attack on any TRON account that has ever sent a transaction: public keys are exposed on-chain and recoverable via Shor's algorithm, granting an attacker full control of the account and all associated TRX, TRC-20 tokens, and staked assets. - Quantum compromise of one or more Super Representative ECDSA keys: enables malicious block production, transaction censorship, chain reorganization, double-spend attacks, and potential consensus failure across the entire TRON network. - The 27-SR DPoS model concentrates consensus security in a small set of known, long-exposure keys. A targeted quantum attack on a quorum of SRs could halt the chain or finalize fraudulent state. - Shielded-transaction (TRONZ) privacy guarantees rely on zk-SNARK proofs using BLS12-381 pairings and Jubjub curve. A quantum computer could break the soundness of these proofs, deanonymize shielded transfers, and forge valid-looking shielded transactions. - Cross-chain value flow through BTTC and Hyperlane bridges means quantum compromise of TRON could cascade to dependent assets on Ethereum, BSC, and 150+ connected chains, and vice versa. - No migration mechanism, deprecation policy, freeze capability, or emergency governance process exists to protect legacy ECDSA accounts in the event of a quantum breakthrough. All ~380M accounts would need to migrate atomically or risk theft. - The PQC roadmap (Q2 testnet, Q3 mainnet) is an unsubstantiated public statement with no supporting code, TIP, or formal governance. If executed, the ~10x larger PQC signature sizes could materially degrade TRON's throughput (~10M daily transactions), requiring significant protocol redesign not yet addressed publicly. ## TrueUSD (TUSD) - Project page: https://qrindex.org/projects/true-usd/ - Complete report JSON: https://qrindex.org/projects/true-usd/report.json - Official project website: https://tusd.io/ - Project type: stablecoin - Evaluated network: Ethereum (primary), TRON, BNB Smart Chain, Avalanche (native); Polygon, Fantom, Arbitrum, Cronos, Optimism, Aurora (bridged) - Evaluated scope: Fiat-backed ERC-20/TRC-20/BEP-20 stablecoin token with multi-chain native and bridged deployments; token-level evaluation including admin/governance keys, bridge dependencies, and host-chain cryptographic inheritance. - QRI score: 0/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-05 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, ECC-Only, Token Inheritance, Multi-Chain, Stablecoin, No-Quantum-Plan ### Summary TrueUSD (TUSD) is a fiat-collateralized stablecoin with ~$494M market cap deployed as a standard ERC-20/TRC-20/BEP-20 token across multiple host chains. TUSD has no custom cryptography and inherits all transaction security from its host chains (Ethereum, TRON, BNB Smart Chain, Avalanche), all of which rely exclusively on quantum-vulnerable ECDSA for spend authorization. The token's admin functions—including minting, burning, pausing, and contract upgrades—are controlled by classical ECDSA addresses (proxyOwner on Ethereum) with long-exposed public keys. No quantum risk assessment, cryptographic inventory, PQC implementation, migration roadmap, or mitigation design exists. The project scores 0/100 across all five QRI categories. Stage 0 (Unassessed / No Evidence) applies because the project has not published even a basic quantum risk assessment. The ~$494M in circulating value plus admin-controlled supply integrity remain entirely unprotected against quantum key-recovery attacks. The original issuer (Archblock) is in Chapter 11 bankruptcy, and current operator Techteryx has published no quantum-related plans. ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA-only across all host chains (Ethereum, TRON, BNB Smart Chain, Avalanche) with no PQC or hybrid-PQC path. - Token admin keys (proxyOwner upgrade authority, mint/burn/pause functions) are controlled by classical ECDSA addresses with long-exposed public keys on-chain. - No public cryptographic inventory or quantum risk assessment has been published by Techteryx, Archblock, TrueCoin, or any associated entity. - No quantum migration roadmap, PQC implementation, prototype, testnet, or mitigation design exists for any TUSD contract or admin key. - Multi-chain bridged TUSD deployments depend on third-party bridge signer sets that are also ECDSA-only. ### Principal risks - All ~$494M in circulating TUSD value is protected only by ECDSA spend authorization on quantum-vulnerable host chains. A CRQC could recover private keys from exposed public keys and steal funds. - The token admin key (proxyOwner on Ethereum, equivalent admin keys on other chains) is a classical ECDSA address whose public key is permanently exposed on-chain. Compromise would enable unlimited minting of unbacked TUSD, global token freezing, supply destruction, and malicious contract upgrades. - Multi-chain bridged TUSD deployments (Polygon, Fantom, Arbitrum, Cronos, Optimism, Aurora) rely on third-party bridge infrastructure with ECDSA-only signer sets. - No migration path exists. TUSD cannot independently migrate its users to quantum-safe cryptography; it is entirely dependent on host-chain PQC adoption for base-layer protection. - The bankruptcy of Archblock/TrueCoin and the complex ownership history create governance uncertainty that may delay or prevent coordinated quantum-migration action. - TUSD's multi-chain architecture means quantum vulnerability exists on every deployed chain simultaneously. - The absence of any public quantum risk assessment or cryptographic inventory means token holders, exchanges, and custodians cannot evaluate the project's quantum-attack surface without independent analysis. ## Uniswap (UNI) - Project page: https://qrindex.org/projects/uniswap/ - Complete report JSON: https://qrindex.org/projects/uniswap/report.json - Official project website: https://www.coingecko.com/en/coins/uniswap - Project type: DeFi protocol token - Evaluated network: Ethereum - Evaluated scope: UNI ERC-20 governance token, Uniswap DAO treasury multisigs, governance contracts, and Unichain L2 staking dependencies on Ethereum mainnet as of 2026-06-06. Standard ERC-20 token transfers inherit Ethereum L1 QRI score per QRI Token Inheritance rule (Section 7.2). Token-specific admin/governance keys and treasury multisigs are evaluated separately. - QRI score: 6.5/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection, Token Inheritance: Ethereum L1 ### Summary Uniswap (UNI) is a standard ERC-20 governance token on Ethereum. Per QRI Token Inheritance rules (Section 7.2), UNI inherits Ethereum L1's quantum-readiness posture for base-layer token transfers — Ethereum has no production PQC protection as of 2026-06-06 and is rated QRI ~25/100 (Stage 2: Mitigation/Development) with a structured roadmap targeting ~2029 for core PQ infrastructure. Token-specific evaluation reveals critical quantum vulnerabilities: the Uniswap governance DAO and treasury multisigs (~$3B+ in protocol-controlled assets) rely exclusively on ECDSA keys, exposing them to quantum key-recovery attacks. The Unichain L2 Validation Network adds further quantum-vulnerable dependencies through Ethereum-based UNI staking. On the positive side, Uniswap V3 Core contracts are immutable (limiting what a compromised governance can modify), and ERC-1271 support allows users with PQ smart-contract wallets to interact with the protocol. However, Uniswap itself has published no quantum risk assessment, no cryptographic inventory, no PQC migration roadmap, and no quantum-specific incident response process. The overall QRI Score of 7 reflects near-total absence of quantum readiness, with third-party evidence of quantum risk being the only credit earned. ### Critical quantum blockers - Uniswap governance and treasury multisigs are secured exclusively by ECDSA keys on Ethereum, exposing approximately $3B+ in protocol-controlled assets to quantum key-recovery attacks. - All UNI token transfers rely on Ethereum's ECDSA (secp256k1) spend authorization, which is vulnerable to Shor's algorithm. This is an inherited vulnerability from Ethereum L1, which has no production PQC protection as of 2026-06-06. ### Principal risks - Governance treasury theft: A quantum attacker recovering ECDSA private keys of Uniswap governance multisig signers could drain ~$3B+ in protocol-controlled assets from the treasury. - Protocol parameter manipulation: Compromised governance could modify fee switches, Unichain parameters, and V4 hook configurations to extract value or disrupt protocol operations. - Harvest-now-decrypt-later: All historical Uniswap governance transactions have exposed signer public keys on-chain. These are permanently recorded and can be harvested today for future quantum decryption. - Cross-chain contagion: Bridged UNI on Arbitrum, Optimism, Base, and other chains inherits both the bridge operator's quantum risk and the destination chain's quantum risk. - No migration path: There is no public plan, timeline, or mechanism for migrating Uniswap governance, treasury, or staking to post-quantum signature schemes. - Dependency on Ethereum timeline: Even if Uniswap governance were to migrate to PQ signatures tomorrow, all UNI token transfers would remain quantum-vulnerable until Ethereum L1 deploys production PQC protection (currently targeted ~2029 at earliest). ## United Stables (U) - Project page: https://qrindex.org/projects/united-stables/ - Complete report JSON: https://qrindex.org/projects/united-stables/report.json - Official project website: https://www.coingecko.com/en/coins/united-stables - Project type: cryptoasset - Evaluated network: Ethereum, BNB Chain - Evaluated scope: Standard ERC-20/BEP-20 stablecoin token on Ethereum and BNB Chain, including token-specific admin/mint key controls and EIP-3009 signature-based transfer path. Host-chain consensus, P2P, and base-layer security inherited per QRI Section 7.2. - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, Classical-Only, Inherits L1 Risk, EIP-3009 ECDSA ### Summary United Stables ($U) is a USD-pegged stablecoin deployed as a standard ERC-20/BEP-20 token on BNB Chain and Ethereum, backed 1:1 by fiat and stablecoin reserves. As of the evaluation date (2026-06-06), the project has performed zero identifiable quantum readiness work: no public cryptographic inventory, no quantum threat model, no PQC or hybrid-PQC implementation, no migration roadmap, and no quantum-specific governance or incident-response processes. All cryptographic operations — including standard transaction signing, EIP-3009 gasless transfers, admin/mint key authorization, and proxy upgrade authority — rely exclusively on classical ECDSA (secp256k1). The token inherits the classical quantum vulnerabilities of both host chains (BNB Chain and Ethereum). With ~$1.07B in circulating market cap and ~$1.01B fully diluted valuation, the quantum-exposed value-at-risk is material. The QRI Score of 0 reflects zero earned points across all five scoring categories, bound by a Readiness & Risk Cap of 10 (no public cryptographic inventory). The project is classified at Stage 1 (Quantum Risk Assessed) because the quantum vulnerability is readily assessable from public mainnet evidence, even though the project itself has published no quantum assessment. ### Critical quantum blockers - No public cryptographic inventory: the project has not published any quantum threat model, cryptographic inventory, or quantum risk assessment (Readiness & Risk Cap: 10). - Active production spend authorization remains entirely ECDSA-only via host-chain transaction signatures and token-specific EIP-3009 gasless transfer signatures (Readiness & Risk Cap: 40). - Token supply integrity depends on admin/mint keys secured by classical ECDSA EOAs; a quantum attacker could plausibly forge minting transactions and inflate supply (Readiness & Risk Cap: 60). - Users can only create new quantum-vulnerable accounts by default; no PQ/hybrid account creation path exists (Readiness & Risk Cap: 60). - No public migration roadmap, prototype, testnet, or mainnet PQC support of any kind (Readiness & Risk Cap: 25). ### Principal risks - SUPPLY INFLATION RISK: Admin/mint keys and proxy upgrade authority are secured by classical ECDSA EOAs. A quantum adversary capable of recovering private keys from exposed public keys could forge minting transactions, inflate the token supply arbitrarily, and destroy the 1:1 backing guarantee. The exact cryptographic control structure (multisig type, threshold, key custody) is not publicly documented, making this a quantum-critical uncertainty. - SPEND AUTHORIZATION RISK: All token transfers — including EIP-3009 gasless, signature-based transfers — rely on secp256k1 ECDSA. A quantum attacker could recover private keys from any address that has ever sent a transaction (long-exposure attack window) and drain those holdings. - HOST CHAIN DEPENDENCY: The token inherits the quantum vulnerabilities of both BNB Chain and Ethereum L1s. Neither host chain has production PQC protection as of the evaluation date. Any quantum compromise of either host chain's consensus, finality, or state integrity would directly threaten all $U token balances on that chain. - NO MIGRATION PATH: There is zero evidence of any quantum migration design, prototype, testnet, or roadmap. Users, exchanges, and custodians have no mechanism to protect their holdings from quantum attack. The freeze capability in the contract could theoretically support future migration enforcement, but no such plan exists. - VALUE-AT-RISK: Approximately $1.07B in circulating market cap (as of June 2026) is entirely quantum-vulnerable with no protection, migration path, or recovery mechanism. All ~1.01B tokens in total supply are exposed. - GOVERNANCE CAPTURE RISK: The board of directors currently controls parameter adjustments. If governance keys are classical EOAs (as appears from on-chain evidence), a quantum attacker could capture governance, change contract parameters, and potentially drain or freeze assets arbitrarily. ## USD1 (USD1) - Project page: https://qrindex.org/projects/usd1-wlfi/ - Complete report JSON: https://qrindex.org/projects/usd1-wlfi/report.json - Official project website: https://www.coingecko.com/en/coins/usd1-wlfi - Project type: cryptoasset - Evaluated network: Multi-chain (Ethereum, BNB Chain, Solana, Tron, Aptos, AB Core) - Evaluated scope: Multi-chain fiat-backed stablecoin token (ERC-20/BEP-20/SPL equivalents), including admin/governance keys, bridge dependencies, and custody paths - QRI score: 1/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Token Inheritance, Classical Only ### Summary USD1 is a multi-chain fiat-backed stablecoin issued by World Liberty Financial (WLFI) and custodied by BitGo, deployed as a standard ERC-20/BEP-20/SPL token across Ethereum, BNB Chain, Solana, Tron, and other networks. It has zero quantum-resistant cryptographic protection at any layer. All on-chain spend authorization inherits classical ECDSA/EdDSA from host chains. The upgradeable proxy admin is controlled by a classical Gnosis Safe multisig. Chainlink CCIP cross-chain bridging relies on classical oracle signatures. BitGo custody uses classical MPC in production (a PQ MPC simulation was completed in May 2026 but is not in production). No public cryptographic inventory, quantum threat model, migration roadmap, or PQC implementation exists. The project earns minimal points solely from having identifiable on-chain value-at-risk. The QRI Score of 1 reflects that quantum readiness has not been assessed or implemented by the project; the custodian's PQ MPC simulation is a Stage 2 signal but does not yet protect any production assets. Users and institutions should monitor BitGo's PQ MPC development and any WLFI-published quantum risk assessment. ### Critical quantum blockers - No public cryptographic inventory or quantum risk assessment exists for the token or its issuance/custody infrastructure (Readiness & Risk Cap: max QRI 10) - Active production spend authorization remains entirely ECDSA/EdDSA/BLS-only via host chains (Readiness & Risk Cap: max QRI 40) - Upgradeable proxy admin keys controlled by classical Gnosis Safe multisig represent long-exposure quantum vulnerability for supply integrity - Chainlink CCIP cross-chain bridge relies on classical oracle signatures; quantum compromise could allow unauthorized cross-chain minting - BitGo custody and minting workflows rely on classical MPC/multisig with no production PQ protection ### Principal risks - Quantum-critical vulnerability: All circulating USD1 is secured by host-chain classical ECDSA/EdDSA signatures. Any Ethereum EOA that has sent a USD1 transfer has an exposed public key vulnerable to offline quantum key-recovery attacks. - Quantum-critical vulnerability: The proxy admin (Gnosis Safe multisig) controls contract upgradeability. Quantum compromise of admin signers' classical ECDSA keys could allow an attacker to upgrade the token contract to a malicious implementation capable of unlimited minting or global fund freezing. - Quantum-critical vulnerability: Chainlink CCIP bridge signers use classical cryptographic signatures. A quantum-capable adversary compromising the CCIP oracle network could mint unauthorized USD1 on destination chains, breaking the 1:1 backing invariant. - Quantum-critical vulnerability: BitGo's production custody and mint/redemption workflow relies on classical MPC. Although a PQ MPC simulation was completed in May 2026, production keys remain classically protected. Compromise could enable unauthorized minting or reserve theft. - No migration, freeze, deprecation, or burn policy exists to address quantum-vulnerable accounts or admin keys. If a quantum attack becomes feasible, there is no documented mechanism to protect or recover user funds. ## USDC (USDC) - Project page: https://qrindex.org/projects/usd-coin/ - Complete report JSON: https://qrindex.org/projects/usd-coin/report.json - Official project website: https://www.circle.com/en/usdc - Project type: stablecoin - Evaluated network: Multi-chain (34+ host blockchains, primarily Ethereum) - Evaluated scope: USDC stablecoin token across all production host chains, including token-specific admin/governance keys and CCTP bridge attestation. Host-chain user transaction signatures are inherited per QRI §7.2 Token Inheritance. Arc L1 blockchain is excluded as a separate project not in production scope. - QRI score: 10/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, PQ-Recoverable, Token Inheritance ### Summary USDC scores 10/100 (QRI Stage 2: Mitigation / Development). Circle has published an exemplary post-quantum security whitepaper (May 2026) with comprehensive cryptographic inventory, threat modeling, phased migration strategy, and recovery framework designs — earning full credit for Security Assessment & Evidence Preparedness (5/5). However, zero production PQ protection exists for any token-specific function. All admin key authorization (MasterMinter, Blacklister, proxy-admin, Owner, Pauser) and CCTP bridge attestation remain entirely ECDSA-only. Multiple admin keys have exposed on-chain public keys, creating material long-exposure quantum-vulnerable value-at-risk across ~$76.5B in circulation. User transaction signatures inherit host-chain quantum vulnerability. The Arc L1 blockchain (separate project) plans native PQ support but does not protect current USDC. The whitepaper's proposed dual-signature contract upgrades and recovery frameworks are roadmap items with no production deployment. Score is capped at 40 by the Readiness & Risk Cap (active production spend authorization entirely ECC-only) but the raw Factor Score of ~10 is the binding constraint. ### Critical quantum blockers - ECDSA-only admin key authorization: MasterMinter, Blacklister, Pauser, proxy-admin, and Owner roles rely entirely on ECDSA signatures. Compromise of MasterMinter enables unlimited unbacked minting (~$76.5B value-at-risk). Multiple admin keys have exposed public keys from historical on-chain transactions. - CCTP bridge attestation uses ECDSA m-of-n multisig: Circle's Cross-Chain Transfer Protocol V2 attestation service signs cross-chain minting authorizations with 65-byte ECDSA signatures. A quantum attacker breaking attester keys could forge mint attestations on destination chains. - No production PQ or hybrid-PQ protection exists for any token-specific cryptographic function. User transaction authorization inherits host-chain quantum vulnerability (ECDSA/Ed25519 on Ethereum, Solana, etc.). ### Principal risks - MasterMinter key compromise via quantum attack enables unlimited unbacked USDC minting, directly threatening the 1:1 USD peg and ~$76.5B in circulation. - CCTP attester key compromise enables forged cross-chain mint attestations, allowing an attacker to mint USDC on destination chains without corresponding source-chain burns. - Blacklister key compromise enables targeted or widespread freezing of exchange hot wallets, DeFi protocols, and institutional holdings, causing systemic market disruption. - Proxy-admin multisig compromise (requiring multiple Shor runs but offering total control) enables deployment of malicious implementation contracts that could steal or manipulate all USDC balances. - Multiple admin role addresses (Blacklister, Owner, Pauser, MasterMinter controller owner) have been single EOAs with exposed public keys, making them the cheapest quantum targets. - USDC inherits host-chain quantum vulnerability for all user transactions across 34+ blockchains. Users on quantum-vulnerable host chains cannot protect their USDC holdings through token-level mechanisms. - Circle cannot unilaterally fix ecrecover dependency; it requires host-chain hard forks. Immutable third-party contracts using ecrecover cannot be upgraded. - The PQ roadmap's recovery frameworks depend on future regulatory guidance, ZK-proof systems not yet production-ready, and TEE infrastructure that is still in development on Arc. ## USDD (USDD) - Project page: https://qrindex.org/projects/usdd/ - Complete report JSON: https://qrindex.org/projects/usdd/report.json - Official project website: https://www.coingecko.com/en/coins/usdd - Project type: stablecoin - Evaluated network: TRON, Ethereum, BNB Chain - Evaluated scope: USDD stablecoin token across all deployed chains, including token-specific admin/governance keys and host-chain inherited risk - QRI score: 1/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Not Assessed, ECC-Only, Token Inherits Host Chain Risk, Roadmap Only (TRON host chain), Centralized Governance Risk ### Summary USDD is a ~$1.4B market-cap stablecoin deployed as a standard TRC-20/ERC-20/BEP-20 token across TRON, Ethereum, and BNB Chain. It inherits the quantum vulnerability of all three host chains, each of which uses ECDSA secp256k1 for transaction signatures with no post-quantum protection in production. Additionally, USDD's minting authority, collateral custody, and protocol governance are controlled by the TRON DAO Reserve through a 5-of-7 multisig and classical admin contracts (DSPauseProxy, GovActionsProxy)—all secured by quantum-vulnerable ECDSA keys. Compromise of these keys would enable unlimited minting, collateral extraction, and protocol destruction. TRON announced a PQC initiative in April 2026, but as of the evaluation date no formal proposal, code, testnet, or documentation exists. USDD itself has published no cryptographic inventory, quantum risk assessment, or migration plan. QRI Score: 1/100 (Stage 0). ### Critical quantum blockers - Active production spend authorization and token admin/governance keys remain entirely ECC-only (ECDSA secp256k1) across all host chains (TRON, Ethereum, BNB Chain). Cap: 40. - No public cryptographic inventory or quantum risk assessment exists for the protocol. Cap: 10. - Material long-exposure quantum-vulnerable value (~$1.4B circulating across all chains) exists with no migration, freeze, deprecation, burn, or recovery path. Cap: 55. ### Principal risks - Host-chain quantum vulnerability: All three host chains (TRON, Ethereum, BNB Chain) use ECDSA-only spend authorization. A quantum adversary capable of running Shor's algorithm could recover private keys from exposed public keys and drain any USDD balance held in a transacted account. - Admin key compromise: The TRON DAO Reserve controls USDD minting, collateral, and protocol parameters via a 5-of-7 ECDSA multisig. Quantum compromise of 5 of 7 signer keys would grant full control over USDD supply, collateral reserves, and protocol configuration. - Cross-chain attack surface: USDD circulates on TRON (~$1.14B), Ethereum (~$270M), and BNB Chain (~$16M) through bridge contracts. A quantum attack on any host chain's bridge or admin contracts could disrupt cross-chain parity, enable double-spend minting, or drain bridge reserves. - No migration path: There is no mechanism for USDD holders, the TDR multisig, or protocol governance to migrate to quantum-resistant cryptography. If Q-Day arrives before migration infrastructure exists, all ~$1.4B in USDD value is at immediate risk with no recourse. - Governance centralization amplifies quantum risk: The decommissioning of the DAO governance portal means all protocol authority is concentrated in a small set of ECDSA keys. This reduces the attack surface for quantum adversaries to as few as 5 keys (the multisig threshold). - No quantum risk acknowledgment: USDD's official documentation, whitepaper, and public communications contain zero mention of quantum computing threats, cryptographic vulnerabilities, or migration planning. ## USDS (USDS) - Project page: https://qrindex.org/projects/usds/ - Complete report JSON: https://qrindex.org/projects/usds/report.json - Official project website: https://sky.money/ - Project type: stablecoin - Evaluated network: Ethereum, Solana, Base, Avalanche (multi-chain via SkyLink/LayerZero) - Evaluated scope: USDS stablecoin token across all deployed chains, including governance/admin keys and SkyLink/LayerZero bridge infrastructure - QRI score: 4.89/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, ECC-Only, Inherits L1 Score (Ethereum), Bridge-Dependent, No Quantum Roadmap, Classical Governance, Upgradeable Proxy ### Summary USDS is the flagship stablecoin of Sky Protocol (formerly MakerDAO), deployed as an ERC-20 token on Ethereum with cross-chain bridges to Solana, Base, and Avalanche via SkyLink (LayerZero V2). The project has conducted zero quantum-related work: no cryptographic inventory, no quantum risk assessment, no PQ migration roadmap, and no production or testnet PQ cryptography. All spend authorization relies on Ethereum L1's ECDSA (secp256k1), all governance actions use classical Ethereum signatures via Sky DAO, and the SkyLink/LayerZero bridge infrastructure is entirely classical. ChainSecurity and Cantina audits exist but are classical-only with no quantum scope. The project inherits Ethereum L1's quantum vulnerability for base transactions, while adding independent quantum-vulnerable attack surfaces through its upgradeable proxy governance and multi-chain bridge dependencies. The QRI Score of 4.89 reflects Stage 0 (Unassessed / No Evidence): the project has not acknowledged quantum risk, published any cryptographic inventory, or taken any steps toward quantum readiness. Ethereum L1's structured post-quantum program (targeting ~2029) is a future dependency, not current protection, and does not address USDS-specific governance, admin keys, or bridge infrastructure. ### Critical quantum blockers - No public cryptographic inventory or quantum risk assessment exists for USDS or Sky Protocol — the project has not published any inventory of critical public-key mechanisms, attack assumptions, affected assets, or affected layers. - All spend authorization is ECDSA-only — USDS inherits Ethereum L1's secp256k1 ECDSA for all transaction signatures. Any account that has sent a transaction has its public key exposed on-chain, making it vulnerable to Shor's algorithm. - Governance/admin keys rely entirely on classical Ethereum signatures — the ERC1967Proxy admin, Sky DAO executive spells, PauseProxy, and all privileged roles use classical ECDSA with no PQ migration path. - SkyLink/LayerZero bridge infrastructure uses classical cryptography — the bridge's DVN (Decentralized Verifier Network), Executor, governance relay, and OFT adapter all depend on classical cryptographic assumptions with no documented PQ migration plan. - Two-way bridge allows unrestricted value flow between quantum-vulnerable systems — USDS flows between Ethereum, Solana, Base, and Avalanche via classical bridge infrastructure, creating multiple quantum-vulnerable attack surfaces. ### Principal risks - QUANTUM-CRITICAL: All USDS spend authorization is ECDSA-only. A quantum computer capable of running Shor's algorithm on secp256k1 could derive private keys from any exposed public key (i.e., any address that has ever sent a transaction), enabling theft of all USDS held by those addresses. - QUANTUM-CRITICAL: The ERC1967Proxy admin key controls the USDS token implementation. Compromise of the proxy admin's ECDSA private key via quantum attack would allow an attacker to upgrade the contract to a malicious implementation, potentially draining all USDS or minting unlimited tokens. - QUANTUM-CRITICAL: Sky DAO governance (executive votes, spell execution, PauseProxy) uses classical ECDSA. A quantum attacker compromising sufficient governance keys could pass malicious governance proposals, upgrade contracts, drain surplus buffers, or brick the protocol. - QUANTUM-CRITICAL: The SkyLink/LayerZero bridge uses classical cryptography for its DVN (Decentralized Verifier Network), Executor, and governance relay. A quantum attacker could forge cross-chain messages to mint unbacked USDS on destination chains or steal escrowed collateral. - QUANTUM-CRITICAL: Two-way bridge paths allow unrestricted value flow between quantum-vulnerable systems. An attacker compromising one chain's bridge verification could potentially drain USDS across multiple chains. - QUANTUM-UNCERTAINTY: The exact signer set, threshold, and key management for SkyLink/LayerZero bridge components (DVN, Executor, governance relay) are not publicly documented, making independent quantum risk assessment of bridge infrastructure incomplete. - LONG-EXPOSURE: All Ethereum EOAs that have sent USDS transactions have exposed their public keys on-chain. These represent 'harvest now, decrypt later' targets — an adversary can record exposed public keys today and derive private keys once a sufficiently powerful quantum computer exists. - NO MIGRATION PATH: No freeze, deprecation, burn, or migration mechanism exists for quantum-vulnerable USDS balances. Dormant accounts, lost keys, and unresponsive holders have no policy path to protection. ## USDtb (USDTB) - Project page: https://qrindex.org/projects/usdtb/ - Complete report JSON: https://qrindex.org/projects/usdtb/report.json - Official project website: https://www.coingecko.com/en/coins/usdtb - Project type: cryptoasset - Evaluated network: Ethereum (primary), Arbitrum, Solana, Base (via LayerZero OFT) - Evaluated scope: USDtb ERC-20/OFT stablecoin token including admin keys, minting authority, and LayerZero bridge dependencies - QRI score: 1.5/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token, Inherits L1 Score (Ethereum), Classical Cryptography, No PQC Roadmap, Bridge-Dependent (LayerZero OFT), Stablecoin, Upgradeable Contract, Single Admin Key ### Summary USDtb is a fiat-backed stablecoin (ERC-20 / LayerZero OFT) issued by Anchorage Digital Bank under the GENIUS Act, with reserves held in BlackRock's BUIDL fund. It has no post-quantum cryptographic protection whatsoever. All spend authorization relies on classical ECDSA (secp256k1 on Ethereum, ed25519 on Solana). The upgradeable contract is controlled by a single ECDSA admin key — now held by Anchorage Digital — whose compromise via quantum attack would enable unlimited minting. Cross-chain transfers depend on LayerZero OFT, which uses classical cryptography for message verification. The project has not published a quantum risk assessment, cryptographic inventory, or post-quantum migration roadmap. Standard Web3 audits confirm general smart contract safety but do not assess quantum resistance. The QRI Score of 1.5 reflects: minimal project-published quantum assessment (Category 1: 0.5/5), no production PQC protection (Category 2: 0/35), negligible value-at-risk coverage (Category 3: 1/25), no migration mechanisms (Category 4: 0/15), and no algorithm assurance (Category 5: 0/20). The score is capped at Stage 1 (Quantum Risk Assessed, max 20) and further by the Readiness & Risk Cap of 20 (no credible mitigation design). The binding constraint is the factor score itself at 1.5. ### Critical quantum blockers - All spend authorization is ECDSA (secp256k1 on Ethereum, ed25519 on Solana) — fully quantum-vulnerable. A quantum attacker could derive private keys from exposed public keys of any transacted address and steal tokens. - The USDtb contract admin key (now held by Anchorage Digital Bank) relies on ECDSA. Compromise via quantum attack would allow an attacker to upgrade the proxy contract, change the admin, add/remove minters, and mint unlimited unbacked tokens. - LayerZero OFT cross-chain message verification relies on classical cryptographic assumptions. A quantum attacker could forge cross-chain messages to mint or redirect USDtb on destination chains. - No quantum risk assessment, cryptographic inventory, or post-quantum migration roadmap has been published by Ethena Labs or Anchorage Digital. - USDtb minting authority uses EIP-712 signed orders (ECDSA) for the RFQ-based mint/redeem system. Quantum compromise of a benefactor or delegate signer key would allow unauthorized minting of USDtb. ### Principal risks - QUANTUM-CRITICAL: ECDSA spend authorization on all host chains (Ethereum secp256k1, Solana ed25519) means any address that has ever sent a transaction has an exposed public key vulnerable to offline quantum attack via Shor's algorithm. - QUANTUM-CRITICAL: Single ECDSA admin key (Anchorage Digital) controls contract upgrades, minter management, transfer state, and token redistribution. Quantum compromise = infinite unbacked minting + global fund freeze/seizure. - QUANTUM-CRITICAL: LayerZero OFT bridge message verification is classically secured. A quantum attacker compromising a relayer or endpoint could forge cross-chain mint/unlock instructions on Arbitrum, Solana, or Base. - QUANTUM-CRITICAL: EIP-712 signed mint/redeem orders use ECDSA. Quantum compromise of a benefactor or delegate signer key allows unauthorized minting. - OPERATIONAL: CVE-2026-9999 in LayerZero OFT v2.4.1 enables silent cross-chain recipient rerouting (classical attack). ~37% of OFT integrations exposed; USDtb's specific OFT version is unconfirmed. - OPERATIONAL: Anchorage Digital's two-tier holder model means non-Client token holders have no direct contractual redemption rights with the issuer. During a quantum incident, non-Clients may face additional barriers to exit. - CONCENTRATION RISK: ~$1.44B market cap with 0% quantum protection. The entire supply is quantum-vulnerable. Large holders include Ethena's own USDe backing contracts, Aave Core market (~128M tokens), and unknown exchange/custodian wallets. ## Usual USD (USD0) - Project page: https://qrindex.org/projects/usual-usd/ - Complete report JSON: https://qrindex.org/projects/usual-usd/report.json - Official project website: https://www.coingecko.com/en/coins/usual-usd - Project type: stablecoin - Evaluated network: Ethereum, Arbitrum, Base, BNB Chain - Evaluated scope: ERC-20 RWA-backed stablecoin token (USD0) including token-specific admin/governance keys, bridge dependencies (Chainlink CCIP, LayerZero), and RWA collateral dependency chain. Host-chain quantum risk is inherited from Ethereum and respective L1/L2 chains. - QRI score: 2/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: High - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, Inherits L1 Risk, Classical ECC Only, Token (ERC-20), Stablecoin, RWA-Backed, Multi-Chain, Upgradable Proxy, Classical Bridge Dependencies ### Summary Usual USD (USD0) is a ~$562M market cap RWA-backed ERC-20 stablecoin deployed across Ethereum, Arbitrum, Base, and BNB Chain. The QRI evaluation finds no evidence of quantum readiness: no public cryptographic inventory, no quantum risk assessment, no post-quantum cryptography implementation, and no quantum migration roadmap. All spend authorization is ECDSA-only (inherited from host EVM chains). Token-specific admin/governance keys are controlled by a 5/9 ECDSA multisig without timelock. Cross-chain infrastructure (Chainlink CCIP, LayerZero) and RWA collateral dependencies (Hashnote USYC, BlackRock BUIDL, Circle USDC, etc.) all rely on classical cryptography. The 20+ classical security audits provide strong classical assurance but no quantum-specific review. The project receives a QRI Score of 2 (Stage 1: Quantum Risk Assessed). The protocol has not publicly acknowledged quantum computing as a risk to its security model. ### Critical quantum blockers - No public cryptographic inventory or quantum threat model published — the protocol has not acknowledged quantum risk in any public documentation. - All token spend authorization is ECDSA-only, inherited from host EVM chains (Ethereum, Arbitrum, Base, BNB Chain) — none of which are quantum-ready as of June 2026. - Admin/governance keys (5/9 Usual Multisig) are standard ECDSA with no timelock — complete control over minting, burning, pausing, blacklisting, upgrades, and collateral parameters. A quantum attacker compromising these keys could mint unlimited unbacked USD0. - Cross-chain bridge infrastructure (Chainlink CCIP, LayerZero) relies entirely on classical cryptography. A quantum compromise could drain bridge liquidity or forge cross-chain messages affecting USD0 supply integrity. - RWA collateral dependency chain (Hashnote USYC, M0, Ethena USDtb, BlackRock BUIDL, Ondo OUSG, Circle USDC, Spiko USTBL) is entirely on classical cryptography. Quantum compromise of any underlying token's admin keys or host chain could depeg or drain USD0 backing. - No post-quantum cryptography migration roadmap, plan, prototype, or research acknowledgment exists for USD0 or the Usual Protocol. - No quantum-specific incident response process or emergency governance procedure is documented. ### Principal risks - QUANTUM-CRITICAL: A sufficiently powerful quantum computer running Shor's algorithm could derive private keys for all EOA addresses that have ever sent USD0 transactions, enabling theft of all user-held USD0. - QUANTUM-CRITICAL: The 5/9 ECDSA admin multisig controls all privileged functions (minting, burning, pausing, blacklisting, upgrades, collateral parameters). Quantum compromise of the multisig would give an attacker unlimited minting power, the ability to drain all protocol-controlled collateral, and control over cross-chain USD0 supply. - QUANTUM-CRITICAL: Chainlink CCIP and LayerZero bridge infrastructure relies on classical ECDSA/BLS signatures. Quantum compromise of bridge signer sets could enable forged cross-chain messages, unauthorized minting of USD0 on destination chains, or draining of bridge liquidity pools. - QUANTUM-CRITICAL: USD0 is backed by a chain of RWA token wrappers (USYC, M, USDtb, BUIDL, OUSG, USDC, USTBL) — all on classical cryptography. Quantum compromise of any underlying token's admin keys could depeg or destroy the collateral backing of USD0. - QUANTUM-CRITICAL: The protocol uses Chainlink Price Feeds and Proof of Reserve which rely on classical oracle node operator signatures. Quantum compromise of oracle signers could feed false price data or reserve attestations, enabling minting of unbacked USD0. - OPERATIONAL: The 5/9 multisig lacks a timelock on admin functions, meaning a quantum attacker who compromises the multisig could execute malicious upgrades or mint unbacked tokens instantly with no window for intervention. - STRUCTURAL: USD0's TransparentUpgradeableProxy pattern means the implementation contract can be replaced by the admin. A quantum-compromised admin could deploy a malicious implementation that drains all user-approved allowances or alters token behavior retroactively. ## USX (USX) - Project page: https://qrindex.org/projects/usx/ - Complete report JSON: https://qrindex.org/projects/usx/report.json - Official project website: https://solstice.finance/ - Project type: stablecoin - Evaluated network: Solana - Evaluated scope: USX SPL token (contract 6FrrzDk5mQARGc1TDYoyVnSyRdds1t4PbtohCD6p3tgG) on Solana mainnet, including token-specific admin/governance keys. Evaluation inherits Solana L1 QRI per Section 7.2 Token Inheritance. - QRI score: 9.79/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Partial Protection, Token Inheritance, SPL Token, Solana-Dependent, Quantum Risk Acknowledged ### Summary USX is a standard Solana SPL stablecoin token issued by Solstice Finance with $501M+ TVL. It inherits Solana's quantum-vulnerable Ed25519 signature scheme for all user spend authorization and address exposure. Token-specific strengths include PDA-controlled minting (quantum-resistant by design since PDAs use SHA-256 hashing with no private keys) and claimed non-upgradeable token programs. However, the Squads 3/5 multisig that governs program upgrades, parameter changes, and emergency operations relies entirely on Ed25519 signer keys — a token-specific quantum-critical vulnerability. Solstice Finance has published no quantum risk assessment, cryptographic inventory, migration roadmap, or PQ implementation of its own. The QRI Score of 10 reflects a project where quantum risk is acknowledged only through Solana L1 inheritance, with no meaningful project-level production protection. Users should monitor Solana's Falcon migration progress and Solstice Finance's admin key migration status. ### Critical quantum blockers - All spend authorization for USX token transfers relies on Solana's Ed25519 signature scheme, which is vulnerable to Shor's algorithm (quantum-critical vulnerability, inherited from Solana L1). - USX program governance uses a Squads 3/5 multisig whose signers use Ed25519 keypairs. A quantum adversary could derive signer private keys and compromise governance, enabling unauthorized program upgrades, parameter changes, or emergency fund movements (quantum-critical vulnerability, token-specific). - No project-specific quantum risk assessment, cryptographic inventory, or migration plan has been published by Solstice Finance for USX (quantum-critical uncertainty). ### Principal risks - Quantum key-recovery attack on USX holder Ed25519 private keys (inherited from Solana): A sufficiently powerful quantum computer running Shor's algorithm could derive private keys from on-chain public keys, enabling theft of all USX balances from addresses that have signed transactions. Over 60% of funded Solana addresses have made at least one outgoing transaction, exposing their public keys on-chain (long-exposure attack surface). - Quantum compromise of Squads 3/5 multisig signers: An attacker who derives the private keys of 3 out of 5 multisig signers could unilaterally execute administrative actions including program upgrades (if upgradeable), configuration parameter changes, whitelist modifications, collateral token registration changes, custodian authorization changes, and emergency fund movements. This represents a supply-integrity and treasury-drain risk specific to USX. - Program upgrade authority uncertainty: The security page claims 'non-upgradeable SPL programs' while the smart contracts documentation states 'Program upgrade authority held by multi-sig wallet.' If the USX Program is upgradeable, the quantum-vulnerable multisig creates a direct path to program compromise. If non-upgradeable, the risk is limited to operational parameter manipulation. - No project-level quantum migration plan: Even when Solana L1 deploys Falcon signatures, USX-specific admin keys, whitelisted accounts, and multisig signers would require separate migration. No plan, timeline, or commitment exists for this. - Off-chain collateral custody (Copper, Ceffu) introduces additional quantum risk surface for the assets backing USX, though this is outside the on-chain token evaluation scope. ## Venice Token (VVV) - Project page: https://qrindex.org/projects/venice-token/ - Complete report JSON: https://qrindex.org/projects/venice-token/report.json - Official project website: https://www.coingecko.com/en/coins/venice-token - Project type: AI network token - Evaluated network: Base (Ethereum L2 / OP Stack) - Evaluated scope: ERC-20 utility token on Base L2; evaluation covers token-specific admin/governance keys and inherited Base/Ethereum L2 cryptographic posture per QRI Section 7.2 Token Inheritance - QRI score: 3/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance, Standard ERC-20, Centralized Admin Keys, Quantum-Vulnerable Admin, Not Assessed ### Summary Venice Token (VVV) is a standard ERC-20 utility token on Base (Ethereum L2 / OP Stack) with no post-quantum cryptographic protection at any layer. Per QRI Section 7.2 Token Inheritance, VVV inherits Base/Ethereum's entirely classical (ECDSA/BLS/KZG) cryptographic posture for spend authorization, consensus, and state integrity. The token has a critical token-specific quantum vulnerability: the contract owner is a single classical ECDSA EOA with unlimited, uncapped mint authority and no timelock, multisig, or governance controls. A quantum adversary recovering this key could mint unlimited tokens, compromising the entire supply. The sVVV staking contract is an upgradeable proxy with classical admin keys, creating an additional quantum-vulnerable attack surface. Base/OP Stack has published a 10-year PQ roadmap (January 2026) to deprecate ECDSA EOAs by 2036, and Ethereum has a dedicated PQ research team targeting ~2029 for core infrastructure, but no PQ protection is live on mainnet as of June 2026. The token has no PQ-specific assessment, migration plan, or implementation. The only scored credit is for the verified open-source contract code on BaseScan. Overall QRI Score: 3/100 (Stage 0: Unassessed / No Evidence). ### Critical quantum blockers - VVV token mint authority controlled by single classical ECDSA key (likely EOA, no multisig label on BaseScan, no timelock) — quantum key-recovery would enable unlimited unauthorized minting of ~$690M market-cap token - sVVV staking proxy upgrade authority controlled by classical ECDSA key — quantum compromise enables malicious contract upgrade affecting all staked VVV - All spend authorization (token transfers) is entirely ECDSA-based, inherited from Base/Ethereum — no PQ or hybrid protection exists on mainnet - No cryptographic inventory, quantum threat model, or risk assessment published for token-specific admin/governance key surface ### Principal risks - Token owner key (single classical ECDSA EOA) can be compromised by quantum key recovery to mint unlimited tokens, destroying supply integrity - sVVV staking proxy admin keys can be compromised to upgrade the staking contract maliciously, potentially draining staked funds - All VVV holder accounts on Base use classical ECDSA spend authorization — vulnerable to quantum key recovery once public keys are exposed on-chain - No migration path exists for token-specific admin keys or for Base/Ethereum base-layer accounts - Base/Ethereum PQ migration timeline extends to 2029-2036, leaving a multi-year window of quantum vulnerability - Trust Security audit claim is unverifiable, leaving implementation assurance gaps - Harvest-now-decrypt-later: All VVV transfer public keys and admin key public keys visible on-chain today can be harvested and stored for future quantum decryption ## WhiteBIT Coin (WBT) - Project page: https://qrindex.org/projects/whitebit-coin/ - Complete report JSON: https://qrindex.org/projects/whitebit-coin/report.json - Official project website: https://whitebit.com - Project type: exchange and ecosystem token - Evaluated network: Whitechain (native), Ethereum (ERC-20), Tron (TRC-20) - Evaluated scope: WBT token across all production representations: Whitechain native coin, Ethereum ERC-20, and Tron TRC-20. Evaluation covers spend authorization, consensus authentication, P2P transport, bridge/mint-burn mechanisms, and value-at-risk across all three chains. - QRI score: 1/100 - Readiness stage: 0 (Unassessed / No Evidence) - Evidence confidence: High - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Not Assessed, ECC-Only, Multi-Chain Token, Exchange/Ecosystem Token, PoA Consensus, EVM-Compatible ### Summary WhiteBIT Coin (WBT) is a multi-chain exchange/ecosystem token with a ~$10–12B market cap, native to Whitechain (a go-ethereum fork using Clique PoA consensus) and also represented as ERC-20 on Ethereum and TRC-20 on Tron. As of 2026-06-06, the project has published NO quantum risk assessment, cryptographic inventory, PQC roadmap, mitigation design, prototype, testnet, or mainnet protection. All critical cryptographic layers — spend authorization (ECDSA/secp256k1 EOAs), consensus authentication (Clique secp256k1 block sealing), P2P transport (devp2p ECDSA), and token bridge mechanisms — rely entirely on quantum-vulnerable elliptic curve cryptography. The ERC-20 and TRC-20 representations inherit the quantum vulnerability of Ethereum and Tron respectively. Approximately 100% of the ~$10–12B value-at-risk is quantum-vulnerable with no migration path. The centralized PoA architecture gives WhiteBIT theoretical operational control to halt or migrate the chain, but no such plan is documented. The project scores 1/100 (Stage 0, Readiness & Risk Cap 10 from no public cryptographic inventory). The project requires a public cryptographic inventory and quantum risk assessment as immediate next steps. ### Critical quantum blockers - No public cryptographic inventory of quantum-vulnerable mechanisms: the project has not published any inventory of its ECDSA/secp256k1 usage across spend authorization, consensus, P2P, or bridge layers. Readiness & Risk Cap: 10. - All critical cryptographic layers are ECDSA/secp256k1-only: Whitechain spend authorization uses standard Ethereum EOA signatures, Clique PoA consensus uses secp256k1 block sealing, P2P node identity uses devp2p ECDSA, and ERC-20/TRC-20 token representations inherit host-chain ECC vulnerability. No PQC, hybrid-PQC, or migration path exists. - No quantum risk assessment, PQC roadmap, mitigation design, prototype, testnet, or mainnet protection of any kind has been published by WhiteBIT or the Whitechain project. ### Principal risks - 100% of WBT value-at-risk (~$10–12B across all three chains) is protected only by ECDSA/secp256k1, which is breakable by a sufficiently scaled quantum computer running Shor's algorithm. - Whitechain Clique PoA consensus uses secp256k1 validator signatures; a quantum attacker compromising the single validator key (currently operated by WhiteBIT) could forge blocks, reorg the chain, and double-spend native WBT. - Ethereum ERC-20 and Tron TRC-20 WBT representations inherit full host-chain quantum vulnerability; a quantum attack on Ethereum or Tron would compromise all wrapped/bridged WBT on those chains. - All WBT user accounts on Whitechain use standard Ethereum EOAs; public keys are exposed on every transaction, creating long-exposure attack surfaces for offline quantum key recovery. - The burn-and-mint bridge between Whitechain and Ethereum/Tron likely relies on administrative ECDSA keys; compromise of these keys by a quantum adversary could enable infinite minting of WBT on Whitechain. - No migration, freeze, burn, deprecation, or recovery mechanism exists for quantum-vulnerable WBT; even if quantum attack becomes imminent, there is no publicly documented path to protect user funds. - The project has no documented quantum incident response process; while a general bug bounty exists (HackenProof), no quantum-specific vulnerability handling is defined. ## World Liberty Financial (WLFI) - Project page: https://qrindex.org/projects/world-liberty-financial/ - Complete report JSON: https://qrindex.org/projects/world-liberty-financial/report.json - Official project website: https://www.coingecko.com/en/coins/world-liberty-financial - Project type: cryptoasset - Evaluated network: Ethereum (primary), BNB Smart Chain, Solana - Evaluated scope: WLFI governance token (ERC-20/BEP-20/SPL) across all deployed chains, associated DeFi lending protocol (Aave V3 fork), USD1 stablecoin, and governance multisigs - QRI score: 0/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inheritance, ECC-Only, Multi-Chain, Governance Token, Stablecoin Issuer ### Summary World Liberty Financial (WLFI) is a governance token and DeFi protocol deployed as a standard ERC-20 token on Ethereum with additional deployments on BNB Smart Chain (BEP-20) and Solana (SPL). The protocol includes an Aave V3-based lending market and the USD1 fiat-backed stablecoin (~$2.2-3B circulating supply). WLFI inherits the quantum-security posture of its host chains per QRI Section 7.2 (Token Inheritance). The project has acknowledged quantum computing as a risk in its official risk disclosures but has published no cryptographic inventory, no quantum threat model, no PQC migration roadmap, and no quantum-specific mitigation of any kind. All spend authorization, governance multisigs (Gnosis Safe), protocol admin keys, stablecoin custody (BitGo), and cross-chain bridge dependencies remain entirely classical ECDSA/EdDSA-based. The QRI Score is 0, capped at 10 by the absence of a public cryptographic inventory (Readiness & Risk Cap) and further constrained by a Factor Score of 0 reflecting zero implementation across all five scoring categories. WLFI's quantum readiness is entirely dependent on future quantum-security upgrades to Ethereum, BSC, and Solana. ### Critical quantum blockers - No public cryptographic inventory: the project has not published an inventory of quantum-vulnerable public-key mechanisms, attack surfaces, affected assets, or affected layers (Readiness & Risk Cap: 10) - All spend authorization is entirely ECDSA/EdDSA-only across all deployed chains. No PQC or hybrid-PQC transaction path exists (Readiness & Risk Cap: 40) - Governance multisigs (Gnosis Safe) and protocol admin keys use classical ECDSA, leaving protocol upgrades, treasury management, and emergency controls quantum-vulnerable - USD1 stablecoin minting, redemption, and custody (BitGo) rely on classical cryptographic infrastructure with no quantum-safe path - Cross-chain bridge dependencies (Wormhole for Solana, LayerZero OFT pattern, third-party bridges for EVM chains) introduce additional quantum-vulnerable signer-set and verification surfaces - No migration mechanism, deprecation path, or quantum-specific incident-response process exists for any WLFI-specific vulnerability ### Principal risks - Quantum key-recovery attack on any Ethereum EOA that has sent a WLFI transfer transaction would expose the private key, enabling theft of all WLFI held at that address across all EVM-compatible chains. - Governance multisig signer key compromise via quantum attack would give an adversary control over protocol upgrades, treasury funds ($15M+ initial reserve), USD1 stablecoin parameters, and emergency controls. - USD1 stablecoin reserves custodied by BitGo rely on classical cryptographic infrastructure. A quantum compromise of BitGo's custody keys could threaten the ~$2.2-3B stablecoin backing. - Cross-chain bridge dependencies (Wormhole for Solana, third-party bridges for EVM chains) expose WLFI value to quantum-vulnerable bridge signer sets and verification logic on each bridge. - The Aave V3 fork lending market holds hundreds of millions in TVL secured by classical Ethereum smart contracts. Quantum compromise of admin keys or the underlying chain could drain lending pools. - Long-exposure vulnerability: any Ethereum address that has ever sent a WLFI transaction has its public key permanently exposed on-chain, enabling offline quantum key-recovery attacks with no time constraint. - Solana deployment uses Ed25519 signatures which are also quantum-vulnerable (Shor's algorithm applicable to elliptic curve discrete log). ## Worldcoin (WLD) - Project page: https://qrindex.org/projects/worldcoin-wld/ - Complete report JSON: https://qrindex.org/projects/worldcoin-wld/report.json - Official project website: https://www.coingecko.com/en/coins/worldcoin-wld - Project type: cryptoasset - Evaluated network: Ethereum Mainnet / World Chain (OP Stack L2) - Evaluated scope: WLD as ERC-20 token on Ethereum L1 and World Chain L2; includes World ID proof-of-personhood protocol. Token inherits host-chain quantum risk per QRI Section 7.2. AMPC biometric privacy layer scored separately as off-chain infrastructure. - QRI score: 2/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Token Inherits L1/L2 Score, Roadmap Only, Partial Protection ### Summary Worldcoin (WLD) scores 2/100 on the QRI, placing it at Stage 1 (Quantum Risk Assessed). The project has acknowledged quantum risk through its AMPC biometric privacy system (quantum-secure SMPC for off-chain iris code protection) and through inheritance of Optimism's January 2026 Superchain PQ roadmap targeting ECDSA deprecation by 2036. However, all production blockchain layers — spend authorization (ECDSA/secp256k1), World ID zero-knowledge proofs (Groth16 zkSNARKs on BN254 pairing-based curve), consensus authentication (sequencer ECDSA keys), and account/public-key exposure (Ethereum EOAs) — remain fully quantum-vulnerable with no migration path active or imminent. The AMPC system provides genuine quantum-secure multi-party computation for biometric data privacy but does not protect on-chain assets, identity proofs, or consensus. No PQ code, testnet, or mainnet support exists for any blockchain layer. The WLD token inherits the quantum risk profile of Ethereum L1 and World Chain L2. The low Factor Score reflects minimal credit for having public cryptographic documentation (Least Authority audits, open-source code, protocol specs) and an ecosystem-level roadmap (Optimism 2036), but no Worldcoin-specific quantum assessment, no deployed PQ protection, and zero migration coverage. ### Critical quantum blockers - ECDSA-only spend authorization on Ethereum L1 and World Chain L2 — all WLD token transfers and World Chain transactions are quantum-vulnerable to key-recovery attacks via Shor's algorithm (Readiness & Risk Cap 40). - Semaphore zkSNARK proofs (Groth16 on BN254 pairing-based curve) used for World ID proof-of-personhood — quantum-vulnerable to forgery, enabling Sybil attacks and identity bypass without iris scanning (Readiness & Risk Cap 70). - Long-exposure public-key vulnerability — Ethereum EOAs that have sent WLD transactions expose secp256k1 public keys on-chain, creating an at-rest attack surface for offline quantum key recovery (Readiness & Risk Cap 55). - No Worldcoin-published quantum cryptographic inventory or threat model — quantum risk is acknowledged only implicitly through AMPC biometric privacy feature and Optimism roadmap inheritance (Readiness & Risk Cap 10-20). - World Chain sequencer/batch-submitter keys use ECDSA — consensus authentication is quantum-vulnerable; compromise could enable transaction censorship, reordering, or fraudulent batch submission (Readiness & Risk Cap 70). ### Principal risks - Irreversible biometric compromise risk: Unlike financial keys which can be rotated, iris codes cannot be changed. If quantum attacks break the ZK proof system wrapping iris code hashes, the biometric identity damage is permanent and global in scale. - Sybil attack via quantum ZK forgery: A CRQC capable of forging Groth16 zkSNARK proofs could create unlimited fake World IDs without any Orb iris scan, completely bypassing the proof-of-personhood system. - Mass WLD theft via ECDSA key recovery: All WLD held in Ethereum EOAs that have ever sent a transaction have exposed public keys vulnerable to offline quantum key-recovery attacks (long-exposure surface). - World Chain sequencer compromise: The sequencer's ECDSA key, if quantum-compromised, could enable transaction censorship, reordering, or fraudulent L1 batch submission affecting all World Chain users. - No Worldcoin-specific migration timeline: The project relies entirely on Optimism's 2036 deadline without publishing its own migration plan, activation criteria, or user communication strategy. - The BN254 curve's marginal classical security (~96 bits) means World ID proofs are already below NIST recommendations even before considering quantum attacks, creating a compounded risk surface. ## XDC Network (XDC) - Project page: https://qrindex.org/projects/xdce-crowd-sale/ - Complete report JSON: https://qrindex.org/projects/xdce-crowd-sale/report.json - Official project website: https://www.coingecko.com/en/coins/xdce-crowd-sale - Project type: blockchain network - Evaluated network: XDC Mainnet (Chain ID 50) - Evaluated scope: XDC Network native asset and base protocol (XDPoS 2.0 consensus, EVM execution layer, as of v2.6.8 Cancun upgrade) - QRI score: 19.4/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-06 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, Partial Protection ### Summary XDC Network has published one of the most comprehensive post-quantum migration roadmaps in the blockchain industry (5 phases, 2026–2035), backed by a working Falcon consensus PoC, NIST FIPS 203/204/205/206 alignment, and the XDSS-PQ open standard co-authored with ITFA/ICC/TradeTrust. The project earns full marks for Security Assessment & Evidence Preparedness (5/5). However, as of June 2026, the network is in Phase 0 (Research/Standards) and every quantum-critical production layer — transaction spend authorization, XDPoS 2.0 consensus block signing and quorum certificates, P2P node identity, wallet/custody paths — remains entirely ECDSA (secp256k1). The recently activated Cancun upgrade (v2.6.8, January 2026) added KZG/blob cryptography, introducing a pairing-based quantum-vulnerable data availability primitive into production. Zero percent of economic value-at-risk is protected by PQ mechanisms. The QRI Score of 19.4 reflects strong risk assessment and mitigation planning that is not yet materially protecting any production users, consistent with Stage 2 (Mitigation / Development). The project is on a credible trajectory toward quantum readiness but has substantial engineering, governance, audit, and deployment work ahead before production protection becomes live. ### Critical quantum blockers - Active production spend authorization remains entirely ECDSA (secp256k1) — all transaction signatures are quantum-vulnerable. - Active production consensus authentication (XDPoS 2.0 block signing, quorum certificates, validator votes) remains entirely ECDSA (secp256k1) — a quantum-enabled attacker could forge block signatures and compromise finality. - XDC v2.6.8 introduced production KZG/blob cryptography support (pairing-based, quantum-vulnerable) for data availability — a new quantum-vulnerable protocol surface not covered by the current PQ migration scope until Phase 2+. ### Principal risks - All transaction spend authorization is ECDSA-only. A cryptographically relevant quantum computer could recover private keys from exposed public keys of any account that has ever sent a transaction, enabling theft of all accessible funds. - All XDPoS 2.0 consensus authentication (block signatures, quorum certificates, validator votes) is ECDSA-only. A quantum attacker could forge validator signatures to compromise finality, rewrite chain history, or execute a hostile takeover below the Byzantine fault tolerance threshold. - XDC v2.6.8 KZG/blob support introduces a pairing-based quantum-vulnerable primitive into the production protocol. While KZG is used for transient data availability (blobs pruned after ~18 days), any L2 or rollup depending on XDC blob DA could face settlement forgery risk under a quantum adversary. - P2P node identity and transport encryption (devp2p with ECDSA/ECDH) remain quantum-vulnerable, enabling harvest-now-decrypt-later attacks on masternode communications and potential node impersonation. - Material long-exposure quantum-vulnerable value exists in all accounts that have ever broadcast a transaction (exposed ECDSA public keys), including treasuries, bridge contracts, exchange wallets, and foundation-controlled assets. No migration, freeze, or deprecation mechanism is active. - The PQ initiative relies primarily on lattice-based algorithms (ML-DSA, Falcon). While SLH-DSA is identified as a hash-based fallback, a catastrophic lattice break before Phase 3 (2030–2031) would require an emergency hard fork to deploy the fallback — a process that has been documented in planning but never tested. - Migration timeline extends to 2035 for full PQ-only mode. If cryptographically relevant quantum computers arrive earlier than projected (Google's 2026 estimate reduced the logical qubit requirement from ~4,000 to ~1,200), the network could face a protection gap. ## XRP Ledger (XRP) - Project page: https://qrindex.org/projects/xrp/ - Complete report JSON: https://qrindex.org/projects/xrp/report.json - Official project website: https://xrpl.org - Project type: federated-consensus payment network - Evaluated network: XRPL Mainnet - Evaluated scope: Native XRP asset, consensus layer, P2P layer, account and transaction signing - QRI score: 26.88/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-08-13 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: Roadmap Only, PQ-Recoverable, Partial Protection ### Summary XRP Ledger is in Stage 2 (Mitigation / Development) with a QRI Score of 26.88, capped at 40 by classical-only spend authorization and testnet-only PQC status. The project has full credit for Security Assessment & Evidence Preparedness (5.0/5), reflecting a comprehensive public cryptographic inventory, detailed quantum threat model, and strong evidence record including official docs, XLS-295 specification, AlphaNet testnet, IEEE paper, and ripple codebase. However, all production cryptographic protection remains classical: mainnet transaction signatures use secp256k1 ECDSA and Ed25519 exclusively, validator consensus authentication is classical, and no PQ/hybrid-PQC path exists on mainnet. XRPL has advanced further in PQ planning than many L1 peers: a formal XLS specification (#295) proposes ML-DSA-44 (NIST FIPS 204) across all signing surfaces gated by a 'Quantum' amendment; an AlphaNet developer testnet has been running ML-DSA since December 2025 covering accounts, transactions, and consensus; and Ripple has published a 4-phase roadmap targeting full PQC transition by 2028. XRPL's architecture provides structural advantages for future migration: public keys are double-hashed (RIPEMD-160(SHA-256(pk))) so they remain unexposed until the first outgoing transaction, and native key rotation (SetRegularKey) allows accounts to update signing keys without moving funds. These design properties significantly reduce long-exposure value-at-risk for dormant accounts (only ~0.03% of circulating supply is in dormant accounts with exposed keys per third-party analysis). Despite these meaningful preparations, zero mainnet value is protected by PQC today. The computed Factor Score (26.88) binds below both the Stage 2 cap (40) and the Readiness & Risk cap (40 for ECC-only spend authorization and testnet-only PQC). ### Critical quantum blockers - Active production spend authorization remains entirely ECC/EdDSA-only (secp256k1 ECDSA and Ed25519) on mainnet; no PQC or hybrid-PQC transaction signature path exists in production. Readiness & Risk Cap: 40. - Consensus-critical validator authentication (validator manifests, validations, consensus proposals, UNL publisher signatures) remains classical on mainnet; no PQC validator auth exists in production. Readiness & Risk Cap: 40. - No mainnet PQC or hybrid-PQC path exists as of the evaluation date; the 'Quantum' amendment (XLS-295) is Draft status and gated behind consensus activation that has not occurred. Testnet only cap: 40. ### Principal risks - Quantum-critical vulnerability: Mainnet transaction signatures are entirely secp256k1 ECDSA or Ed25519. A sufficiently advanced quantum computer running Shor's algorithm can recover private keys from exposed public keys and forge transactions, enabling theft of any account that has sent a transaction. - Quantum-critical vulnerability: Consensus-critical authentication (validator manifests, validations, consensus proposals) uses classical signatures. A quantum adversary could forge validator identities or consensus messages, plausibly compromising finality or liveness on a federated-consensus chain. - Quantum-critical uncertainty: No mainnet PQC path exists. The 'Quantum' amendment (XLS-295) is Draft and consensus activation has not occurred; production readiness depends entirely on future roadmap execution with a 2028 target. - Long-exposure value-at-risk: Active accounts that have previously transacted expose their public keys on-chain and remain vulnerable to harvest-now-decrypt-later attacks with no production mitigation path until the PQC amendment activates. - No enforcement mechanism for PQ migration: Classical signatures will remain valid indefinitely. XLS-295 proposes an additive amendment (new key type alongside existing) rather than mandatory replacement. Ripple's Phase 4 mentions 'enforcing a hard shift' but this is a future contingency concept, not a current mechanism. - Bridge exposure (token-inheritance scope): Wrapped XRP representations via XRPL-EVM, Axelar GMP, and Wormhole rely on classical bridge signer sets and door accounts with no published PQC roadmaps, leaving non-native representations quantum-vulnerable. - Performance uncertainty: ML-DSA-44's 2420-byte signatures and ~3.7 KB transaction overhead are untested at mainnet scale; state bloat and throughput reduction could delay or complicate the 2028 transition. - Implementation assurance gap: The PQ testnet implementation lives in a third-party fork (Transia-RnD/rippled) with no completed independent cryptographic audit, limiting confidence in the production readiness of the candidate implementation. ## YLDS (YLDS) - Project page: https://qrindex.org/projects/ylds/ - Complete report JSON: https://qrindex.org/projects/ylds/report.json - Official project website: https://www.figuremarkets.com/c/ylds - Project type: stablecoin - Evaluated network: Multi-chain (Provenance primary; also Solana, Stellar, Ethereum, Sui, Avalanche) - Evaluated scope: Multi-chain SEC-registered yield-bearing stablecoin token, evaluated under Token Inheritance rules for all deployed host chains as of 2026-06-07. Host-chain spend authorization, consensus, and state integrity are inherited; token-specific admin/governance keys and the off-chain transfer-agent recovery mechanism are evaluated directly. - QRI score: 1/100 - Readiness stage: 1 (Quantum Risk Assessed) - Evidence confidence: Medium - Evaluation date: 2026-06-07 - Review status: draft - User urgency: [Monitor for Updates] - Readiness tags: PQ-Recoverable, Token Inheritance, Multi-Chain, Not Assessed (by project) ### Summary YLDS is a multi-chain SEC-registered yield-bearing stablecoin deployed across Provenance (native), Solana, Ethereum, Sui, Avalanche, and Stellar. It inherits the classical ECC-based cryptographic security of all its host chains — none of which have production post-quantum protection as of the evaluation date. YLDS has published no cryptographic inventory, quantum threat model, PQ migration roadmap, or quantum-specific incident-response process. The QRI Score is 1/100, reflecting Stage 1 (Quantum Risk Assessed) with no meaningful production quantum protection. However, YLDS carries the PQ-Recoverable tag: as an SEC-registered face-amount certificate with Figure Equity Solutions as the registered transfer agent, legal ownership is maintained off-chain. The issuer can revoke on-chain account access and claw back tokens via Provenance Blockchain's forced-transfer feature, providing a credible — though not quantum-preventive — recovery path. With ~$557M in circulation, YLDS represents significant quantum-exposed value-at-risk that is currently unprotected on all host chains. ### Critical quantum blockers - All host chains (Provenance, Solana, Ethereum, Sui, Avalanche, Stellar) use classical ECC-based spend authorization (Ed25519, ECDSA) with no production PQC or hybrid-PQC protection. A quantum adversary recovering a private key from any host chain's public key can forge token transfer signatures. - No public cryptographic inventory or quantum threat model has been published by Figure Certificate Company, Figure Markets, or the YLDS project. - Figure Markets MPC wallet infrastructure uses classical MPC implementations; standard MPC protects against single-point key theft but does not protect against quantum key recovery from exposed public keys. - Long-exposure quantum-vulnerable public keys exist on host chains (Ethereum EOAs that have sent transactions, Solana Ed25519 addresses with on-chain activity) with no migration, freeze, deprecation, or policy path for YLDS token holders. - Admin/upgrade keys for YLDS smart contracts on non-Provenance host chains have no publicly documented quantum-resistant protection. ### Principal risks - Quantum key recovery on any host chain (Provenance Ed25519, Solana Ed25519, Ethereum ECDSA secp256k1, Sui Ed25519, Avalanche ECDSA, Stellar Ed25519) would enable forgery of YLDS transfer signatures, allowing theft of on-chain token balances. - Long-exposure public keys on Ethereum (transacted EOAs), Solana, and other chains are vulnerable to offline quantum attack with no time constraint. - Figure Markets' classical MPC wallet infrastructure does not protect against quantum key recovery from public keys; a quantum adversary who recovers MPC shard private keys could access user funds. - Admin/upgrade keys for YLDS token contracts on non-Provenance chains are of unknown quantum resilience; compromise could enable unauthorized minting, freezing, or contract replacement. - The Provenance Blockchain 'Quantum-Resistant Protocol Evolution' is a 24–36 month roadmap item with no production timeline, activation criteria, or testnet implementation publicly documented. - No formal incident-response playbook exists for coordinating freeze/clawback operations across all six host chains simultaneously in a quantum-emergency scenario. - The transfer-agent recovery mechanism depends on the issuer detecting quantum theft and acting before tokens are exchanged for non-recoverable assets; the window for effective clawback is uncertain. - YLDS on Stellar and other chains may not have the same forced-transfer/clawback capabilities available natively on Provenance; cross-chain recovery enforceability is unverified. ## Zcash (ZEC) - Project page: https://qrindex.org/projects/zcash/ - Complete report JSON: https://qrindex.org/projects/zcash/report.json - Official project website: https://z.cash - Project type: PoW privacy chain - Evaluated network: Zcash Mainnet - Evaluated scope: Native asset (ZEC) — transparent, Sprout, Sapling, and Orchard pools; consensus; P2P; shielded protocol layers - QRI score: 19/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-11 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, PQ-Recoverable, Partial Protection, Privacy Chain ### Summary Zcash has conducted one of the most thorough quantum risk assessments in the blockchain ecosystem. The protocol specification, ZIP 2005 (Orchard Quantum Recoverability), and contributor analyses from Sean Bowe and others provide a detailed cryptographic inventory explicitly identifying all quantum-vulnerable components: spend authorization (ECC-only across all address types), Halo 2 proof soundness (Pasta curve discrete-log assumptions), note encryption (elliptic-curve ECDH), and note commitments (not post-quantum binding). ZIP 2005 proposes a quantum recoverability mechanism for Orchard notes but remains in Proposed/Draft status with code PRs behind an unstable feature flag; it is not activated on mainnet and does not make the protocol quantum-secure today. An aggressive roadmap announced at Consensus Miami (May 2026) targets quantum-recoverable wallets by mid-2026 and full post-quantum status by late 2027 through Project Tachyon. However, as of June 11, 2026, zero production post-quantum or hybrid-PQC protection is live on mainnet. All spend authorization across all address types remains entirely ECC-based and quantum-vulnerable. The transparent pool (~69% of circulating supply, ~11.5M ZEC) uses secp256k1 with fully exposed or derivable public keys and no announced migration plan. Shielded pools (~31%, ~5.1M ZEC) benefit from quantum-resistant nullifiers for transaction-graph privacy but remain ECC-dependent for asset ownership and proof soundness. Score: 19/100 (Stage 2: Mitigation/Development). ### Critical quantum blockers - All spend authorization remains ECC-only across all address types: transparent uses ECDSA/secp256k1, Sapling uses RedJubjub, Orchard uses RedDSA/RedPallas — all vulnerable to Shor's algorithm. - Halo 2 proof system soundness relies on discrete-log hardness on Pasta (Pallas/Vesta) curves; a quantum break would enable undetectable forgery of spending proofs and potential inflation within shielded pools. - Note encryption relies on elliptic-curve Diffie-Hellman key agreement, enabling harvest-now-decrypt-later retroactive deanonymization of all historical shielded transactions. - Note commitment algorithms in Sapling and Orchard are not post-quantum binding (acknowledged in ZIP 2005); even a future PQ proof system upgrade would leave existing shielded state vulnerable to forgery unless migrated through the not-yet-built Recovery Protocol. - Approximately 69% of circulating supply (~11.5M ZEC) resides in the transparent pool with secp256k1 keys fully exposed or derivable on-chain; no migration, freeze, deprecation, or recovery path exists for transparent addresses. - No production PQC, hybrid-PQC, or mandatory migration path is live on mainnet for any address type as of the evaluation date. ### Principal risks - A quantum adversary capable of solving ECDLP on secp256k1 could steal all transparent-pool ZEC from addresses with exposed public keys, with no migration or recovery path available. - A quantum break of discrete log on Pasta curves would compromise Halo 2 proof soundness, enabling undetectable forgery of shielded spending proofs and potential unlimited ZEC inflation within the Orchard and Sapling pools. - All historical shielded transactions are vulnerable to harvest-now-decrypt-later attacks; an adversary recording ciphertexts today could retroactively deanonymize amounts, memos, and address linkages once quantum computing matures — this damage is irreversible. - Note commitment algorithms in both Sapling and Orchard are not post-quantum binding; even after a future PQ proof system upgrade, existing shielded notes could be forged unless migrated through the not-yet-built Recovery Protocol. - ZIP 2005's Recovery Protocol retains a RedDSA signature requirement, meaning spend authorization during recovery still depends on classical ECC assumptions. - Sapling funds (~592K ZEC) are excluded from ZIP 2005 recoverability and must be migrated to Orchard first — with no automated or enforced migration mechanism. - No public plan exists for migrating, freezing, depreciating, or burning transparent-pool balances, which constitute the majority of ZEC supply and face the same quantum threat as Bitcoin. - Tachyon's lattice-based PCS replacement and post-quantum key exchange designs are at the research/prototype stage; no production-grade PQ-SNARK or PQ note encryption implementation exists. ## 币安人生 (BinanceLife) (币安人生) - Project page: https://qrindex.org/projects/bianrensheng/ - Complete report JSON: https://qrindex.org/projects/bianrensheng/report.json - Official project website: https://www.coingecko.com/en/coins/bianrensheng - Project type: meme token - Evaluated network: BNB Smart Chain (BEP-20) - Evaluated scope: Standard BEP-20 meme token inheriting BNB Smart Chain host-layer cryptography; token-specific admin/governance keys only - QRI score: 4.78/100 - Readiness stage: 2 (Mitigation / Development) - Evidence confidence: Medium - Evaluation date: 2026-06-01 - Review status: draft - User urgency: [Migration Required] - Readiness tags: Roadmap Only, Inherits L1 Score (BNB Smart Chain) ### Summary 币安人生 (BinanceLife) is a standard, immutable BEP-20 meme token on BNB Smart Chain with renounced ownership and no custom cryptography. Under QRI Section 7.2 (Token Inheritance), it inherits the base-layer QRI score of BNB Smart Chain. As of 2026-06-01, BSC production relies entirely on classical ECDSA for spend authorization and BLS12-381 for consensus, leaving 100% of the token's ~$632M market cap exposed to quantum key-recovery attacks. BNB Chain published a post-quantum cryptography migration research report on May 14, 2026, evaluating ML-DSA-44 transaction signatures and pqSTARK consensus aggregation with detailed benchmarks, but this remains a research/proof-of-concept document with no public testnet, committed timeline, or mainnet deployment. The token itself has no agency to migrate; its quantum readiness is entirely dependent on BSC's future host-chain upgrade. Token-specific admin keys are satisfied by design (ownership renounced, no proxy, no minting). ### Critical quantum blockers - Active production spend authorization on BNB Smart Chain remains entirely ECDSA (secp256k1) with no mainnet or public testnet PQC deployment as of 2026-06-01. - 100% of token value-at-risk (~$632M market cap) is exposed to quantum key-recovery attacks via host chain ECC vulnerability; no migration, freeze, deprecation, or recovery path exists. - Consensus-critical authentication on BSC remains BLS12-381 only; pqSTARK aggregation exists only in a research report with no production or testnet deployment. ### Principal risks - 100% of token value (~$632M market cap) is exposed to quantum key-recovery attacks via BSC's ECDSA-based spend authorization. - BSC's PQ migration is at research/prototype stage only (May 2026 report); no public testnet, committed timeline, or mainnet deployment exists. - All BSC addresses with exposed public keys (transacted EOAs, reused addresses) represent long-exposure quantum-vulnerable value with no migration or deprecation path. - BSC consensus remains BLS12-381 only; validator authentication is quantum-vulnerable. - Token is immutable with renounced ownership; it cannot independently upgrade or migrate to a PQ-secure host chain. - BSC's proposed PQ migration path explicitly excludes P2P handshakes and KZG commitments, leaving structural vulnerabilities even in the proposed design.