Is SOON Quantum Safe?

Is SOON quantum safe? That question matters more than most SOON holders realise. SOON is a high-throughput Solana Virtual Machine (SVM) Layer-2 network that inherits the cryptographic assumptions baked into its parent ecosystem. As quantum computing hardware edges closer to practical threat thresholds, any asset secured by classical elliptic-curve schemes faces a non-trivial future risk. This article examines exactly which cryptographic primitives SOON relies on, how those primitives break under a sufficiently powerful quantum computer, what migration paths exist, and what genuinely quantum-resistant alternatives look like in practice.

What Is SOON and How Does It Handle Cryptography?

SOON (Simple Optimistic Optimized Network) is an SVM-compatible optimistic rollup Layer-2 network. Its architecture is designed to bring Solana's parallel execution model to a broader set of settlement layers, including Ethereum. Transactions executed on SOON are batched, compressed, and settled to a base layer, with fraud proofs available during a challenge window.

From a cryptographic standpoint, SOON inherits the signature scheme of the underlying execution environment. In the Solana Virtual Machine context, that means Ed25519, a variant of EdDSA (Edwards-curve Digital Signature Algorithm) built over Curve25519. Ed25519 is the same scheme Solana itself uses to authorise all on-chain transactions.

Ed25519 vs ECDSA: Are They Different Security Families?

It is worth drawing a clear distinction between ECDSA and EdDSA before assessing quantum risk:

• ECDSA (Elliptic Curve Digital Signature Algorithm): used by Bitcoin (secp256k1) and pre-Merge Ethereum. Security rests on the hardness of the elliptic-curve discrete logarithm problem (ECDLP).
• EdDSA / Ed25519: used by Solana and SOON. Security also rests on ECDLP, applied to a twisted Edwards curve.

Both are elliptic-curve schemes. Both are broken by Shor's algorithm running on a sufficiently large, fault-tolerant quantum computer. The distinction between ECDSA and EdDSA is primarily about implementation correctness and signing speed, not quantum resistance. Neither provides any meaningful protection against a cryptographically-relevant quantum computer (CRQC).

---

The Quantum Threat Explained: Shor's Algorithm and Q-Day

Shor's algorithm, published in 1994, demonstrates that a quantum computer can solve integer factorisation and discrete logarithm problems in polynomial time. For classical computers, those problems take exponential time, which is the entire basis of RSA and elliptic-curve security.

The critical parameters:

Q-day is the informal term for the moment a CRQC becomes capable of breaking a 256-bit elliptic-curve key within a practically relevant timeframe, often estimated at hours to days. Current estimates from bodies including NIST and NCSC place that risk window somewhere between the early 2030s and the mid-2040s, though rapid hardware progress makes the lower end of that range increasingly plausible.

What Happens to SOON Addresses at Q-Day?

Every SOON (and Solana) wallet address is derived from an Ed25519 public key. The public key is visible on-chain the moment any transaction is broadcast. Once a CRQC can invert the discrete logarithm for that public key, it can reconstruct the private key and sign arbitrary transactions, draining the wallet without any need for the original seed phrase.

There is a specific window of maximum danger: the period between when a transaction is broadcast and when it is confirmed. During that window, the public key is exposed. A quantum attacker with a fast-enough machine could, in theory, extract the private key and front-run the original transaction. At sufficient quantum speed, even previously confirmed transactions could be attacked if the public key has ever appeared on-chain in cleartext.

For SOON specifically, this exposure is compounded by the optimistic rollup design. Transactions are published to the settlement layer before they are finalised, extending the window during which a raw Ed25519 public key is observable in plaintext.

---

Does SOON Have a Post-Quantum Migration Plan?

As of the most recent publicly available roadmap and documentation for SOON, no explicit post-quantum migration plan has been announced. This is not unique to SOON. The vast majority of Layer-2 projects, including Arbitrum, Optimism, and zkSync, have not published PQC transition roadmaps either.

The likely reasons:

1. Timeline perception: Most teams consider Q-day a distant threat and prioritise near-term scaling and adoption.
2. Ecosystem lock-in: SOON's Ed25519 dependency is inherited from Solana's core protocol. Changing it requires upstream action at the Solana Foundation level, not just the SOON team.
3. Lack of settled standards: NIST finalised its first post-quantum cryptographic standards in 2024 (CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium / FALCON / SPHINCS+ for signatures). Until those were stable, projects had reasonable grounds to wait.

What Would a Migration Actually Require?

Migrating SOON to a quantum-safe signature scheme is not a trivial upgrade. The steps would likely include:

