blockchain network
Internet Computer ICP
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.
Roadmap OnlyClassical ECC/BLSQuantum-Vulnerable ConsensusQuantum-Vulnerable Spend Authorization
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0.75 / 15
Migration Status & Value-at-Risk
0 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
1.25 / 5
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.
Key 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.
Assurance Notes
- Trail of Bits and NCC Group audits cover classical consensus and cryptographic implementations (Threshold BLS, Threshold ECDSA) but do not address post-quantum migration or resistance.
- The 2021 NNS Proposal (35660) acknowledged quantum risks to discrete-log assumptions but has not resulted in a concrete L1 migration design, prototype, or testnet as of mid-2026.
- Community-led experiments (e.g., ICP Hub Egypt's April 2026 ML-DSA/MAYO2 canister demo) demonstrate application-layer PQ verification capabilities but do not protect the L1 consensus, subnet keys, or native spend authorization.
- ICP's Chain-Key architecture provides strong crypto-agility (upgradable without hard forks), but the production deployment remains entirely classical as of evaluation date.
- LayerQu external assessment (May 2026) corroborates Stage 1 with QRI 25/100, citing similar findings.
Non-Scoring Caveats
- Application-layer PQ demos (e.g., ML-DSA in canisters) exist but do not mitigate L1 protocol-level quantum exposure.
- Audit coverage for classical threshold cryptography is present but aging; no PQ-specific audits exist as no PQ implementation is in production.
- DFINITY has acknowledged the quantum threat and committed to monitoring, but no concrete timeline or algorithm selection for L1 migration has been published.
Evidence record
Claims and Caveats
Consensus
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Consensus notarization and finalization rely on Threshold BLS multi-signatures.
Coverage basis: Classical ECC/BLS dependency
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus finality relies on Threshold BLS, vulnerable to Shor's algorithm.
Assurance: Official documentation and whitepaper confirm BLS usage. Classical audits exist but do not cover PQ migration.
BLS is used for subnet state certification, randomness, and consensus shares. All quantum-vulnerable.
Transaction
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Canister signing for external chains and native operations uses Threshold ECDSA, Schnorr, and EdDSA.
Coverage basis: Classical ECC dependency
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only.
Assurance: Mainnet proof and public code confirm classical schemes for Chain-Key signatures.
Threshold ECDSA (secp256k1) and Schnorr (bip340, ed25519) used for cross-chain and canister-controlled assets.
Governance
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: 2021 NNS Proposal 35660 acknowledges quantum threat to discrete log-based signatures.
Coverage basis: Risk assessment / Proposal
Implementation score: 0.25 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Proposal is historical (2021) and lacks follow-through to production mitigation.
Acknowledges risk but no concrete L1 migration design has been published since.
Application
Migration Mechanism, Governance & Ecosystem Coordination
Claim: Community and hub-led experiments demonstrate ML-DSA/MAYO2 verification inside ICP canisters.
Coverage basis: Application-layer prototype
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Application-layer demo does not protect L1 consensus or native spend authorization.
Shows ecosystem interest and canister-level capability, but L1 remains classical.
Architecture
Parameter agility and future upgrade path are documented
Claim: ICP's Chain-Key architecture supports crypto-agility with upgrades without hard forks.
Coverage basis: Design capability
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Architecture enables algorithm swaps without hard forks, but no PQ algorithm has been selected or deployed.
Strong crypto-agility by design; key rotation and algorithm upgrades are protocol features.
Report metadata