Canonical: https://builtonarc.app/guides/arc-post-quantum-explained # Arc's post-quantum security roadmap, explained from Circle's own whitepaper Updated 2026-09-02. Circle's Arc post-quantum whitepaper names real cryptographic schemes and three migration phases. Here's what it actually says, dated 2 Sep 2026. > Circle's Arc post-quantum security whitepaper, published at `arc.io/post-quantum-whitepaper`, describes a three-phase migration — Readiness, Transition, Switch — with specific named cryptographic schemes at each stage: SLH-DSA-SHA2-128s is already deployed on Arc mainnet as a smart-account signature option, and X-Wing (a hybrid of X25519 and ML-KEM-768) secures private transaction encryption today. No Arc-specific calendar date is given for completing the Transition or Switch phases; the only dated figures in the document are external regulatory deadlines (the EU's 2030, the US and Canada's 2035) that Circle cites as context, not as its own commitments. ## The three phases, as Circle names them The whitepaper structures Arc's quantum migration as **Readiness** (assess vulnerabilities, deploy initial protections — the phase Circle describes as current), **Transition** (run classical and post-quantum cryptography side by side in hybrid mode), and **Switch** (a hard cutover to post-quantum-only systems). This is a process-based framing, distinct from the component-based phase table on Arc's own developer documentation (wallet signatures, then privacy, then offchain infrastructure, then validator signatures) — both documents are genuinely Circle's, and Built on Arc did not find a single unified timeline reconciling the two. Treat them as two lenses on the same underlying work rather than conflicting roadmaps. ## What's specifically named, and what's live today The whitepaper commits to real algorithm choices rather than staying abstract. For signatures, it names **SLH-DSA-SHA2-128s** — a hash-based scheme chosen for conservative security resting only on SHA-2 — as deployed on Arc mainnet today as a precompiled verifier available to smart accounts, ahead of any protocol-level requirement. It separately discusses **ML-DSA-44** (lattice-based, larger signatures) and **Falcon/FN-DSA** (shorter signatures, still pending formal standardization) as candidates for a later, native transaction-signature scheme — no final choice between them is stated. For encryption, it names **X-Wing**, a hybrid combining classical X25519 with post-quantum ML-KEM-768, used today for encrypted transaction memos and for securing Arc's trusted-execution-environment communications (TLS 1.3 with the X25519MLKEM768 hybrid, AES-256-GCM-SIV for persistent state inside AWS Nitro Enclaves). For zero-knowledge proofs, it names hash-based **zkSTARK** constructions (FRI, STIR, WHIR) as inherently quantum-resistant, at the cost of larger proof sizes than current pairing-based alternatives. ## Validators, infrastructure, and account recovery Consensus signatures are flagged for eventual post-quantum upgrade, but the document states the specific algorithm is pending a workable post-quantum alternative to the BLS aggregate signatures Arc-family consensus systems typically rely on — no scheme is named for that piece yet. On infrastructure, the whitepaper calls out AWS Nitro's post-quantum support as partial today: TLS communication is already secured with post-quantum-hybrid cryptography, while enclave attestation and certificate issuance are described as pending upgrade from AWS's side, outside Circle's direct control. Account recovery gets unusually detailed treatment for a technical whitepaper: it discusses zero-knowledge-circuit-based seed-phrase recovery, TEE-attested recovery flows, and explicitly frames the harder question as a policy one — distinguishing "disabling unsafe cryptography" from "extinguishing someone's economic interest," and drawing analogies to escheat and bailment law rather than proposing Circle unilaterally resolve it. ## Dates: what's stated and what isn't The whitepaper does not give a target date for Arc's own Transition or Switch phases, and it does not give a completion date for validator or infrastructure migration. The dated figures that do appear are regulatory reference points from outside Arc entirely — the EU's 2030 and the US/Canada's 2035 post-quantum migration deadlines — cited as context for why the industry is moving, not as Circle's internal deadline. The document is explicit that rushing is itself treated as a risk: it warns that "rushing the transition will result in a design flaw that will expose the system to a conventional attack or permanently locked assets," calling that "a bigger danger than the risk of an attack by a quantum computer whose time horizon is unknown." Circle's broader public materials describe post-quantum cryptography as "an evolving area of research" and state that "no post-quantum design can eliminate all future security risk" — language consistent with the whitepaper's own caution about locking in a scheme before NIST's standardization work settles. Sources: - [Arc post-quantum security whitepaper (PDF)](https://6778953.fs1.hubspotusercontent-na1.net/hubfs/6778953/PDFs/quantum_paper.pdf) - [Arc post-quantum whitepaper landing page](https://www.arc.io/post-quantum-whitepaper) - [Arc documentation: post-quantum security](https://docs.arc.io/arc/concepts/post-quantum-security.md) *Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle.* ## Questions **Is Arc quantum-secure today?** Partially, by design choice rather than completion: one signature scheme (SLH-DSA-SHA2-128s) and Arc's private-transaction encryption already use post-quantum-hybrid cryptography; core transaction signing and validator consensus still rely on classical ECDSA/BLS as of 2 Sep 2026. **When does Arc's post-quantum migration finish?** Not stated. The whitepaper gives no target date for its Transition or Switch phases. **Does Arc have a final choice between ML-DSA and Falcon for native signatures?** No — the whitepaper discusses trade-offs between both, plus hardware-wallet readiness, without naming a final pick. **Is this the same document as Arc's privacy whitepaper?** No, though they overlap technically — Arc's privacy design already uses the same X-Wing hybrid encryption this roadmap names as its post-quantum encryption standard. **Should an institution treat this as a compliance guarantee?** No. This is Circle's own engineering roadmap, not a certification or regulatory attestation, and the document itself cautions against treating any current post-quantum design as risk-free.