---
title: Is Ethereum Classic quantum-safe?
chain: Ethereum Classic
ticker: ETC
hardy_score: 13
rank: 38 of 80
tier: "5: Exposed"
url: "https://hardyindex.com/chains/ethereum-classic"
updated: 2026-10-22
reviewed: 2026-11-13
methodology_version: 1.8
---

# Is Ethereum Classic quantum-safe?

**Hardy Score 13.0 / 100. Rank 38 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.**

No. Ethereum Classic accounts sign transactions with ECDSA on the secp256k1 curve, as in its Core-Geth client, and a sufficiently large quantum computer running Shor's algorithm would break it. Ethereum Classic has no post-quantum roadmap, adopted proposal or research programme. The one post-quantum item in its process is a work-in-progress draft, opened as a pull request to the ECIPs repository in January 2026 by an outside author, GravityLab LLC, for an EVM precompile that verifies ML-DSA-65 signatures under FIPS 204, so contract wallets could use post-quantum keys. It has not been assigned a number or merged, and ECIP editor Chris Mercer replied that upstream Ethereum is the better place for the work, describing Ethereum Classic as resource-constrained and saying infrastructure and governance need stabilising first. In July 2026 he removed the number 1122 the author had given it, which belongs to the Olympia suite, and said a dedicated range in the 1140s makes sense for post-quantum proposals, with this precompile as its anchor and the number to be assigned at formal submission. Ethereum Classic shares Ethereum's history up to the July 2016 split, so every key revealed before then is revealed on both chains, but nobody has published a measurement of that shared history.

> This is a security-readiness assessment, not investment advice.

## Summary

Signs with ECDSA on secp256k1, and its improvement process holds one post-quantum item, an unsubmitted draft by an outside author for an ML-DSA precompile, which an ECIP editor has pointed upstream while saying it would anchor a post-quantum number range once formally submitted.

## Where we are making a judgement call

Two judgement calls carry this profile. The first is the tier. The ECIP process is open to anyone and a draft is a legitimate route in, and in July 2026 an ECIP editor said the ML-DSA precompile would anchor a dedicated post-quantum number range once submitted, so a reader could count it as the formal proposal the Tier 4 floor asks for, which would raise the deployment score from 1 to 2 and the Hardy Score from 13.0 to 15.5. We do not, because the floor asks for work documented by people with authority over the chain, and the author, GravityLab LLC, has none; the pull request has not been formally submitted, and the editor said the number will be assigned only then; and the editor has also pointed the work upstream. The precompile would also serve contract wallets without touching the chain's own transaction signatures. The second is exposure. The inheritance rule applies, but there is no published measurement of the shared pre-2016 history to inherit, so the score rests on the address model alone. A measurement of Ethereum Classic, or of the shared history, could lower it.

## Score breakdown

| # | Dimension | Score | Weight | Contribution |
|---:|---|---:|---:|---:|
| 1 | Signature scheme | 0/10 | 30% | 0.0 |
| 2 | Deployment stage | 1/10 | 25% | 2.5 |
| 3 | NIST alignment | 3/10 | 15% | 4.5 |
| 4 | Migration path | 2/10 | 15% | 3.0 |
| 5 | Exposure | 2/10 | 10% | 2.0 |
| 6 | Verification | 2/10 | 5% | 1.0 |
| | **Hardy Score** | | | **13.0** |

### 1. Signature scheme: 0/10

Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.

Ethereum Classic transactions are signed with ECDSA on secp256k1, implemented in Core-Geth's crypto package. Proof of work secures blocks, so there are no validator signatures, and nothing post-quantum protects ETC on mainnet.

Source: https://github.com/ethereumclassic/core-geth/blob/main/crypto/crypto.go

### 2. Deployment stage: 1/10

Anchor band 1: Tier 5: Exposed.

Tier 5: Exposed. The signatures securing ETC are quantum-vulnerable, and the one post-quantum item is a draft pull request by GravityLab LLC, an outside author with no authority over the chain, which has not been formally submitted or assigned a number. An ECIP editor has said the number will be assigned at formal submission, so it is not yet a formal improvement proposal. See the caveat below on why this is a judgement call.

