How does Circle plan to handle a USDC lock-changing project spanning more than 30 blockchains?
Compiled & Written by: KarenZ, Foresight News
If quantum computers become powerful enough one day, blockchain will likely face two fundamental security assumptions: whether signatures can still prove "I am me," and whether data encrypted today will be decrypted in the future.
Circle's latest paper, "Circle's Post-Quantum Security Roadmap," addresses this very issue. Its core assertion is straightforward: elliptic curve cryptography, widely relied upon by today's blockchains, including ECDSA, Ed25519, and BLS, will fail against sufficiently powerful quantum computers. More problematic is that on EVM chains, accounts typically expose their public keys when broadcasting transactions for the first time; on chains like Bitcoin, addresses that have already spent, reused, or exposed their public keys through specific scripts also enter a similar risk zone.
The author lineup also indicates that this is not an ordinary popular science article. Authors include Mira Belenkiy, Chief Software Engineer at Circle; Duc V. Le, Research Engineer at Circle; Gordon Liao, Chief Economist at Circle; Vipin Singh Sehrawat, Chief Security Engineer for Product Security at Circle; Dragos Rotaru, Research Engineer; and several Circle engineers, including Sergey Gorbunov, co-founder of Interop Labs (the original developer of the Axelar network) and now at Circle. Additionally, Dan Boneh, a leading scholar in applied cryptography at Stanford University, also co-authored the paper.
The most important aspect of this paper is not the fear-mongering narrative of "will quantum computing destroy cryptocurrencies?", but rather its breakdown of the problem into a real-world engineering migration issue. Circle argues that post-quantum migration is not an upgrade button, but a "long-term relocation" across wallets, smart contracts, custody, cloud services, validators, and regulatory rules.
The paper outlines several types of risks that blockchain faces in the face of quantum attacks.
The first type is account forgery. Once the address's public key is exposed, a quantum attacker could potentially recover the private key and directly forge transactions. The paper cites Project Eleven's Bitcoin RisQ Metrics, stating that millions of addresses with balances have already been exposed to quantum risks, including an estimated 14 million Bitcoin addresses.
The second type is the "collect first, decrypt later" risk: attackers store encrypted data today and decrypt it when quantum computing matures in the future.
The third category is consensus layer risks. If the validator's signing key is recovered, it could lead to double signatures, censorship, or even historical rewriting. The fourth category is network layer risks. Parts that rely on traditional key exchange, such as P2P communication and RPC over TLS, also need to be upgraded.
Circle's three-stage migration roadmap
Circle's roadmap is not simply about replacing one signature algorithm with another, but rather a three-step process: "Prepare Now, Hybrid Transition, and Final Switch." Each step has a different risk priority: privacy data must be protected first, accounts and smart contracts must be migrated gradually, and consensus and infrastructure will be switched over after the ecosystem, hardware, and standards have matured.
Attack types and response phases in the Arc roadmap, source: Circle post-quantum security roadmap paper.
The first phase is the "Preparation Phase." The goal of this phase is not to immediately disable ECDSA, but rather to provide developers and users with a migration path. Arc will support SLH-DSA-SHA2-128s post-quantum signature verification on the mainnet, allowing smart accounts to verify post-quantum signatures on-chain. In simpler terms, Arc is first installing an access control system on smart contracts that can recognize the new lock, but native transaction signatures will still retain ECDSA in the short term because post-quantum signatures are larger and slower to verify, impacting throughput and user experience.
At the same time, Arc will support encrypted transaction memos using X-Wing HPKE and protect transaction content, contract state, and execution traces through privacy execution. Circle puts this part first because the privacy risk of "recording today and decrypting in the future" is irreversible. Signatures can be upgraded in the future, but leaked data cannot be made private again.
At the account layer, Circle also proposes several transition tools. For example, through EIP-4337 account abstraction, smart accounts can verify post-quantum signatures; through a hash-and-rotate scheme, only the public key hash is stored on-chain, minimizing the window of exposure to the public key plaintext; and through a post-quantum public key registry, users can bind their addresses and post-quantum public keys in advance. The common goal of these designs is to allow users to prepare for account migration without waiting for the underlying protocol to be completely transformed.
The second phase is the "hybrid transition." This phase is the most realistic and also the most complex. USDC smart contracts will support both traditional signatures and post-quantum signatures for a period. Once the ecosystem is ready, classic signatures will be disabled through a reservation mechanism. Circle also plans to migrate cold storage funds to multi-signature smart contracts to ensure compatibility with the migration schedules of different chains and different post-quantum signature algorithms. Since USDC smart contracts are deployed on more than 30 chains, it faces not a single-chain upgrade problem, but rather the fragmentation problem caused by multiple chain ecosystems each choosing their own algorithms and setting their own timelines.
The paper specifically highlights the challenges posed by ecrecover. Many EVM contracts use ecrecover to verify ECDSA signatures, but many of these contracts are no longer upgradable. Simply disabling ecrecover would break many existing applications; continuing to run it introduces the risk of quantum forgery. Circle proposes a promising solution: modifying ecrecover's behavior at the protocol layer through a hard fork, allowing it to support post-quantum signatures while maintaining the old ABI. This solution has significant practical implications because it doesn't just serve new contracts, but attempts to provide a migration path for already deployed, difficult-to-modify legacy contracts.
The transition phase also includes updating the underlying infrastructure. Circle needs to take stock of its internal cryptography stack, assess whether its cloud service providers, HSM, KMS, TEE, libp2p, TLS, and other dependencies have post-quantum preparedness capabilities, and rotate keys in the correct order. The paper specifically warns that if key A protects key B, and key B protects key C, then A must be rotated first, then B, and finally C. Incorrect order, even with a post-quantum algorithm, could potentially expose previously intercepted encrypted material in the future.
The third phase is the "final switch." Circle will only execute the true hard switch once the ecosystem, regulations, hardware wallets, cloud service providers, and blockchain infrastructure are all ready. At that time, Arc and USDC smart contracts may refuse ECDSA signatures, and validator signatures will migrate to a post-quantum scheme. If some chains hosting USDC fail to meet sufficient post-quantum security requirements in the long term, Circle may even consider suspending some contract functions or withdrawing support to avoid exposing user assets to the risk of quantum forgery.
What to do with the old accounts is the most difficult problem.
However, the final switch also brings the most challenging issue: what happens to the assets in the unmigrated accounts? Circle's stance is that freezing insecure accounts is to prevent theft and should not automatically equate to asset confiscation. In other words, "stopping control of the old signature" and "denying the economic rights of the asset holder" must be handled separately. Therefore, the paper places great importance on account recovery, including migration to Arc, recovery via seed phrase and zero-knowledge proofs, recovery via TEE proofs, and, in limited cases, recovery via off-chain legal documents, custodian proofs, exchange proofs, or legacy documents.
This leads to a crucial policy issue discussed in the paper: account recovery. In the quantum era, traditional signatures alone can no longer prove ownership, and KYC may not be able to prove who owns an anonymous address. Circle argues that regulators need to clarify in advance: how users should be notified before the migration deadline, what evidence is sufficient to prove asset ownership, how long an asset freeze lasts before it is considered unclaimed, and how rules regarding inheritance, sanctions, anti-money laundering, and court orders should apply. The paper estimates that the industry may have a 5 to 10-year window to develop these rules.
This paper also offers a sober assessment: overly rapid migration could potentially lead to greater risks. For example, if companies currently use HSMs to protect their private keys, and hastily export these keys to ordinary CPUs for signing in order to catch up with post-quantum signatures, they may actually be more vulnerable to being stolen by traditional hackers. Circle's stance is that post-quantum migrations should be prepared for early, but current security should not be compromised for the sake of "appearing secure."
In layman's terms, Circle isn't saying "quantum computers will break the blockchain tomorrow," but rather that financial infrastructure can't wait until the locks are proven to be faulty before it starts changing them. Especially for stablecoins like USDC that operate across more than 30 chains, the real challenge isn't just choosing a new algorithm, but getting wallets, contracts, custodians, validators, cloud service providers, regulators, and users to migrate together.
Quantum attacks have not yet been truly implemented, but the costs of migration are already looming.