1. Protocol-level signature replacement: Swapping Ed25519 for a NIST PQC-approved signature algorithm (ML-DSA, formerly Dilithium, is the primary candidate for blockchains).
2. Address format changes: Post-quantum public keys are significantly larger. ML-DSA public keys are approximately 1,312 bytes versus 32 bytes for Ed25519. This affects storage costs, transaction fees, and block space calculations.
3. Wallet software updates: Every wallet that supports SOON would need to generate and store PQC key pairs, a non-trivial engineering effort across the entire ecosystem.
4. Migration period: Users would need to move funds from old Ed25519 addresses to new PQC addresses. Any funds left in unmigrated wallets would remain vulnerable after Q-day.
5. Settlement layer co-ordination: Because SOON settles to an external base layer (Ethereum or Solana, depending on deployment), the quantum-resistance of the entire stack, not just SOON itself, must be considered.

---

Comparing Classical vs Post-Quantum Cryptographic Primitives

Understanding the technical tradeoffs helps assess how realistic a PQC migration is for any Layer-2 network.

The key observation: post-quantum signature schemes are quantum-safe, but they come with significant size overheads. FALCON offers the best signature-size profile for blockchain use, which is why it attracts the most interest from protocol designers working on PQC-ready chains. SPHINCS+ has the advantage of relying only on hash functions (a more conservative security assumption) but produces very large signatures.

---

How Lattice-Based Post-Quantum Wallets Differ From Standard Crypto Wallets

Lattice-based cryptography, the foundation of both ML-DSA and FALCON, derives its security from the hardness of problems like the Shortest Vector Problem (SVP) and the Learning With Errors (LWE) problem in high-dimensional mathematical lattices. These problems are believed to be hard for both classical and quantum computers, with no known polynomial-time quantum algorithm capable of solving them.

From a user perspective, a lattice-based wallet differs from a standard Ed25519 or ECDSA wallet in three practical ways:

• Key generation: Produces larger public and private key pairs. Storage requirements for key material increase by roughly one to two orders of magnitude.
• Transaction signing: Signing operations remain fast (milliseconds on modern hardware), but the resulting signature data is larger, increasing on-chain storage and fee costs.
• Seed phrase compatibility: The BIP-39 mnemonic standard was designed around 256-bit entropy for elliptic-curve keys. PQC schemes may require new derivation standards to correctly seed larger key pairs.

Projects that are building with PQC from the ground up, such as BMIC.ai, implement lattice-based schemes natively (aligned with NIST PQC standards) rather than bolting them on as an afterthought. That architectural choice matters because retrofitting quantum resistance into an existing protocol involves risks, such as hybrid-mode vulnerabilities during the migration window, that a native implementation avoids entirely.

---

What Should SOON Holders Do Now?

The honest answer is that Q-day is not tomorrow. However, the "harvest now, decrypt later" strategy, where adversaries collect encrypted data or on-chain public keys today with the intention of breaking them once a CRQC is available, is already a documented concern in government cybersecurity guidance. For long-term holders of SOON or any SVM-ecosystem asset, several practical steps are worth considering:

1. Minimise public key exposure: Avoid reusing addresses. On Solana-compatible chains, each transaction exposes the Ed25519 public key. Fewer transactions from a given address mean less accumulated exposure.
2. Monitor SOON and Solana Foundation announcements: Any PQC roadmap announcement from Solana would cascade to SOON. Follow their technical forums and GitHub repositories.
3. Diversify custody: Hold a portion of long-term holdings in wallets or protocols that are building PQC infrastructure now, not as a replacement for SOON exposure, but as a hedge against cryptographic tail risk.
4. Watch NIST guidance: NIST's ongoing PQC standardisation process provides the most authoritative signal for when migration timelines become urgent for the industry.
5. Assess settlement-layer risk independently: SOON's quantum risk is not just its own. The security of whatever base layer it settles to must also be evaluated under a quantum threat model.

---

The Broader Ecosystem Context: Where Does Layer-2 PQC Stand?

No major optimistic rollup or ZK rollup project has achieved full end-to-end post-quantum security as of mid-2025. ZK rollups that use zk-SNARKs face their own quantum problem: many SNARK constructions rely on elliptic-curve pairings, which are also vulnerable to Shor's algorithm. ZK-STARKs, which rely only on hash functions, are quantum-resistant at the proof level, but the wallet and account-layer key management on top of them typically still uses ECDSA or EdDSA.

This means the quantum vulnerability for Layer-2 users is almost universally located at the account key layer, regardless of whether the rollup uses optimistic or ZK proof systems. SOON is not uniquely exposed here; it is representative of the entire current Layer-2 landscape.

The differentiation will come from which projects act first and with architectural integrity rather than cosmetic changes.