Source: https://github.com/ethereumclassic/ECIPs/pull/557

### 3. NIST alignment: 3/10

Anchor band 3 to 5: NIST schemes are referenced as candidates without a committed selection, or the work is bespoke research.

The unsubmitted draft names ML-DSA-65 from the final FIPS 204 as its required precompile, with ML-DSA-44 and ML-DSA-87 as options, for contract wallets. An ECIP editor has said its number will be assigned at formal submission, and nothing has been named for Ethereum Classic's own transaction signatures.

Placement in the band: The bottom of the band rather than a 4 or a 5: the draft has no standing in the ECIP process until it is formally submitted, its author has no authority over the chain, and it covers contract wallets rather than the chain's own transaction signatures. Above a 2, because a parameter set of a final NIST standard is named for a mechanism that would protect ETC held in contract wallets.

Source: https://github.com/ethereumclassic/ECIPs/pull/557

### 4. Migration path: 2/10

Anchor band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.

No migration plan exists. The draft precompile would give holders a contract-wallet route to post-quantum keys, and it leaves externally owned accounts unchanged. The ECIP editor who replied directed the work upstream and said the chain has gone a long stretch without an EVM upgrade.

Placement in the band: The top of the band rather than a 0 or a 1: a concrete contract-wallet mechanism is drafted, and Ethereum Classic's practice of adopting Ethereum's EVM changes gives it a path to reuse that work. Not a 3, because no one with authority has acknowledged migration as Ethereum Classic's own problem to solve.

Source: https://github.com/orgs/ethereumclassic/discussions/556

### 5. Exposure: 2/10

Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.

Ethereum Classic uses Ethereum's account model, in which an address is a hash of the public key, so an account that has never signed keeps its key private. Any account that has signed, on this chain, on Ethereum before the 2016 split, or on Ethereum since with the same key, has published it.

Placement in the band: The top of the band rather than a 1: the hashed-address model protects never-signed accounts. Not a 3, because almost all active supply has signed, and the shared keys with Ethereum widen exposure in a way nobody has measured for ETC.

Source: https://github.com/ethereumclassic/core-geth/blob/main/crypto/crypto.go

### 6. Verification: 2/10

Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing.

No post-quantum component exists on Ethereum Classic. The ML-DSA-65 precompile is a work-in-progress Core-Geth pull request, unmerged and on no network, and under v1.8 an unmerged implementation is not a component. The classical code's openness earns nothing here.

Placement in the band: The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but nothing about the chain is marketed as quantum-safe, so its position does not rest on marketing.

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

## Nearest chains in the ranking

The chains Ethereum Classic sits among, out of 80 rated. The last column is the gap in Hardy points from Ethereum Classic.

