Ethereum ETH

Claim: Ethereum has published an extensive cryptographic inventory identifying four vulnerable areas: ECDSA for EOA signatures, BLS for consensus, KZG for data availability, and ZK-proofs for applications. The threat model covers attack assumptions, affected assets, and affected layers.

Coverage basis: Public documentation across ethereum.org, pq.ethereum.org, consensus-specs, EIPs, and Google Quantum AI co-authored paper.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Comprehensive public documentation from official sources. Updated May 2026. Google Quantum AI March 2026 paper provides third-party validation.

Ethereum's quantum threat assessment is among the most comprehensive in the blockchain industry.

• https://ethereum.org/roadmap/future-proofing/quantum-resistance/
• https://pq.ethereum.org/
• https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md

Claim: Assessment is supported by code references (consensus-specs, EIPs), specifications, transaction examples on Etherscan, and reproducible analytics.

Coverage basis: Public GitHub repositories, EIP specifications, mainnet explorer data, research forum posts.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary source code and specifications are publicly available and verifiable.

Evidence record is comprehensive. Multiple primary sources independently confirm the same findings.

• https://github.com/ethereum/consensus-specs
• https://eips.ethereum.org/EIPS/eip-4844
• https://eips.ethereum.org/EIPS/eip-4337
• https://etherscan.io/

Claim: Ethereum mainnet uses ECDSA/secp256k1 for all EOA transaction signatures with no PQ or hybrid alternative deployed. ERC-4337 theoretically permits optional PQ smart contract wallets but no PQ precompiles or standard implementations exist.

Coverage basis: Protocol-level spend authorization for all EOAs is ECDSA-only. No PQ path exists in production.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: ECDSA-only spend authorization: All EOA transaction signatures use secp256k1/ECDSA. Public keys are permanently exposed on-chain after first transaction.

Assurance: Confirmed by official Ethereum Foundation documentation. No PQ signature scheme is deployed on mainnet.

ERC-4337 technically provides an optional path but no practical PQ implementation exists. EIP-8141, the designated protocol-level PQ migration mechanism, is a draft EIP with CFI status only.

• https://ethereum.org/roadmap/future-proofing/quantum-resistance/
• https://eips.ethereum.org/EIPS/eip-4337
• https://pq.ethereum.org/

Claim: EOAs expose their secp256k1 public key permanently on-chain after the first transaction. No key rotation mechanism exists. No PQ address formats exist on mainnet.

Coverage basis: All transacted EOAs have permanently exposed public keys with no rotation or PQ migration path.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Long-exposure at-rest vulnerability: transacted EOA public keys are permanently visible on-chain with no rotation or PQ migration path.

Assurance: Well-documented in Ethereum protocol design. Google estimates top 1,000 wallets (~20.5M ETH) have exposed public keys.

This is the most severe quantum exposure on Ethereum. Public key is derivable from any signed transaction.

• https://ethereum.org/developers/docs/accounts/
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: Validator attestations, block proposals, and the RANDAO randomness beacon use BLS12-381 signatures exclusively. The production consensus spec contains no PQ alternatives.

Coverage basis: All validator authentication in the production consensus spec uses BLS12-381, which is quantum-vulnerable.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: BLS-only consensus authentication: ~37M ETH staked. A quantum attacker compromising one-third of validators halts finality; two-thirds enables chain history rewriting.

Assurance: Authoritative consensus-specs repository confirms BLS-only. PQ alternatives (leanXMSS) are in devnet/research only.

BLS12-381 is vulnerable to Shor's algorithm. leanXMSS/leanVM PQ consensus devnets are running weekly but no mainnet timeline exists.

• https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md
• https://github.com/ethereum/consensus-specs

Claim: EIP-4844 blob transactions use KZG polynomial commitments based on elliptic curve pairings. These are quantum-vulnerable. No PQ replacement is deployed on mainnet.

Coverage basis: All rollup data availability via blob transactions depends on quantum-vulnerable KZG commitments.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: KZG commitments: A quantum computer could recover the trusted-setup secret and permanently forge data-availability proofs. This is a once-and-done exploit affecting all L2s.

Assurance: EIP-4844 is live on mainnet. Researchers are exploring STARKs/FRI as future replacement but no timeline is finalized.

STARKs/FRI replacement is in active research but has no committed timeline. Described as the most complex piece of the PQ migration.

• https://eips.ethereum.org/EIPS/eip-4844
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: Application-layer ZK-proof systems predominantly use Groth16, PLONK, and other pairing-based SNARKs that are quantum-vulnerable. Some STARK-based systems exist (StarkNet) but most L2 value depends on quantum-vulnerable proofs.

Coverage basis: Protocol-level ZK infrastructure provides no PQ guarantees. Application-layer PQ varies by project.

