Circle's latest ambition is to create the ultimate settlement layer for stablecoins. Its new network, Arc, touts the conveniences that financial and blockchain enterprises ask for, and if you move or manage money for a living, especially stablecoins, its pitch is quite compelling.
But there's a catch here that sits under the surface. Due to its technical implementation, Circle's new stablecoin faces a quantum computing threat that developers and investors should price in before the mainnet launches -- assuming that Circle doesn't make any adaptations before then.
Here's what you need to know.
Arc's Debut, And What It Gets Right
Arc is framed as an EVM-compatible Layer-1 purpose-built for stablecoin finance. It proposes USDC as native gas, which reduces the operational friction of paying fees in a volatile asset. It advertises built-in FX and on-chain banking rails, plus opt-in privacy that selectively shields balances with compliance-friendly proofs. Finality is described as deterministic and sub-second, powered by Malachite, a Rust BFT engine.
The public timeline to launch is average, with a mainnet beta in 2026, which gives the team time to harden the stack if they choose to do so. The incumbents in the stablecoin space are likely to pay attention to how that launch goes. The asset tokenization movement can and will transform key financial market rails, and companies will require predictable fees, high throughput, and clear compliance paths. If Arc can deliver those operational guarantees, cross-border payments and asset tokenization flows will test it.
Circle's New Stablecoin: Quantum Threat Is The Blind Spot Investors Need To Price In
As good as Arc's feature set looks to be, it's missing something critical.
The cryptography choice at the heart of EVM ecosystems like Arc remains elliptic-curve cryptography (ECC) signatures. A cryptographically-relevant quantum computer would put those signatures at risk, and the public Arc materials do not commit to implementing post-quantum computing (PQC) protections. In fact, they don't even mention them at all.
That's a bit frightening, as the threat model is as straightforward as it is well-known at this point. Most EVM chains sign transactions with ECDSA over secp256k1. Ethereum's own developer docs explain how ECDSA signatures authenticate transactions, and ENISA's post-quantum brief reminds us that Shor's algorithm breaks ECC, which means an adversary with a sufficiently capable quantum computer can derive private keys from public keys.
The same class of risk exists in other ecosystems that use ECDSA over secp256k1 or use Ed25519, because both are elliptic-curve systems. For instance, Tron's docs state that its signature algorithm is ECDSA over secp256k1, while the XRP Ledger supports secp256k1 and Ed25519 key types. This is why security agencies are already pressing for migration to post-quantum secure system configurations today, rather than when it's too late. CISA, NSA, and NIST all advise that organizations should plan for “harvest now, crack later”, where adversaries collect data today to decrypt once quantum capabilities arrive.
Circle’s silence on a quantum threat matters because NIST has now finalized initial PQC standards, including FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA, and has already profiled stateful hash-based signatures like XMSS in SP 800-208. If Arc is meant to be trusted infrastructure for moving large volumes of money, its PQC migration path should be first-class, and loudly advertised.
Ethereum researchers are at least discussing viable pathways. One proposal outlines a backward-compatible post-quantum migration via new transaction types or account-abstraction schemes. Work across the ecosystem explores hybrid signature models where transactions are signed by both a classical and a PQ algorithm during transition. Arc can attempt similar approaches, but it has not publicly said that it will.
Not all chains have made the same oversight; consider the Quantum Resistant Ledger (QRL). QRL has long implemented XMSS-secured accounts, and XMSS is explicitly included in NIST SP 800-208. No one is arguing that Arc must adopt XMSS in particular, the point is that a credible PQC story is a must in 2025, and the actual implementation of it can be engineered without torching developer or user experiences.
Comparative Posture And Signature Choices
Arc isn't alone in attempting to process stablecoin transactions at scale without building out the full set of security features needed for the future:
Network | Default signature primitives | Public PQC posture today |
|---|---|---|
Arc | EVM-compatible stack implying secp256k1 ECDSA for accounts | No PQC commitment in launch blog |
Ethereum | ECDSA secp256k1 for transactions | Researching PQ migration paths |
Tron | ECDSA over secp256k1 | No published PQC plan in docs |
XRP Ledger | secp256k1 or Ed25519 | Community discussion on Dilithium support |
QRL | XMSS hash-based signatures | Built to be post-quantum by design |
In more concrete terms, companies and investors will look for a credible plan to evolve signatures and keys, and eventually, signs of progress. It's also worth noting that national security programs intend to phase out all equipment and services that cannot support CNSA 2.0 prior to 2030, which is directly relevant to capital-markets-grade infrastructure. And yes, government-issued materials do tend to be part of the information set that investors with a lot of capital use to decide where to park their money.
How To Fix The Gap
Circle markets Arc as reliable, compliant rails. That goal is incompatible with avoiding a PQC commitment until after mainnet launches. The risk is that adversaries are already harvesting now to decrypt later. If important account data, proofs, or attestations are captured in 2026, they can be weaponized when quantum capabilities mature.
Here is a crisp set of asks that would put the issue to bed sooner rather than later:
Publish a key-management and signature roadmap that targets support for FIPS 204 ML-DSA or FIPS 205 SLH-DSA for user accounts and validators.
Adopt a staged hybrid model where transactions can be dual-signed by a classical and a PQ scheme during migration, following documented hybrid patterns.
Describe how opt-in privacy will accommodate PQ proofs, since Arc already references selectively shielded balances.
Coordinate with ecosystem standards so that developer ergonomics match what Ethereum researchers are exploring, for example backward-compatible PQ transaction types.
None of this is speculative science so much as it's an emerging set of best practices which have not yet been widely distributed. The NIST standards exist, and there are live networks like QRL that run XMSS. Ethereum research groups are socializing how to get from here to there, and industry guidance from CISA, NSA, and NIST has been explicit about timelines and urgency, including the 2030 objective.
What Investors And Developers Should Do Next
If you are a developer building on Arc, ask for a dated PQC roadmap and a testnet plan that exercises signatures at production-grade load. If you are an investor weighing Arc's go-to-market, discount “trusted infrastructure” claims until a PQC path is documented and staffed. Addressing Circle's new stablecoin quantum threat is the single most tractable design choice Arc can use to differentiate itself before the 2026 mainnet beta.
If Arc is truly about trust and reliability, then proving that begins with cryptography. There is still time to get this right.
To keep up with the latest in blockchain technology and quantum computing, join us on X and subscribe to our newsletter.