| Rank | Chain | Tier | Hardy | vs ETC |
|---:|---|---|---:|---:|
| 34 | [Dash](https://hardyindex.com/chains/dash) | 5: Exposed | 16.5 | +3.5 |
| 35 | [Bitcoin](https://hardyindex.com/chains/bitcoin) | 4: Debating | 14.5 | +1.5 |
| 36 | [Sonic](https://hardyindex.com/chains/sonic) | 5: Exposed | 14.5 | +1.5 |
| 37 | [Terra Classic](https://hardyindex.com/chains/terra-classic) | 5: Exposed | 14.5 | +1.5 |
| 38 | **Ethereum Classic** | 5: Exposed | 13.0 | this chain |
| 39 | [Flare](https://hardyindex.com/chains/flare) | 5: Exposed | 13.0 | level |
| 40 | [Internet Computer](https://hardyindex.com/chains/internet-computer) | 5: Exposed | 13.0 | level |
| 41 | [TON](https://hardyindex.com/chains/toncoin) | 5: Exposed | 11.0 | -2.0 |
| 42 | [Decred](https://hardyindex.com/chains/decred) | 5: Exposed | 10.5 | -2.5 |

## Signature scheme

- **On mainnet today:** ECDSA on secp256k1 for account transactions; proof of work for block production
- **Post-quantum scheme:** None selected. An unmerged work-in-progress ECIP draft proposes an ML-DSA-65 verification precompile for contract wallets.
- **NIST standard:** None adopted. The draft names ML-DSA under FIPS 204.
- **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found.

## Cryptography in use

- **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, default.
  Source (source code or release): https://github.com/ethereumclassic/core-geth/blob/main/crypto/crypto.go
- **Contract level:** [ML-DSA](https://hardyindex.com/algorithms/ml-dsa.md) (ML-DSA-65). Proposed. An EVM verification precompile for contract wallets, in an unsubmitted draft ECIP by an outside author, GravityLab LLC. Not assigned a number or merged.
  Source (specification or proposal): https://github.com/ethereumclassic/ECIPs/pull/557

A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md.

## Roadmap

- **July 2016** (shipped): Ethereum Classic continues the original chain at the DAO fork, block 1,920,000, sharing all of Ethereum's history and every key revealed in it up to that point.
  Source: https://github.com/ethereumclassic/ECIPs/blob/master/README.md
- **26 January 2026** (proposed): An outside author opens a work-in-progress ECIP pull request and discussion for an ML-DSA-65 (FIPS 204) verification precompile, with a Core-Geth implementation in progress.
  Source: https://github.com/ethereumclassic/ECIPs/pull/557
- **3 February 2026** (shipped): ECIP editor Chris Mercer replies that upstream adoption is the more effective path for the work, citing Ethereum Classic's constrained resources.
  Source: https://github.com/orgs/ethereumclassic/discussions/556
- **16 July 2026** (shipped): ECIP editor Chris Mercer removes the number 1122 from the draft's title, as it belongs to the Olympia suite, and says a dedicated 1140s range makes sense for post-quantum proposals, with the ML-DSA precompile as its anchor and the number to be assigned at formal submission.
  Source: https://github.com/ethereumclassic/ECIPs/pull/557
- **No date published** (proposed): No numbered ECIP, roadmap or timeline for post-quantum signatures on Ethereum Classic exists.
  Source: https://github.com/ethereumclassic/ECIPs

## If holders never migrate

**No stated policy.** No ECIP or statement from Ethereum Classic's maintainers addresses accounts that never move to post-quantum keys. The draft precompile leaves existing accounts unchanged. As of 22 October 2026. Source: https://github.com/ethereumclassic/ECIPs/pull/557

## Exposure

Ethereum Classic is the original Ethereum chain continued past the DAO fork of July 2016, so it shares Ethereum's history up to block 1,920,000. Under the v1.8 inheritance rule, published measurements of that shared history apply here, but none exists: Deloitte's finding that over 65% of Ether sits in addresses that have sent a transaction was measured on Ethereum's state after the split and does not transfer to the shared history. The structural picture is still clear. Every account that signed before the split has its key public on both chains, and because the two chains share an address and key format, a holder who has signed on Ethereum since with the same key has exposed the matching ETC address too. No measurement specific to Ethereum Classic has been published.

## Frequently asked questions

### Is Ethereum Classic quantum-safe?

No. Ethereum Classic accounts sign transactions with ECDSA on the secp256k1 curve, as in its Core-Geth client, and a sufficiently large quantum computer running Shor's algorithm would break it. Ethereum Classic has no post-quantum roadmap, adopted proposal or research programme. The one post-quantum item in its process is a work-in-progress draft, opened as a pull request to the ECIPs repository in January 2026 by an outside author, GravityLab LLC, for an EVM precompile that verifies ML-DSA-65 signatures under FIPS 204, so contract wallets could use post-quantum keys. It has not been assigned a number or merged, and ECIP editor Chris Mercer replied that upstream Ethereum is the better place for the work, describing Ethereum Classic as resource-constrained and saying infrastructure and governance need stabilising first. In July 2026 he removed the number 1122 the author had given it, which belongs to the Olympia suite, and said a dedicated range in the 1140s makes sense for post-quantum proposals, with this precompile as its anchor and the number to be assigned at formal submission. Ethereum Classic shares Ethereum's history up to the July 2016 split, so every key revealed before then is revealed on both chains, but nobody has published a measurement of that shared history.

### Is Ethereum Classic quantum-safe?

No. Ethereum Classic signs transactions with ECDSA on the secp256k1 curve, which a sufficiently large quantum computer would break. There is no post-quantum roadmap, numbered improvement proposal or research programme for its signatures.

### Is there an ECIP for post-quantum signatures?

Not a numbered one. In January 2026 an outside author, GravityLab LLC, opened a draft pull request for a precompile that would verify ML-DSA-65 signatures, letting contract wallets use post-quantum keys. It has not been formally submitted or merged. An ECIP editor replied that pursuing it upstream in Ethereum first would be more effective, and in July 2026 removed the number 1122 the author had used, which belongs to the Olympia suite, saying a dedicated 1140s range for post-quantum proposals makes sense, with this one as its anchor, and that the number will be assigned at formal submission.

### Does Ethereum Classic share Ethereum's quantum exposure?

Partly. The two chains share history up to the DAO fork in July 2016, so any key revealed before then is revealed on both. They also share a key format, so a key used on Ethereum after the split exposes the matching Ethereum Classic address. Published measurements of Ethereum's exposure were taken on Ethereum's state after the split, so they do not carry over as figures.

### Will Ethereum's post-quantum work reach Ethereum Classic?

Possibly, because Ethereum Classic has historically adopted Ethereum's EVM changes after they mature, and its maintainers have said that is the path they prefer for this work. Nothing is scheduled, and the upgrade currently drafted for Ethereum Classic, ECIP-1130 Bastion, contains no post-quantum change.

## What this rating means if you hold Ethereum Classic

Plain-language guidance from the same publication, with no product recommendation attached.

- [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md)
- [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md)
- [All guides](https://hardyindex.com/guides.md)


## Sources

1. [Core-Geth crypto package (crypto/crypto.go)](https://github.com/ethereumclassic/core-geth/blob/main/crypto/crypto.go): Ethereum Classic (GitHub) (primary, checked 22 October 2026)
2. [ECIP (draft): Quantum-resistance for Ethereum Classic, ML-DSA verification precompile](https://github.com/ethereumclassic/ECIPs/pull/557): Ethereum Classic ECIPs (GitHub) (primary, checked 22 October 2026)
3. [Quantum-resistance for Ethereum Classic: ML-DSA verification precompile (discussion)](https://github.com/orgs/ethereumclassic/discussions/556): Ethereum Classic (GitHub) (primary, checked 22 October 2026)
4. [Core-Geth ML-DSA-65 precompile work in progress](https://github.com/ethereumclassic/core-geth/pull/5): Ethereum Classic (GitHub) (primary, checked 22 October 2026)
5. [Ethereum Classic Improvement Proposals](https://github.com/ethereumclassic/ECIPs): Ethereum Classic (GitHub) (primary, checked 22 October 2026)
6. [Quantum risk to the Ethereum blockchain](https://www.deloitte.com/nl/en/services/risk-advisory/perspectives/quantum-risk-to-the-ethereum-blockchain.html): Deloitte (primary, checked 22 October 2026)

## How to cite this rating

A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too.

The Hardy Index (2026). Ethereum Classic: quantum readiness assessment. Hardy Score 13.0 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/ethereum-classic

```bibtex
@misc{hardyindex_ethereum_classic_2026,
  author       = {{The Hardy Index}},
  title        = {Ethereum Classic: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/ethereum-classic}},
  note         = {Hardy Score 13.0 of 100, Tier 5: Exposed. Methodology v1.8},
  urldate      = {2026-11-13}
}
```

---

Methodology: https://hardyindex.com/methodology (v1.8).
Cite as: The Hardy Index, "Ethereum Classic", https://hardyindex.com/chains/ethereum-classic, as of 13 November 2026.
