Circle's Post-Quantum Security Roadmap

In three numbers

The gap, the cost, the plan

The problem

Every account that has signed has published its public key

Blockchains authorize transactions with elliptic-curve signatures. On a cryptographically relevant quantum computer (CRQC), Shor's algorithm recovers a private key from its public key, and an EVM account reveals its public key the first time it sends a transaction. The paper calls this a potential cliff event rather than a gradual erosion: millions of funded addresses are exposed, including an estimated 14 million Bitcoin addresses.

Circle meets the problem three times over: as the developer of the Arc blockchain, as the operator of USDC contracts on more than 30 blockchains that will each migrate on their own timeline, and as a service provider that depends on cloud and hardware vendors.

“You can always upgrade your signatures but you can never get your privacy back due to harvest-now-decrypt-later.” — §1, Algorithm Choices

The roadmap

Three phases: Now, Transition, Switch

The phases follow urgency. Privacy protections ship first, signature and consensus changes follow as post-quantum infrastructure matures, and a hard cutoff comes only once recovery paths exist. The paper gives no calendar dates for Circle's phases; the binding external deadlines it cites fall in 2030 and 2035 (Table 3). Tags name the attacks each item counters in Table 4; click one to open it below.

Interactive · Figure 1 + Table 4

Seven attacks on one transaction

Figure 1 follows a transaction from wallet to validators and pins seven quantum attacks to the stage they target. Pick a phase to see which attacks have at least one countermeasure listed in Table 4 by the end of it. Click an attack for its description, timing, and countermeasures.

Interactive · §2.5, §3.1, §4.3

Why Arc's transaction signatures stay ECDSA for now

Arc will deploy an SLH-DSA verifier that smart contracts can call, but native transaction signatures remain ECDSA for the near future. The paper gives three reasons: post-quantum signature length and verification time would cut throughput, Falcon's standardization as FN-DSA (shorter and faster) is pending, and hardware wallets need to support whatever is picked. The sizes below are the ones the paper quotes.

Not a signature. Encrypting an Arc memo with HPKE over X-Wing adds 1,136 bytes to the payload (§3.2). Arc memos are capped only by the block gas limit; the paper notes other chains will need larger memos to carry post-quantum public-key encryption.

Interactive · §2.3 (A7), §3.4.2, §4.4

Shrinking the window in which a public key is visible

A plain account exposes its public key from its first transaction onward, so any CRQC can attack it at rest. Hash-and-rotate stores only a hash of the next key and uses each key once, so the key is exposed only between broadcast and inclusion. What that buys depends on the machine: a fast-clock CRQC could finish an attack in seconds to minutes, while a slow-clock one is limited to long-window, at-rest attacks (§2.3).

Schematic: the time axis has no units because the paper gives none beyond “seconds–minutes” for fast-clock on-spend attacks. The outcome column quotes the paper; it is not computed from the drawing.

Switch · §5.1–5.3

A freeze is not a forfeit

At the Switch, Arc and USDC contracts reject ECDSA-signed transactions and funds in unmigrated accounts are frozen. The paper treats this as a protective control against quantum-enabled theft, not a finding that the holder has abandoned the asset. Where it is technically feasible and legally supportable, frozen assets should stay recoverable if entitlement can be shown with reliable evidence.

Properties

What breaks, and what Arc uses instead

Provenance

Where the paper's own sources differ

This page reproduces each source as written rather than reconciling them.

1. A4 has three names. “History Rewrite” in the §2.3 text, “Long-range” in Figure 1 and Table 4, and “Long-range / posterior” in Table 2.
2. A1 timing. Figure 1 annotates at-rest forgery with “hours–days”; Table 2 lists its time constraint as “Offline”.
3. A2 placement. Figure 1 draws retroactive privacy loss at the validator (consensus) stage; §2.3 and Table 2 list it under the Application layer.
4. A4 Transition countermeasure. Table 4 says “PoW / social checkpointing (§4.7)”; the text of §4.7 describes a “post-quantum secured checkpoint of block state” and does not mention PoW or social checkpointing.
5. A6 Transition countermeasure. Table 4 cites “TLS PQ upgrade (§4.6)”; §4.6 covers libp2p and does not discuss TLS.

Cite

BibTeX

@misc{belenkiy2026circle,
  title        = {Circle's Post-Quantum Security Roadmap: Securing Blockchains,
                  Smart Contracts, and Digital Assets for the Quantum Era},
  author       = {Belenkiy, Mira and Le, Duc V. and Liao, Gordon and
                  Sehrawat, Vipin Singh and Rotaru, Dragos and Gorbunov, Sergey and
                  Sheth, Milap and Logelin, Jay and De Abreu, Anthony and Boneh, Dan},
  howpublished = {Circle Whitepaper},
  year         = {2026},
  url          = {https://levduc.github.io/papers/pq-roadmap.pdf}
}

Code. No code or data accompanies this whitepaper; it describes a roadmap rather than an implementation. Items such as Arc's SLH-DSA precompile and privacy layer are described in the paper, not released with it.