Classix now keeps a current, public copy of the whole Ethereum Classic chain in Google BigQuery, which we describe in Ethereum Classic Is Back in BigQuery. This post is the first research we’ve done with it, measuring how much ETC sits behind exposed public keys.
Yesterday, on 2026-10-07, Justin Drake called on the industry to start planning for what he calls “bunker mode”. He thinks AI-assisted mathematics could break ECDSA, the signature scheme that protects ETC and ETH accounts, before anyone builds a large enough quantum computer, and he asked holders to move their funds to addresses that have never signed a transaction. Vitalik Buterin replied later that day. He agrees that fresh addresses are worth it, and warns that the move itself carries risk.
If it’s not difficult for you, keeping your funds in addresses which have not yet been used to make a transaction is a good idea. If it’s easy for you, do it. But be careful about migrations; I personally have lost more money in botched migrations than I have lost in all hacks combined.
Classix also recommends that large holders move their funds to a fresh address, one that has never signed a transaction. It doesn’t need a new wallet. A new address from the same seed phrase works, because each address has its own private key. There is time to do this calmly. Don’t rush it, and make sure the move goes smoothly, for example by sending a small test amount first.
Initial Findings
These are first results from one day of queries, at block 25,493,265 (2026-10-08 01:58 UTC), when the total ETC supply was 158.5M ETC. 132.0M ETC, 83.3% of all ETC, sits at addresses whose public key is already on-chain. Most of it is in active hands. The 14.5M ETC (9.2%) on exposed keys that haven’t signed in three years or more is the ETC most likely to be left behind.
- Exposed, exchanges and custodiansKnown operators that can move funds when they choose 20.8%32.9M ETC
- Exposed, activeKey on-chain, signed in the last three years 53.4%84.6M ETC
- Exposed, dormantKey on-chain, no signature in three years or more 9.2%14.5M ETC
- ContractsNo key of their own 2.2%3.4M ETC
- Never signedNo signature on ETC or Ethereum 14.5%23.0M ETC
Of the exposed ETC, 125.9M has signed on ETC and 6.1M sits at 162,446 addresses that have only signed on Ethereum, which exposes the same key. Known exchanges and custodians hold 32.9M ETC and can move it whenever they decide to. The dormant slice includes 3.4M ETC taken in the 2016 DAO attack, on a key that hasn’t signed since December 2016. (If you are the DAO hacker and reading this, move the funds to a fresh address!)
We haven’t counted contracts as exposed or safe. A contract has no key of its own, but someone controls it, through owner keys, a multisig, or the depositors of a DeFi or staking pool, and each kind needs its own analysis. On ETC most of the 3.4M ETC in contracts sits in multisig wallets and the DAO refund contract.
SQL Query: ETC Supply Split
-- Today's ETC supply split by whether the holding address has its public key
-- on-chain, and for exposed keys whether they signed in the last three years.
-- A key is exposed once its address has signed a transaction on ETC, or on
-- Ethereum (same key, same address). Scans about 200 GB, mostly Ethereum.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
DECLARE dormant_before TIMESTAMP DEFAULT TIMESTAMP('2023-10-08 01:58:10'); -- three years earlier
WITH etc_signed AS ( -- last ETC signature per address
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
eth_signed AS ( -- last Ethereum signature per address
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS ( -- contracts have no key of their own
SELECT DISTINCT address FROM `classix-etc-data.crypto_ethereum_classic.contracts`
)
SELECT
CASE
WHEN c.address IS NOT NULL THEN 'contract'
WHEN COALESCE(etc.last_signed, eth.last_signed) IS NULL THEN 'never signed'
WHEN COALESCE(etc.last_signed, eth.last_signed) < dormant_before THEN 'exposed, dormant'
ELSE 'exposed, active'
END AS category,
COUNT(*) AS addresses,
ROUND(SUM(b.eth_balance) / 1e18) AS etc
FROM `classix-etc-data.crypto_ethereum_classic.balances` AS b
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE b.eth_balance > 0
GROUP BY category
ORDER BY etc DESCThe bar splits the exposed ETC by the year each key last signed, using the last Ethereum signature for keys exposed only there. 114.4M ETC sits on keys that signed in 2025 or 2026. That is good news, because most of the exposed supply is with people who are still active and can move it. The 17.7M ETC on keys last used between 2015 and 2024 belongs to holders who are harder to reach.
SQL Query: Exposed ETC by Year of Last Signature
-- ETC on exposed keys, by the year each key last signed. Keys that signed on
-- ETC are dated by their last ETC signature, keys exposed only on Ethereum by
-- their last Ethereum signature. Scans about 200 GB, mostly Ethereum.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
WITH etc_signed AS (
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
eth_signed AS (
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS (
SELECT DISTINCT address FROM `classix-etc-data.crypto_ethereum_classic.contracts`
)
SELECT
EXTRACT(YEAR FROM COALESCE(etc.last_signed, eth.last_signed)) AS last_signed_in,
COUNT(*) AS addresses,
ROUND(SUM(b.eth_balance) / 1e18) AS etc
FROM `classix-etc-data.crypto_ethereum_classic.balances` AS b
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE b.eth_balance > 0
AND c.address IS NULL
AND COALESCE(etc.last_signed, eth.last_signed) IS NOT NULL
GROUP BY last_signed_in
ORDER BY last_signed_inThe ten largest exposed balances hold 85.2M ETC, 53.8% of all ETC, all on keys that signed in 2025 or 2026. Three carry a public exchange label from the Open Labels Initiative, shown on their Blockscout pages, and we name those. Two more we have tied to exchange or custodian operators from on-chain evidence alone, so we mark them as known without naming them.
| Address | ETC | Last signed | Holder | |
|---|---|---|---|---|
| 1 | 0x13cdee29…6d02ad | 36.23M | 2026-09-24 | Unknown |
| 2 | 0x00cd5bf5…0ade91 | 12.58M | 2026-04-20 | Unknown |
| 3 | 0xd4e36ae1…af5d4d | 9.90M | 2025-12-04 | Known |
| 4 | 0xcea13c17…4c21d8 | 8.35M | 2026-03-05 | Unknown |
| 5 | 0x87932916…5e494f | 7.26M | 2026-09-22 | Unknown |
| 6 | 0x5a52e96b…70efcb | 4.63M | 2026-10-07 | Binance 28 |
| 7 | 0x46b1a921…1dff32 | 2.75M | 2026-09-23 | Known |
| 8 | 0x0051ef92…0841b3 | 1.43M | 2026-10-08 | Bybit 21 |
| 9 | 0xc882b111…84f071 | 1.21M | 2026-05-09 | Gate.io 5 |
| 10 | 0x3f81dd80…1e7b9d | 0.87M | 2026-05-29 | Unknown |
SQL Query: Ten Largest Active Exposed ETC Balances
-- The ten largest balances on keys that signed on ETC in 2025 or 2026.
WITH etc_signed AS (
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= TIMESTAMP('2026-10-08 01:58:10')
GROUP BY address
)
SELECT b.address, ROUND(b.eth_balance / 1e18) AS etc, DATE(s.last_signed) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.balances` AS b
JOIN etc_signed AS s USING (address)
WHERE s.last_signed >= TIMESTAMP('2025-01-01')
ORDER BY b.eth_balance DESC
LIMIT 10The holders who most need to hear about this are the ones who have gone quiet. These are the ten largest exposed balances on keys that last signed before 2025, 7.4M ETC between them. Six are genesis allocations from 2015 that have never signed on ETC. Their keys are public because the same addresses signed on Ethereum between 2018 and 2022, and their owners may not know they still hold ETC.
| Address | ETC | Last signed | Signed on | Holder | |
|---|---|---|---|---|---|
| 1 | 0x5e8f0e63…06df5a | 3.36M | 2016-12-07 | ETC | 2016 DAO attacker |
| 2 | 0xca9349a6…3bc186 | 0.95M | 2023-07-08 | ETC | Unknown |
| 3 | 0x51f9c432…9160eb | 0.53M | 2022-04-24 | Ethereum | Genesis allocation |
| 4 | 0x3bf86ed8…5e576b | 0.45M | 2022-01-10 | Ethereum | Genesis allocation |
| 5 | 0xbf09d770…781495 | 0.44M | 2018-12-05 | Ethereum | Genesis allocation |
| 6 | 0x4845b0d7…6fd9b4 | 0.38M | 2021-05-24 | ETC | Unknown |
| 7 | 0x9d2bfc36…86c60d | 0.38M | 2018-11-19 | Ethereum | Genesis allocation |
| 8 | 0x2b241f03…7cdf4b | 0.38M | 2018-11-19 | Ethereum | Genesis allocation |
| 9 | 0x7d04d2ed…d4c8a6 | 0.31M | 2022-01-21 | Ethereum | Genesis allocation |
| 10 | 0x75dcf92c…b9915e | 0.19M | 2024-03-13 | ETC | Unknown |
If you know who holds one of these addresses, please send them this article. The same goes for anyone you know who bought ETH in the 2015 crowdsale and never moved their ETC.
SQL Query: Ten Largest Quiet Exposed ETC Balances
-- The ten largest balances on exposed keys that last signed before 2025, on
-- ETC, or on Ethereum for keys that never signed on ETC. Contracts excluded.
-- Scans about 200 GB, mostly Ethereum.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
WITH etc_signed AS (
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
eth_signed AS (
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS (
SELECT DISTINCT address FROM `classix-etc-data.crypto_ethereum_classic.contracts`
)
SELECT
b.address,
ROUND(b.eth_balance / 1e18) AS etc,
DATE(COALESCE(etc.last_signed, eth.last_signed)) AS last_signed,
IF(etc.address IS NOT NULL, 'ETC', 'Ethereum') AS signed_on
FROM `classix-etc-data.crypto_ethereum_classic.balances` AS b
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE c.address IS NULL
AND COALESCE(etc.last_signed, eth.last_signed) < TIMESTAMP('2025-01-01')
ORDER BY b.eth_balance DESC
LIMIT 10How Public Keys Get Exposed
An ETC address isn’t the public key itself. It’s the last 20 bytes of a hash of the key, and hashes hold up well against quantum computers, so an address that has only ever received ETC isn’t vulnerable, and should be able to migrate to a new scheme safely when that scheme exists. That changes the first time the address sends a transaction. The public key can be recovered from the signature, and it stays on-chain for good.
Here’s the whole thing in a few lines of TypeScript, using viem.
TypeScript Example: Recovering a Public Key From a Signature
import { keccak256, parseTransaction, recoverPublicKey, serializeTransaction } from 'viem'
import { generatePrivateKey, privateKeyToAccount } from 'viem/accounts'
// A private key is 32 random bytes. Only the owner ever sees it.
const privateKey = generatePrivateKey()
const account = privateKeyToAccount(privateKey)
// The public key comes from the private key by elliptic-curve multiplication
// on secp256k1. Running that backwards is what Shor's algorithm would do.
const publicKey = account.publicKey // 0x04 followed by 64 bytes
// e.g. 0x04976104…9342dff
// The address is the last 20 bytes of the Keccak-256 hash of the public key.
// A hash can't be run backwards, so the address on its own reveals nothing.
const keyBytes = publicKey.replace(/^0x04/, '0x') // drop the 04 marker, keep the 0x prefix
const address = `0x${keccak256(keyBytes).slice(-40)}` // last 20 bytes of the hash
// e.g. 0x4e5ec33e1e7bd13186e6e0c37127b4f0510f60d7
console.log(address === account.address.toLowerCase()) // true
// Sending ETC means signing a transaction with the private key.
const signed = await account.signTransaction({
chainId: 61, // Ethereum Classic mainnet
to: account.address,
value: 1n,
nonce: 0,
gas: 21000n,
gasPrice: 1_000_000_000n,
})
// Anyone who sees the signed transaction can recover the full public key
// from its signature. That's how every node checks who sent it.
const { r, s, v, yParity, ...unsigned } = parseTransaction(signed)
const recovered = await recoverPublicKey({
hash: keccak256(serializeTransaction(unsigned)),
signature: { r: r!, s: s!, yParity: yParity! },
})
console.log(recovered === publicKey) // true
// This is why only addresses that have sent at least one transaction are
// exposed. Until then the chain holds nothing but the hash.The Quantum & AI Threat
Q-Day is the name for the day a quantum computer gets large enough to run Shor’s algorithm against the elliptic-curve signatures that protect ETC accounts, and work out a private key from its public key. Nobody knows when that day comes, but estimates have been moving closer. After Google’s March 2026 paper cut the machine needed to break these signatures to under 500,000 qubits, co-author Justin Drake put at least a 10% chance on it arriving by 2032. When it does, any account whose public key is known is open to whoever is willing to point a quantum machine at it. The first machines will be slow and expensive to run, so the biggest balances are the first targets.
Then, later in the year, Drake made another recommendation that caught the whole industry’s attention, in a post explaining why he thinks ECDSA could fall before Q-Day.
IMO it is now reasonable to brace for the possibility that ECDSA breaks before qday, in the worst case in months not years. By “break” I mean fast private key recovery (e.g. in one week) on available hardware (e.g. a large GPU cluster).
He points to several long-standing conjectures in mathematics that fell over the past few days, and to the 722 mathematical results OpenAI published the day before his post.
Vitalik agrees that AI adds to the risk.
I don’t recommend anyone scramble to move their funds to new wallets today. But we should take the risks to cryptography from AI-accelerated math seriously, and minimize our exposure to not just quantum-vulnerable cryptography, but also potentially AI-vulnerable cryptography.
(and it’s also another reason, along with quantum, why ECDSA might fall even faster than expected, hence the “fresh address” recommendation)
Shor’s algorithm and a classical attack on secp256k1 would both start from a public key, so either way the ETC at risk is ETC controlled by a wallet whose public key is exposed, which is any wallet that has made a transaction.
Post-quantum security was already under discussion in the ETC community before this post. Community Call 58 in August discussed a draft ECIP for an ML-DSA precompile. ML-DSA is a lattice-based signature scheme, and Vitalik names lattices as “the core new area of risk”. For that reason Ethereum’s lean roadmap uses only hash-based signatures.
Compared to Ethereum
We ran the same queries against Google’s public Ethereum dataset, bigquery-public-data.crypto_ethereum, at the same moment. Ethereum has one slice ETC doesn’t, staked ETH.
- StakedEstimated, on the beacon chain, exposure not analysed 35.0%41.2M ETH
- Exposed, activeKey on-chain, signed in the last three years 27.3%32.2M ETH
- Exposed, dormantKey on-chain, no signature in three years or more 8.2%9.6M ETH
- ContractsNo key of their own 7.8%9.2M ETH
- Never signedNo signature on Ethereum or ETC 21.7%25.5M ETH
The staked slice is an estimate, deposits minus withdrawals, and we haven’t analysed whether validators’ keys and withdrawal addresses are exposed.
SQL Query: Staked ETH Estimate
-- Rough size of staked ETH: everything deposited into the beacon deposit
-- contract, minus everything withdrawn back to the execution layer since
-- Shapella. Leaves out rewards earned but not yet withdrawn.
SELECT
(SELECT SUM(eth_balance) / 1e18 FROM `bigquery-public-data.crypto_ethereum.balances`
WHERE address = '0x00000000219ab540356cbb839cbe05303d7705fa') AS deposited_eth,
(SELECT SUM(CAST(w.amount AS NUMERIC)) / 1e9 FROM `bigquery-public-data.crypto_ethereum.blocks`, UNNEST(withdrawals) AS w
WHERE timestamp <= TIMESTAMP('2026-10-08 01:58:10')) AS withdrawn_ethOf the other 76.5M ETH, 41.8M (54.6%) sits at addresses whose public key is on-chain, against 83.3% for ETC. A third of it, 25.5M, is at addresses that have never signed, where ETC has 14.5%. The dormant share is close on both chains, 12.6% of that 76.5M on Ethereum against 9.8% on ETC before we take out known exchanges. That fits the 50 to 65% of Ether at key-revealed accounts in Quantum Horizon. We haven’t split out Ethereum’s exchanges, so its active slice still includes them. The 9.2M ETH in contracts needs the same further analysis as on ETC. The largest holders there are wrapped ETH, at 2.2M, bridges to layer 2 networks, exchange multisigs and DeFi pools.
SQL Query: ETH Supply Split
-- Ethereum's ETH supply split the same way as the ETC pie. The beacon deposit
-- contract holds every ETH ever staked and is its own row.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
DECLARE dormant_before TIMESTAMP DEFAULT TIMESTAMP('2023-10-08 01:58:10'); -- three years earlier
WITH eth_signed AS ( -- last Ethereum signature per address
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
etc_signed AS ( -- last ETC signature per address (same key)
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS (
SELECT DISTINCT address FROM `bigquery-public-data.crypto_ethereum.contracts`
),
holders AS (
SELECT b.address, b.eth_balance,
COALESCE(eth.last_signed, etc.last_signed) AS last_signed,
IF(eth.address IS NOT NULL, 'Ethereum', 'ETC') AS signed_on,
c.address IS NOT NULL AS is_contract
FROM `bigquery-public-data.crypto_ethereum.balances` AS b
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE b.eth_balance > 0
)
SELECT
CASE
WHEN address = '0x00000000219ab540356cbb839cbe05303d7705fa' THEN 'beacon deposit contract'
WHEN is_contract THEN 'contract'
WHEN last_signed IS NULL THEN 'never signed'
WHEN last_signed < dormant_before THEN 'exposed, dormant'
ELSE 'exposed, active'
END AS category,
COUNT(*) AS addresses,
ROUND(SUM(eth_balance) / 1e18) AS eth
FROM holders
GROUP BY category
ORDER BY eth DESC27.3M ETH, 65.3% of Ethereum’s exposed ETH outside staking pools, sits on keys that signed in 2025 or 2026, against 86.6% on ETC. More of the exposed ETH on Ethereum has been sitting still for longer, 14.5M ETH on keys last used between 2015 and 2024.
SQL Query: Exposed ETH by Year of Last Signature
-- ETH on exposed keys by the year each key last signed.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
DECLARE dormant_before TIMESTAMP DEFAULT TIMESTAMP('2023-10-08 01:58:10'); -- three years earlier
WITH eth_signed AS ( -- last Ethereum signature per address
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
etc_signed AS ( -- last ETC signature per address (same key)
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS (
SELECT DISTINCT address FROM `bigquery-public-data.crypto_ethereum.contracts`
),
holders AS (
SELECT b.address, b.eth_balance,
COALESCE(eth.last_signed, etc.last_signed) AS last_signed,
IF(eth.address IS NOT NULL, 'Ethereum', 'ETC') AS signed_on,
c.address IS NOT NULL AS is_contract
FROM `bigquery-public-data.crypto_ethereum.balances` AS b
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE b.eth_balance > 0
)
SELECT EXTRACT(YEAR FROM last_signed) AS last_signed_in, COUNT(*) AS addresses,
ROUND(SUM(eth_balance) / 1e18) AS eth
FROM holders
WHERE NOT is_contract AND last_signed IS NOT NULL
GROUP BY last_signed_in
ORDER BY last_signed_inThe largest exposed balances on Ethereum are mostly exchanges and custodians, and on Ethereum their addresses carry public labels, from the Open Labels Initiative via Blockscout. Eight of the ten largest on keys that signed in 2025 or 2026 are labelled.
| Address | ETH | Last signed | Holder | |
|---|---|---|---|---|
| 1 | 0x40b38765…18e489 | 1.22M | 2026-04-20 | Robinhood 1 |
| 2 | 0x0e58e899…d9bfcd | 0.98M | 2026-10-01 | Upbit 41 |
| 3 | 0x742d35cc…38f44e | 0.48M | 2026-10-08 | Bitfinex: Hot Wallet |
| 4 | 0x47ac0fb4…a6d503 | 0.45M | 2026-09-16 | Binance: Cold Wallet |
| 5 | 0xf977814e…41acec | 0.42M | 2026-10-07 | Binance 8 |
| 6 | 0x9f1799fb…756e83 | 0.32M | 2026-06-23 | Kraken: Cold Wallet 4 |
| 7 | 0x1d48963d…030270 | 0.29M | 2026-09-25 | Unknown |
| 8 | 0x8d05d992…ae6fcf | 0.22M | 2026-08-21 | Kraken: Cold Wallet 3 |
| 9 | 0x2f2d854c…2c9b10 | 0.17M | 2026-02-18 | Unknown |
| 10 | 0xb61a16bd…d1712f | 0.16M | 2026-09-23 | Deribit: Coinbase Prime Custody |
SQL Query: Ten Largest Active Exposed ETH Balances
-- The ten largest ETH balances on keys that signed in 2025 or 2026.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
DECLARE dormant_before TIMESTAMP DEFAULT TIMESTAMP('2023-10-08 01:58:10'); -- three years earlier
WITH eth_signed AS ( -- last Ethereum signature per address
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
etc_signed AS ( -- last ETC signature per address (same key)
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS (
SELECT DISTINCT address FROM `bigquery-public-data.crypto_ethereum.contracts`
),
holders AS (
SELECT b.address, b.eth_balance,
COALESCE(eth.last_signed, etc.last_signed) AS last_signed,
IF(eth.address IS NOT NULL, 'Ethereum', 'ETC') AS signed_on,
c.address IS NOT NULL AS is_contract
FROM `bigquery-public-data.crypto_ethereum.balances` AS b
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE b.eth_balance > 0
)
SELECT address, ROUND(eth_balance / 1e18) AS eth, DATE(last_signed) AS last_signed, signed_on
FROM holders
WHERE NOT is_contract AND last_signed >= TIMESTAMP('2025-01-01')
ORDER BY eth_balance DESC
LIMIT 25The ten largest on keys that last signed before 2025 include exchange wallets that sign rarely, and 169k ETH in a QuadrigaCX hot wallet that hasn’t signed since 2016.
| Address | ETH | Last signed | Holder | |
|---|---|---|---|---|
| 1 | 0xbe0eb53f…4d33e8 | 2.00M | 2024-11-30 | Binance 7 |
| 2 | 0xe92d1a43…85226f | 0.45M | 2019-02-21 | Bitfinex 19 |
| 3 | 0xca8fa8f0…8affca | 0.33M | 2019-02-21 | Unknown |
| 4 | 0x81036832…5c225e | 0.28M | 2019-02-21 | Bitfinex 20 |
| 5 | 0x5b5b69f4…bc7ec4 | 0.17M | 2016-07-30 | QuadrigaCX: Hot Wallet |
| 6 | 0x8ae880b5…59f293 | 0.11M | 2021-02-20 | Unknown |
| 7 | 0x4eac9ce5…be30bc | 0.10M | 2019-06-24 | Unknown |
| 8 | 0xd9858d57…eff98a | 0.10M | 2024-03-06 | Unknown |
| 9 | 0xd8d98ee9…ee8604 | 0.10M | 2022-09-14 | Bitfinex_0xd8d9 |
| 10 | 0x86a6a008…94f8d6 | 0.09M | 2021-02-23 | Unknown |
SQL Query: Ten Largest Quiet Exposed ETH Balances
-- The ten largest ETH balances on exposed keys that last signed before 2025.
DECLARE snapshot TIMESTAMP DEFAULT TIMESTAMP('2026-10-08 01:58:10');
DECLARE dormant_before TIMESTAMP DEFAULT TIMESTAMP('2023-10-08 01:58:10'); -- three years earlier
WITH eth_signed AS ( -- last Ethereum signature per address
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
etc_signed AS ( -- last ETC signature per address (same key)
SELECT from_address AS address, MAX(block_timestamp) AS last_signed
FROM `classix-etc-data.crypto_ethereum_classic.transactions`
WHERE block_timestamp <= snapshot
GROUP BY address
),
contracts AS (
SELECT DISTINCT address FROM `bigquery-public-data.crypto_ethereum.contracts`
),
holders AS (
SELECT b.address, b.eth_balance,
COALESCE(eth.last_signed, etc.last_signed) AS last_signed,
IF(eth.address IS NOT NULL, 'Ethereum', 'ETC') AS signed_on,
c.address IS NOT NULL AS is_contract
FROM `bigquery-public-data.crypto_ethereum.balances` AS b
LEFT JOIN eth_signed AS eth USING (address)
LEFT JOIN etc_signed AS etc USING (address)
LEFT JOIN contracts AS c USING (address)
WHERE b.eth_balance > 0
)
SELECT address, ROUND(eth_balance / 1e18) AS eth, DATE(last_signed) AS last_signed, signed_on
FROM holders
WHERE NOT is_contract AND last_signed < TIMESTAMP('2025-01-01')
ORDER BY eth_balance DESC
LIMIT 25Where ETC Stands
ETC is in a good position compared with Bitcoin and Ethereum. Before we take out known exchanges, 9.8% of ETC sits on exposed keys that have gone quiet, against 12.6% of Ethereum’s ETH outside staking. For Bitcoin, Quantum Horizon, a June 2026 paper by Iosif Gershteyn and Jacob Alber, finds that of roughly six million exposed coins “only about 2.3 million are irreducibly at risk”, around 12% of supply.
The consensus layer is different too. Ethereum’s proof of stake rests on validators’ BLS signatures, which are also elliptic-curve based and so also open to Shor’s algorithm, so Ethereum has to replace the signatures that secure the chain as well as the ones that secure accounts. ETC’s proof of work rests on hashing, which a quantum computer only speeds up modestly, so on ETC it’s the accounts that need to move and not the consensus.
Bitcoin’s dormant exposed coins are spread over tens of thousands of early addresses, many with 50 BTC each. On ETC, eight addresses hold 5.4M of the 10.9M ETC on keys that last signed on ETC more than three years ago. A few large holders are easier to reach, and when they move, it protects the rest of the network too. Coins that have moved are coins an attacker can’t dump on the market, and a sudden dump would hit the price and with it the mining that keeps ETC secure.
If you hold a large amount of ETC or ETH at an address that has signed a transaction, move the bulk of it to a fresh address, and if you know someone with old coins on either chain, send them this post. We’ll publish further research and advice for specific cases like contracts and multisigs, so follow us on X at @classix_dev for updates. Write to [email protected] if you need help.