Circle Explains Why Blockchain Quantum Migration Is So Difficult

Here’s an uncomfortable truth rarely acknowledged: the moment your blockchain wallet signs a transaction, it exposes your public key to the world. This key, not your cold-stored seed phrase, is what a future quantum computer will target.

Circle detailed this challenge in a January 6, 2026 blog post by principal software engineer Mira Belenkiy, accompanied by an Arc post-quantum whitepaper. Do note that this is vendor-published material, not peer-reviewed research. As a stablecoin issuer and operator of the Arc blockchain, Circle has a vested interest in appearing quantum-ready. All claims that follow are either directly from Circle or from third parties they cite. Nevertheless, this roadmap offers one of the few detailed public insights into how a major issuer plans such a migration, and the engineering trade-offs discussed are significant.

Shor’s Algorithm Targets Signatures, Not Hashes

Let’s clarify what breaks and what remains secure.

Blockchains currently use elliptic-curve cryptography for transaction signatures. Bitcoin and Ethereum use 65-byte ECDSA signatures, whereas Solana and Stellar use 64-byte Ed25519. The security of these systems relies on the difficulty of recovering a private key from a public one for classical computers. However, Shor’s algorithm, run on a quantum computer, can accomplish this with ease. Circle states that any protocol built on elliptic curves or RSA is vulnerable.

Why?

Shor’s algorithm can solve the discrete logarithm problem in polynomial time, dismantling the fundamental security assumption of these cryptographic systems.

Conversely, hash functions like SHA-256 and symmetric encryption like AES are largely safe. Though Grover’s algorithm offers quantum computers a quadratic speedup against hashes, simply doubling the hash size can restore the security margin. A Terra Quantum survey paper on arXiv corroborates this, explaining that Shor’s algorithm compromises ECDSA, Ed25519, and BLS signatures, whereas Grover’s algorithm only marginally affects hash functions.

The immediate threat isn’t a quantum computer stealing funds from a dormant wallet. The danger lies in exposed public keys. An active address that has signed even a single transaction has permanently broadcast its key to the blockchain. This exemplifies the “harvest-now, decrypt-later” problem in a blockchain context.

Post-Quantum Signatures Are Large, and Consensus Is Lacking

The new generation of post-quantum signatures is considerably larger than current blockchain signatures, presenting a substantial challenge.

Circle highlights several candidates. ML-DSA, a NIST-standardized lattice scheme, is 2,420 bytes and already has hardware security module support. Ethereum is considering Falcon, which at 666 bytes remains relatively compact but has not yet completed formal standardization. Aptos has proposed SLH-DSA-SHA2-128s, a hash-based scheme of 7,856 bytes that prioritizes security by relying solely on SHA-2.

Consider these numbers. A 65-byte ECDSA signature could balloon to anywhere from 666 to 7,856 bytes. This is an unavoidable trade-off: larger signatures, slower verification, or incompatibility with existing hardware wallets. The Terra Quantum paper deems both SLH-DSA and ML-DSA “not really suitable for ordinary transactions” due to their size alone, identifying Falcon as a better balance. There is no easy solution.

Furthermore, Ethereum’s validator roadmap favors XMSS for consensus signatures. Circle clearly identifies a key limitation: XMSS requires signers to maintain state, tracking which one-time keys have been used. Though a continuously running validator node can manage this, your everyday wallet, secured in a hardware security module or cold storage, cannot. Accidental reuse of a stateful key compromises security. This inherently leads to fragmentation, with different schemes for validators and wallets from the outset.

The Migration Is the Real Hurdle, Not the Math

The necessary algorithms already exist, having been finalized by NIST. The true difficulty lies in migrating every user.

Active addresses must migrate before Q-Day because their public keys are already exposed. Circle cites a third-party estimate suggesting that migrating all Bitcoin UTXOs would require 76 days of continuous processing. This figure originates from a University of Kent preprint on arXiv by Pont, Kearney, Moyler, and Perez-Delgado. However, the fine print reveals this is a non-tight lower bound, which means the authors deliberately omitted transaction overhead and assumed ideal packing to arrive at an unrealistically optimistic number. 

Their actual point: even in a best-case scenario, Bitcoin cannot function as a normal cryptocurrency for 76 consecutive days, which implies the upgrade would need to be spread over months of throttled service.

Passive addresses have a slight advantage. Circle notes that some Ed25519 and BIP-32/BIP-39-derived addresses can be recovered after Q-Day by proving knowledge of the original seed. But this offers little comfort to those who have already spent funds.

The zero-knowledge layer also requires significant changes. Popular proof systems like Groth16, Halo2, and PlonK rely on elliptic curves, making them vulnerable to quantum attacks. The solution involves transitioning to STARKs and FRI-based systems, which depend on hashes. Circle states that Starknet is already moving to FRI, and Ethereum is evaluating FRI, STIR, and WHIR. The trade-off, according to Circle, is larger proofs and slower verification, which is the same recurring cost.

MPC wallets and threshold signatures, widely used by institutions for key custody, currently depend on elliptic curves and will all need replacement. The hardware infrastructure is also not ready. Circle indicates that post-quantum HSMs are only just emerging, and blockchain-specific versions won’t be produced until demand exist, which is a chicken-and-egg problem Circle acknowledges but doesn’t resolve.

Identifying Reality vs. Marketing Claims

Let’s be candid about the limitations of this information.

Circle’s blog post is an engineering piece from a vendor. The Arc whitepaper, at least its public landing page, describes plans for quantum-secure signatures, private execution environments, validator hardening, and account recovery. It also includes Circle’s own disclaimer that “no post-quantum design can eliminate all future security risk.”

The 2030 Q-Day estimate cited by Circle’s post doesn’t trace back to a primary institutional source; it links to an aggregator. Therefore, “2030” is one expert guess among many, not a definitive timeline. Migration planning frameworks like the 12-step roadmap from QuantumGate and the Meta playbook writeup on postquantum.com offer similar “inventory first, migrate in waves” logic. However, these are guidelines, not proof of deadlines.

Circle’s own disclaimer says this represents current thinking that may evolve, and no design eliminates all risk. This reflects the same caution security writers apply universally, from account recovery methods to software supply-chain trust. Every layer contains undiscovered vulnerabilities.

Though algorithms are standardized and roadmaps are being developed, whether the migration concludes before exposed keys become vulnerable is an operational challenge, not a mathematical one. And operational challenges frequently miss deadlines.