Implementation score: 0 · Evidence confidence: High

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

Assurance: ZK proof systems on Ethereum L2s predominantly use pairing-based SNARKs. STARK-based alternatives exist but are not universal.

STARK verification costs ~10M gas vs 300K-500K for SNARKs. EIP-8141's validation frame aggregation is the proposed solution.

• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: Ethereum's P2P layer uses discv5 with secp256k1 node IDs and libp2p noise-based encryption. No PQ protection exists.

Coverage basis: P2P node identity uses classical secp256k1 cryptography.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P quantum vulnerability is lower criticality than spend authorization or consensus authentication.

Node identity compromise does not directly enable fund theft but could facilitate eclipse attacks.

• https://github.com/ethereum/consensus-specs

Claim: No major wallet (MetaMask, Ledger, Trezor, Coinbase Wallet) supports PQ signatures. No HSM supports PQ signing for Ethereum.

Coverage basis: Production wallet and custody infrastructure is entirely classical.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The HSM/MPC hardware refresh cycle runs 2-5 years, creating a long tail for institutional PQ wallet adoption.

Third-party experimental PQ wallets exist via ERC-4337 but have negligible adoption and unverified production readiness.

• https://pq.ethereum.org/
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: Essentially 0% of mainnet value is protected by PQ or hybrid controls. ERC-4337 PQ smart contract wallets have negligible adoption.

Coverage basis: Sub-1% value-at-risk coverage. PQ-native claim does not apply (Ethereum launched with ECDSA).

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path.

Assurance: Google estimates >$100B in combined quantum exposure. Coverage is effectively 0% for native protocol protection.

Per QRI 9.3.1, <25% coverage scores 1 out of 20 points. Implementation Score = 1/20 = 0.05.

• https://www.coindesk.com/tech/2026/03/31/google-warns-five-quantum-attack-paths-could-put-usd100-billion-on-ethereum-at-risk
• https://pq.ethereum.org/
• https://etherscan.io/

Claim: No evidence that any major exchange, custodian, bridge, foundation treasury, or protocol treasury has migrated to PQ-protected wallets.

Coverage basis: All critical wallets remain quantum-vulnerable.

Implementation score: 0 · Evidence confidence: High

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

Google identified ~70 major contracts with exposed admin keys controlling ~2.5M ETH plus ~$200B in stablecoin minting authority.

• https://pq.ethereum.org/

Claim: Vulnerable EOA public keys have been identified and quantified by research. However, no deprecation, freeze, burn, or migration policy exists.

Coverage basis: Vulnerable pools identified but no action taken.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The EF notes ~0.1% of ETH supply is in addresses widely believed abandoned, significantly less than Bitcoin's ~5%.

Identification and measurement are well-documented (score 0.25), but no deprecation, migration, freeze, or burn policy exists.

• https://www.coindesk.com/tech/2026/03/31/google-warns-five-quantum-attack-paths-could-put-usd100-billion-on-ethereum-at-risk
• https://pq.ethereum.org/
• https://ethresear.ch/t/how-to-save-ethereum-from-a-quantum-sudden-death/18901

Claim: Ethereum has published an extensive multi-fork PQ roadmap (Strawmap) with fork milestones I* (PQ key registry), J* (PQ sig precompiles), L* (PQ attestations, leanVM), M* (PQ sig aggregation, PQ blobs), targeting 2029 completion.

Coverage basis: Comprehensive public roadmap with fork-level milestones, activation criteria, and dependency chains.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Roadmap is detailed and from official sources. Roadmap authors acknowledge post-2026 fork assignments are 'overcanonicalized' and likely to be softened.

The 2029 target is aspirational. Devnets and interop testing are active but timelines are planning targets, not commitments.

• https://pq.ethereum.org/
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: EIP-8141 (Frame Transactions) is the designated PQ migration mechanism but is a draft EIP with CFI status only. No default PQ wallet creation exists. No migration prompts in major wallets.

Coverage basis: Migration infrastructure is in proposal/devnet stage. No production defaults or user-facing migration tools exist.

Implementation score: 0.25 · Evidence confidence: High

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

EIP-8141 is CFI for Hegotá (H2 2026) but competes with EIP-8130 and Tempo. Even if shipped, it enables PQ adoption but does not mandate it.

• https://eips.ethereum.org/EIPS/eip-8141
• https://eip8141.io/faq
• https://eips.ethereum.org/EIPS/eip-4337

Claim: No enforcement mechanisms exist. No deprecation of ECDSA signing. No deadlines for migration. No exchange, custody, or bridge coordination for PQ migration.

Coverage basis: Zero enforcement or coordination mechanisms deployed or formalized.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Users can still create new quantum-vulnerable high-value accounts by default with no restrictions, warnings, or migration deadlines.

