Ethereum Classic ETC

Claim: No formal public cryptographic inventory or quantum threat model has been published by the Ethereum Classic project. ECIP-1122 discussion demonstrates basic awareness of secp256k1 quantum vulnerability but does not constitute a formal assessment.

Coverage basis: No inventory or threat model found in official documentation, ECIP repository, GitHub discussions, or project website.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No quantum-focused public cryptographic inventory published.

Assurance: The 2018 blog post documents ECDSA/secp256k1 usage and core-geth source code is public, but these do not constitute a quantum-focused cryptographic inventory or threat model.

Absence confirmed by searching official site, ECIP repository, GitHub discussions, and web search.

• https://ethereumclassic.org/
• https://github.com/orgs/ethereumclassic/discussions/556
• https://github.com/ethereumclassic/ECIPs

Claim: No quantum-specific evidence record exists because no quantum risk assessment has been published.

Coverage basis: No assessment exists to be supported by evidence.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Source code and blog posts provide cryptographic documentation but are not organized as a quantum evidence record.

Claim: ETC uses ECDSA over secp256k1 for all transaction signatures. No PQC or hybrid-PQC spend authorization exists on mainnet.

Coverage basis: All EOAs sign transactions with ECDSA/secp256k1. Verified in official blog post and secondary documentation.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All transaction spending authorization is ECDSA/secp256k1-only, fully breakable by Shor's algorithm.

Assurance: Confirmed in multiple primary and secondary sources. ECDSA on secp256k1 is the canonical signature scheme for all Ethereum-family EOAs.

ECIP-1122 would add ML-DSA precompile for smart-contract-level verification only; it does not replace or augment base-layer transaction signing.

• https://ethereumclassic.org/blog/2018-03-15-signatures/
• https://dev.to/q9/ethereum-2-part-series-1-accounts-keys-and-addresses-122l

Claim: ETC addresses are derived from ECDSA public keys (Keccak256 hash of public key). Public keys are permanently exposed on-chain once an EOA sends a transaction. No PQ/hybrid controls exist.

Coverage basis: Standard Ethereum account model. Public key revealed in transaction signature recovery.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Long-exposure public keys: every EOA that has sent a transaction has its public key permanently visible on-chain, enabling offline at-rest quantum key-recovery with no time constraint.

Assurance: The Ethereum account model is well-documented and identical to Ethereum's. Address reuse is common, compounding exposure.

There is no key-rotation mechanism; users must abandon addresses entirely.

• https://ethereumclassic.org/blog/2018-03-15-signatures/
• https://dev.to/q9/ethereum-2-part-series-1-accounts-keys-and-addresses-122l

Claim: Ethereum Classic uses Proof-of-Work (Etchash). There are no validator signatures, VRFs, BLS threshold signatures, or finality certificates.

Coverage basis: PoW consensus: block validity determined by hash difficulty, not by validator signatures.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ETC's PoW consensus uses Etchash, which is based on Keccak256. PoW hash functions are considered quantum-resistant against known quantum attacks.

Structural advantage of PoW chains: no validator-signature attack surface at the consensus layer.

• https://ethereumclassic.org/
• https://en.wikipedia.org/wiki/Ethereum_Classic

Claim: ETC's protocol-level state integrity uses Keccak256-based Merkle Patricia tries for state roots and Etchash for block hashing. No KZG commitments at protocol level. BN256 and BLS12-381 precompiles available for application use.

Coverage basis: Protocol state integrity is hash-based. KZG/blobs are explicitly deferred (ECIP-1121).

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: BN256 and BLS12-381 precompiles remain available to smart contracts and are quantum-vulnerable (pairing-based). Applications using these inherit quantum vulnerability at the application layer.

Satisfied-by-design applies at the protocol level only. Application-layer quantum vulnerabilities from precompile usage are out of scope for this protocol-level subfactor.

• https://ethereumclassic.org/
• https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1121.md

Claim: Ethereum Classic has no native privacy layer, shielded transactions, or ZK proof assumptions at the protocol level.

Coverage basis: ETC is a transparent EVM chain with no native privacy features.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://ethereumclassic.org/

Claim: ETC uses devp2p with ECDSA-based node identities (secp256k1). No PQC or hybrid-PQC for P2P layer.

