Will Quantum Computers Break EURC?

Will quantum computers break EURC? It is a precise technical question, and it deserves a precise answer. EURC, the euro-pegged stablecoin issued by Circle on Ethereum and other EVM-compatible chains, inherits Ethereum's ECDSA signature scheme. That scheme is mathematically vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. This article explains exactly how that exposure works, what conditions would have to be met for it to become a real threat, where expert opinion currently places the timeline, and what EURC holders can practically do to reduce their risk.

What EURC Is and How It Works at the Protocol Level

EURC is a regulated, fully-reserved euro stablecoin issued by Circle. Each token is backed 1:1 by euro-denominated cash and short-duration sovereign debt held in segregated accounts. On-chain, it is implemented as an ERC-20 smart contract, and like every other ERC-20 token, ownership and transfers are secured by Ethereum's account model.

That account model rests on two cryptographic primitives:

• ECDSA (Elliptic Curve Digital Signature Algorithm) over the secp256k1 curve, used to sign every transaction.
• Keccak-256, a hash function used to derive Ethereum addresses from public keys and to secure the Merkle trees inside each block.

When you send EURC, your wallet software signs the transaction with your private key using ECDSA. The network verifies the signature using your public key. As long as the discrete-logarithm problem on elliptic curves remains computationally hard, no one can derive your private key from your public key. Quantum computers, specifically Shor's algorithm running on a cryptographically relevant quantum computer (CRQC), break that hardness assumption.

Hash functions are a different story. Grover's algorithm gives a quantum computer a quadratic speedup against symmetric primitives and hash functions, effectively halving the security level. Keccak-256's 256-bit output drops to roughly 128-bit quantum security, which remains adequate by current standards. The existential threat to EURC holders is ECDSA, not Keccak.

---

How Shor's Algorithm Threatens ECDSA

Shor's algorithm, published in 1994, solves the integer factorisation and discrete-logarithm problems in polynomial time on a quantum computer. ECDSA security relies entirely on the discrete-logarithm problem being hard. On a classical computer, deriving a private key from a public key on secp256k1 would take longer than the age of the universe. On a CRQC with enough logical qubits, the same operation becomes feasible in hours or less, depending on implementation.

The Attack Window

The attack is only possible when a public key is exposed. On Ethereum, public keys are not always visible. There are two address types:

1. Addresses that have never sent a transaction. Only the address hash (the last 20 bytes of the Keccak hash of the public key) is on-chain. A quantum attacker cannot reverse Keccak to recover the public key, so these addresses are not directly vulnerable to ECDSA-based attacks.
2. Addresses that have sent at least one transaction. The public key is permanently revealed in the transaction signature data. A CRQC could, in principle, derive the private key from that public key and drain any remaining balance.

Most active EURC holder addresses fall into the second category, because users transfer EURC regularly. A dormant address that has only ever received EURC and never sent it retains the hash-only protection, but the moment it initiates a transfer, the public key is exposed.

What "Break" Actually Means

"Breaking EURC" via quantum attack does not mean breaking Circle's reserves or the euro peg. It means an attacker who controls a CRQC could steal EURC balances from exposed addresses, exactly as if they had obtained the holder's private key through any other means. Circle's smart contract, reserve backing, and regulatory status would be unaffected. The damage is individual theft at scale, not a protocol collapse.

---

What Would Have to Be True for Q-Day to Threaten EURC Holders

Several independent conditions must all be satisfied simultaneously:

The most rigorous public estimate, cited in NIST's post-quantum cryptography documentation, is that a CRQC capable of breaking 256-bit elliptic curve keys would require approximately 4,000 logical qubits running millions of error-corrected gate operations. Current leading systems from IBM, Google, and others operate in the hundreds to low thousands of physical qubits with error rates that require substantial overhead for logical qubit construction. The ratio of physical to logical qubits needed for fault tolerance is currently estimated at roughly 1,000:1 under leading error-correction codes like surface codes, implying millions of physical qubits would be needed.

---

Realistic Timeline: What Experts and Institutions Say

Framing this accurately matters. Quantum threat timelines are genuinely uncertain, and both dismissal and panic are unwarranted.

Near-Term (2025–2030)

No credible public roadmap produces a CRQC capable of breaking secp256k1 in this window. IBM's public roadmap targets 100,000 physical qubits by 2033 for utility-scale (not cryptographically relevant) tasks. Google's 2024 Willow chip demonstrated improved error correction but remains far from the scale needed for Shor's against 256-bit curves.

Medium-Term (2030–2040)