Ethereum's governance model makes enforcement mechanisms politically complex. No proposal for mandatory migration deadlines has reached serious consideration.

• https://pq.ethereum.org/

Claim: Vitalik Buterin published a conceptual 'quantum sudden death' emergency recovery plan (ethresear.ch, March 2024) involving a hard fork to revert blocks and implement STARK-based signatures.

Coverage basis: Conceptual recovery design exists but is untested, unformalized, and relies on off-chain social consensus.

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The emergency recovery plan has never been tested, formalized, or operationalized. It relies on off-chain social consensus and a hard fork.

A recovery plan is not active protection. Per QRI spec: 'A project should not be publicly labeled Quantum-Ready based only on recoverability.'

• https://ethresear.ch/t/how-to-save-ethereum-from-a-quantum-sudden-death/18901

Claim: Ethereum's PQ work builds on NIST foundations: leanXMSS is based on XMSS (NIST SP 800-208 stateful hash-based signatures), SLH-DSA (SPHINCS+) is NIST-standardized.

Coverage basis: Algorithm selection is appropriate and standards-aligned, but algorithms are not deployed in production.

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: leanXMSS is a bespoke XMSS variant; while XMSS is NIST-standardized, the leanXMSS construction itself has not undergone independent cryptographic review comparable to NIST standardization.

Algorithm selection demonstrates serious cryptographic engineering. Bespoke variants (leanXMSS) introduce risks not yet independently reviewed.

• https://pq.ethereum.org/
• https://crypto.ethereum.org/blog/nist-pqc-standard

Claim: No independent audit exists for any Ethereum PQ component. The EF's $20M zkEVM Formal Verification Project is underway but has not produced a published audit of quantum-critical scope.

Coverage basis: No independent audit of quantum-critical production or devnet implementation.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI v3.1, audit absence does not by itself create a quantum-critical vulnerability when no PQ production implementation exists. Score is 0.00 because there is nothing deployed to audit.

The $20M zkEVM Formal Verification Project is a significant investment but has not yet delivered auditable PQ artifacts.

• https://pq.ethereum.org/

Claim: All PQ work is open source: leanSig, leanMultisig, leanSpec (executable Python specification), leanVM, EIPs, consensus specs, and client implementations.

Coverage basis: Open-source devnet implementations exist and are reproducible. No production PQ implementation exists.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Open-source development is a strength. Weekly interop devnets with 10+ client teams demonstrate reproducible multi-client coordination.

• https://github.com/ethereum/pm/issues/2065
• https://github.com/ethereum/pm/issues/1983
• https://pq.ethereum.org/

Claim: Cryptographic agility is a core design principle. Account abstraction provides execution-layer agility. Multiple candidate schemes evaluated. The roadmap explicitly avoids premature lock-in.

Coverage basis: Agility is well-documented as a design principle with specific mechanisms (account abstraction, staged fork milestones).

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Agility is well-documented as a design principle but has not been proven in production for quantum-critical upgrades.

Score reflects strong documentation and mechanism design offset by the fact that no PQ-to-PQ upgrade has been demonstrated in production.

• https://pq.ethereum.org/
• https://eips.ethereum.org/EIPS/eip-8141

Claim: leanXMSS is a stateful XMSS variant. State management risks (signing state corruption, anti-reuse controls) are acknowledged in research but not proven in production.

Coverage basis: Stateful signature risks acknowledged in design phase. No production implementation to evaluate safety controls.

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: Stateful hash-based signatures (XMSS/LMS) have known operational failure modes. These risks have not been validated in a production blockchain context at Ethereum's scale (~1M validators).

This is the highest-risk area for Ethereum's PQ consensus design. The EF's formal verification effort ($20M) targets this risk but has not delivered verifiable artifacts.

• https://pq.ethereum.org/
• https://ethresear.ch/t/exploring-the-design-space-for-a-post-quantum-public-key-registry-for-ethereum-validators/25040

Claim: Extensive devnet benchmarking: raw PQ signatures ~3,000 bytes each vs BLS 96 bytes, ~30 MB/slot unaggregated. leanVM achieves ~250x compression.

Coverage basis: Devnet-level performance analysis exists. Mainnet-scale validation (~1M validators) has not been demonstrated.

Implementation score: 0.5 · Evidence confidence: Medium

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

Assurance: Devnet benchmarks are promising but operate at far smaller scale than mainnet. The 250x compression via leanVM is the key assumption enabling PQ consensus feasibility.

Performance analysis is thorough for the devnet scale. If leanVM aggregation performance does not scale to mainnet conditions, the consensus PQ migration timeline would be materially impacted.

• https://leanroadmap.org/
• https://bench.leanroadmap.org/
• https://github.com/ethereum/pm/issues/2065