Coverage basis: Standard Ethereum devp2p stack using secp256k1 for node identity keys.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: P2P node identity using ECDSA does not directly enable asset theft, forgery, or consensus compromise. An attacker compromising node identities could attempt eclipse attacks, but this does not create a direct path to stealing funds. Since spend authorization is already fully ECC-only, the P2P layer is scored at 0.00 for consistency but treated as an assurance-only caveat.

The P2P identity concern is secondary to the spend-authorization vulnerability. Even if P2P were PQ-secure, all funds would remain stealable via ECDSA key recovery.

• https://github.com/ethereumclassic/core-geth

Claim: No PQ wallet, custody, HSM, or hardware-wallet support exists for ETC. All wallets use ECDSA/secp256k1.

Coverage basis: No evidence of any PQ wallet support for ETC found in any source.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No wallet or custody path exists for quantum-safe ETC transactions.

Assurance: Absence of PQ wallet support is a direct consequence of no PQ spend authorization at the protocol layer.

Exchange and custody workflows remain entirely ECDSA-dependent.

Claim: ~0% of the ~$1.25B circulating market cap is protected from quantum key-recovery attacks. All ETC in EOAs that have sent transactions has exposed public keys.

Coverage basis: Market cap data from CoinGecko (June 2026): ~$1.25B. Zero PQ-protected balances or accounts exist on mainnet.

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: ~100% of ~$1.25B circulating value is quantum-vulnerable with no migration path.

Assurance: Market cap data from CoinGecko and CoinMarketCap as of June 2, 2026. Implementation Score of 0.05 reflects <25% coverage per QRI 9.3.1 table (Score = 1 out of weight 20).

Value-at-risk includes all EOAs that have ever broadcast a transaction (public keys permanently exposed), plus all accounts controlling significant balances. Dormant and lost accounts with exposed public keys are permanently unpatchable.

• https://www.coingecko.com/en/coins/ethereum-classic
• https://coinmarketcap.com/currencies/ethereum-classic/

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to PQ protection.

Coverage basis: No evidence of any migrated wallets found in any source.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Absence confirmed by lack of any migration announcements, exchange attestations, or on-chain evidence of PQ-protected accounts.

Critical wallet migration is impossible until the protocol supports PQ transaction signing.

Claim: No identification, measurement, deprecation, or migration of legacy quantum-vulnerable pools has been performed.

Coverage basis: No evidence of any vulnerable-pool inventory or management found.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The 'Code is Law' ethos makes it unclear whether the community would ever accept a freeze/deprecation/burn policy for unmigratable vulnerable value.

ETC's 11-year history (since 2015) means there is a substantial population of dormant accounts with publicly exposed keys that can never migrate.

Claim: ECIP-1122 is a draft proposal for an ML-DSA precompile. It is not a migration roadmap and does not address base-layer account migration.

