1 Signature scheme 0/10, weighted 30%
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
2 Deployment stage 1/10, weighted 25%
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
3 NIST alignment 3/10, weighted 15%
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.
source
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.
4 Migration path 2/10, weighted 15%
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.
source
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.
5 Exposure 2/10, weighted 10%
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.
source
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.
6 Verification 2/10, weighted 5%
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.
source
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.