This is where institutional concern begins. The U.S. National Security Agency's CNSA 2.0 suite mandates transition away from elliptic curve cryptography for national security systems by 2035. NIST finalised its first post-quantum cryptographic standards in 2024 (FIPS 203, 204, 205), explicitly anticipating that migration must begin now to complete before threats materialise.

Long-Term (2040+)

"Harvest now, decrypt later" attacks are already theoretically underway: adversaries with long-term interests may be recording encrypted classical traffic today, intending to decrypt it once a CRQC is available. For blockchain, the equivalent is that addresses with exposed public keys today will remain exposed indefinitely. Any EURC balance sitting in such an address in 2040 is vulnerable if a CRQC exists by then.

The honest summary: no one can give a precise date for Q-day. Credible estimates cluster in the 10-to-20-year range for a cryptographically relevant machine, with significant uncertainty in both directions. That timeframe is long enough to plan, and short enough that planning should begin.

---

What EURC Holders Can Do Right Now

Waiting for the problem to become acute is not a sensible strategy given the lead time required for ecosystem migration. Practical steps exist today.

Address Hygiene

• Use fresh addresses for every deposit. If a receiving address has never signed a transaction, its public key is not exposed. This limits the attack surface to the moment of withdrawal, where the signature is unavoidable.
• Move balances off long-used addresses. If you hold significant EURC on an address that has sent dozens of transactions, consider consolidating to a fresh address now, before quantum threats are practical.
• Avoid address reuse. Many wallet applications reuse addresses for convenience. Disable this where possible.

Monitor Ethereum's Migration Path

Ethereum's core developers have discussed quantum-safe account abstraction upgrades. EIP-7560 introduces native account abstraction that could support alternative signature schemes, including NIST-approved post-quantum algorithms such as ML-KEM (CRYSTALS-Kyber) and ML-DSA (CRYSTALS-Dilithium). Keep track of Ethereum Improvement Proposals in this space. A network-level migration would protect all ERC-20 holdings, including EURC, without requiring individual action beyond upgrading wallet software.

Diversify Across Signature Schemes

For holders with material crypto exposure, holding assets across wallets that use different underlying signature schemes reduces correlated risk. A failure in secp256k1 does not simultaneously compromise schemes built on different mathematical problems.

Consider Natively Post-Quantum Designs

Some newer projects are building quantum resistance into their architecture from inception rather than retrofitting it. BMIC.ai, for example, uses lattice-based cryptography aligned with NIST's PQC standards in its wallet infrastructure, meaning its signature scheme is not based on ECDSA and therefore does not share EURC's secp256k1 exposure. For investors who consider long-horizon quantum risk material, the architectural baseline of any new custody solution is worth examining.

---

How Post-Quantum Signature Schemes Differ from ECDSA

Understanding the alternative helps frame why migration is non-trivial but achievable.

Lattice-Based Cryptography

NIST's primary post-quantum signature standard, ML-DSA (formerly CRYSTALS-Dilithium), is based on the hardness of the Module Learning With Errors (MLWE) problem. No known quantum algorithm, including Shor's, provides an efficient solution to MLWE. Signatures are larger than ECDSA (roughly 2–3 KB versus 64 bytes), which has gas-cost implications on Ethereum, but the cryptographic security guarantee survives a CRQC.

Hash-Based Signatures

SPHINCS+ (now SLH-DSA under NIST FIPS 205) relies only on hash function security. It is quantum-resistant given Grover's algorithm halvings (128-bit quantum security at 256-bit output) and is considered extremely conservative because it makes minimal structural assumptions. Signatures are large (8–50 KB depending on parameterisation), making them expensive on-chain.

Comparison: ECDSA vs. Leading PQC Signature Schemes

The on-chain feasibility column is the reason Ethereum cannot simply flip a switch. Gas costs, transaction throughput, and smart contract compatibility all require careful engineering before any of these schemes can replace ECDSA at the base layer.

---

The Bottom Line: Threat Is Real, Urgency Is Proportionate

EURC's quantum exposure is not hypothetical in principle, but it is not imminent in practice. The signature scheme it inherits from Ethereum is mathematically vulnerable to a CRQC running Shor's algorithm, and most active EURC holder addresses have exposed public keys. The conditions required for an actual attack do not yet exist, and credible timelines place the earliest plausible Q-day a decade or more away.

That window is enough time for Ethereum to migrate its signature infrastructure, for Circle to adapt EURC's contract accordingly, and for holders to adopt better address hygiene. The productive response is informed preparation, not panic selling or dismissal. Holders who understand the mechanism are far better positioned to act when concrete migration paths emerge at the protocol level.