Coverage basis: ECIP-1122 draft (PR #557, Jan 2026), GitHub discussion #556. Proposal covers only smart-contract-level PQ verification precompile.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: confidence-only

Assurance: ECIP-1122 is in draft status, not merged, with a core contributor indicating it's unlikely to receive attention due to funding constraints. The proposal scope (precompile only) does not constitute a base-layer migration roadmap.

A precompile-only approach cannot migrate existing EOAs. A separate, fundamental protocol change would be needed for base-layer PQ transaction signing.

• https://github.com/ethereumclassic/ECIPs/pull/557
• https://github.com/orgs/ethereumclassic/discussions/556

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, or migration prompts exist.

Coverage basis: No evidence of any PQ-accessible user workflows found.

Implementation score: 0 · Evidence confidence: High

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

Even if the ECIP-1122 precompile were deployed, it would not provide migration accessibility for EOAs.

Claim: No migration enforcement mechanisms exist. No coordination with exchanges, custodians, or infrastructure providers on quantum migration.

Coverage basis: No evidence of any enforcement or coordination found.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The 'Code is Law' philosophy makes legacy-signing deprecation, forced freezes, or mandatory migration particularly difficult to achieve through governance.

No evidence of any exchange, custody, mining pool, or infrastructure coordination around quantum readiness.

Claim: No quantum-specific incident response process, disclosure mechanism, or emergency governance path exists.

Coverage basis: No evidence of quantum-specific IR processes found in any project documentation or governance channels.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI specification Section 7.4, the absence of a formal quantum-specific IR playbook is a note-only caveat unless it leaves a current quantum-vulnerable path unresolved. Since the entire spend-authorization layer is already unprotected, the IR gap does not independently create new vulnerability.

The Olympia DAO governance framework could theoretically serve as an emergency coordination mechanism, but it is not yet activated on mainnet and was not designed for quantum-specific incidents.

Claim: ECIP-1122 proposes ML-DSA (FIPS-204 / CRYSTALS-Dilithium), which is a NIST-standardized post-quantum signature algorithm. However, this is only a draft proposal, not a production implementation.

Coverage basis: ECIP-1122 draft references ML-DSA-65. Upstream Ethereum EIP-8051 also specifies ML-DSA precompiles.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: confidence-only

Assurance: ML-DSA is a NIST-standardized algorithm (FIPS-204). The proposal references a well-reviewed algorithm, but the proposal itself has received minimal community review. Score reflects proposal-only status.

The ML-DSA precompile approach aligns with upstream Ethereum EIP-8051 work, suggesting eventual convergence if adopted.

• https://github.com/ethereumclassic/ECIPs/pull/557
• https://eips.ethereum.org/EIPS/eip-8051

Claim: No independent cryptographic audit of quantum-critical implementation exists. Core-Geth underwent a security gap analysis (March 2026) for classical CVEs, not quantum security.

Coverage basis: No quantum-specific audit found. The March 2026 Core-Geth security gap analysis addressed classical CVEs and Go runtime vulnerabilities.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI specification Section 7.4, the absence of an audit for an otherwise verifiable quantum-critical claim is a note-only caveat. However, here there is no PQ implementation to audit, so the score is 0.00 on implementation grounds, not audit absence.

Core-Geth 1.13.0 (March 2026) patched several CVEs and upgraded to Go 1.26+. This demonstrates active classical security maintenance but no quantum-specific audit scope.

• https://ethereumclassic.com/olympia/security

Claim: Core-geth is open-source (LGPL-3.0). The ECIP-1122 prototype PR exists as open-source code but is not merged or production-ready.

Coverage basis: Core-geth at github.com/ethereumclassic/core-geth. ECIP-1122 PR at github.com/ethereumclassic/core-geth/pull/5.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Core-geth is fully open source under LGPL-3.0. The ML-DSA precompile PR adds 530 lines across 12 files as a draft/WIP.

The ETC ecosystem is moving toward multi-client architecture (Fukuii as primary, Core-Geth in maintenance, Besu plugin). This could provide implementation diversity for any future PQ deployment.

• https://github.com/ethereumclassic/core-geth
• https://github.com/ethereumclassic/core-geth/pull/5

Claim: No parameter agility or PQ upgrade path has been documented for the ETC protocol beyond the draft ECIP-1122 precompile proposal.

Coverage basis: No documentation found addressing cryptographic agility or PQ parameter migration.

Implementation score: 0 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: The Olympia upgrade demonstrates that ETC can execute large-scale protocol upgrades, suggesting a viable governance path for future PQ upgrades. However, no PQ-specific agility planning is documented.

ETC's hard-fork governance process (ECIP-1000) provides a mechanism for protocol upgrades, but the 'Code is Law' philosophy may complicate consensus on cryptographic changes that affect account ownership.

Claim: No production PQ implementation exists to assess for stateful-signature safety, side-channel resistance, or custody implementation risks. ML-DSA is stateless.

Coverage basis: No PQ implementation exists to assess. ML-DSA (proposed) is stateless, eliminating XMSS/LMS state-management concerns.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Claim: No performance analysis has been published for PQ signature deployment on ETC mainnet.

Coverage basis: No gas-cost modeling, block-size impact analysis, or node resource analysis for PQ transactions found.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Per QRI specification, missing formal performance benchmarks are note-only when no PQ deployment exists. ML-DSA signatures are ~2.4KB (ML-DSA-65), significantly larger than ECDSA's ~65 bytes, which would impact gas costs, block space, and archival growth.

Upstream Ethereum EIP-8051 specifies gas costs for ML-DSA verification precompiles (4500 gas), providing a preliminary reference point for future ETC analysis.