Layer 2 Quantum Security: Arbitrum, Optimism, and zkSync Analyzed

TL;DR: Every major Ethereum L2 — Arbitrum, Optimism, zkSync Era, Starknet, Base, Linea — inherits Ethereum's secp256k1 quantum vulnerability for user wallets. A quantum computer running Shor's algorithm can derive private keys from on-chain public keys, giving an attacker full control of any address. zkSync Era adds a second quantum exposure layer: its PLONK validity proofs rely on elliptic curve pairings breakable by the same algorithm. Starknet's proof system is hash-based and quantum-resistant, but its wallet layer remains vulnerable. No major L2 offers end-to-end quantum resistance as of 2026.

The Inherited Vulnerability: secp256k1 on Every L2

Ethereum's base signature scheme is ECDSA over secp256k1 — the same curve used by Bitcoin. When users transact on Arbitrum, Optimism, zkSync, Base, or any other EVM-compatible L2, they sign transactions with their Ethereum private key using secp256k1. The L2 sequencer, the bridge contracts, and the L1 settlement layer all validate these signatures.

Shor's algorithm efficiently solves the elliptic curve discrete logarithm problem (ECDLP) — the mathematical problem that secp256k1 security relies on. Given a public key (which is always visible on-chain after the first transaction from an address), a quantum computer running Shor's algorithm can derive the corresponding private key in polynomial time. The practical implication: any address that has ever sent a transaction — and therefore published its public key on-chain — is a quantum target.

This vulnerability is not specific to any L2. It is an Ethereum base-layer issue that every L2 inherits by design. When Ethereum migrates to post-quantum signatures (if and when it does), L2s using the EVM would need to follow. But Ethereum has no committed post-quantum signature migration timeline as of 2026, and L2s are entirely dependent on Ethereum governance for this change.

Optimism (OP Mainnet and OP Stack)

Optimism is an optimistic rollup: it assumes transactions are valid by default and relies on a 7-day fraud proof window for challengers to dispute invalid state transitions. The core security mechanism is classical Merkle tree proofs posted to Ethereum L1 — no ZK circuit is involved in the standard execution path.

The quantum attack surface for Optimism includes:

User wallets: secp256k1 ECDSA, identical to Ethereum mainnet. Full quantum exposure.

Sequencer signing: The Optimism sequencer signs transaction batches posted to L1 using secp256k1. A quantum attacker who compromises the sequencer key (by recovering it from the published public key) can submit fraudulent batches. The 7-day fraud window theoretically allows challengers to dispute, but if the fraud proof system itself uses classical crypto for its Merkle proof validation on L1, a quantum attacker may also be able to forge the fraud proof responses.

Bridge contracts: The L1-to-L2 and L2-to-L1 message passing uses Merkle proofs and L1 Ethereum signatures. These are classically secure but quantum-vulnerable through the signature layer.

The OP Stack (the underlying framework used by Base, Mode, Zora, and other OP-chain deployments) inherits identical quantum security properties. Base — Coinbase's L2 — is therefore equivalently vulnerable.

Arbitrum One and Arbitrum Nova

Arbitrum uses an optimistic rollup architecture similar to Optimism, with its own dispute resolution mechanism. Arbitrum One uses the Nitro architecture (introduced 2022), and its fraud proof system is called BOLD (Bounded Liquidity Delay). BOLD improved the fraud proof mechanism to be permissionless and defend against delay attacks.

Arbitrum's quantum attack surface:

User wallets: secp256k1 ECDSA. Fully quantum-vulnerable, identical to Ethereum.

Sequencer and validator keys: Arbitrum validators post assertions signed with Ethereum keys (secp256k1). A quantum adversary who can derive validator private keys from published public keys can post fraudulent assertions. The 7-day challenge window provides a theoretical window for honest validators to challenge, but all challenge messages are themselves signed with secp256k1 — also quantum-vulnerable.

BOLD challenge protocol: BOLD uses bisection games and classical Merkle proofs. The game theory that makes BOLD secure assumes economically rational actors with valid signing keys. A quantum attacker who compromises multiple validator keys simultaneously could manipulate the dispute game — an attack that becomes increasingly plausible as quantum hardware scales.

Arbitrum Nova uses a different data availability layer (the Arbitrum AnyTrust committee) with weaker security assumptions. Nova is designed for high-throughput gaming and social applications where the security trade-off is acceptable. Its quantum security profile is identical to Arbitrum One at the wallet and signature layer.

zkSync Era

zkSync Era uses validity proofs — ZK proofs that mathematically guarantee the correctness of each batch before it is accepted on L1. Unlike optimistic rollups, there is no fraud window; the proof either verifies or it does not. This makes validity proof systems more secure than optimistic rollups against classical attacks — but it introduces a second quantum attack surface that optimistic rollups lack.

zkSync Era uses the Boojum prover, which is built on PLONK over FRI — a hybrid construction. The FRI (Fast Reed-Solomon IOP of Proximity) component uses hash functions for its proximity testing, which is quantum-resistant. However, the polynomial commitment scheme in Boojum uses KZG commitments over BLS12-381 — elliptic curve pairings that Shor's algorithm breaks efficiently.

The Boojum system therefore has two distinct quantum vulnerabilities:

Wallet layer: secp256k1 ECDSA (inherited from Ethereum). A quantum attacker can steal funds by recovering private keys.

Proof system layer: BLS12-381 KZG commitments. A quantum attacker who can break discrete logs on BLS12-381 can forge validity proofs that appear correct to the L1 verifier contract. This would allow draining the zkSync bridge without any fraud proof mechanism catching it — there is no 7-day dispute window in a validity proof system. The quantum attack on the proof system is categorically more dangerous than the classical case because forged proofs are irreversible.

zkSync's native account abstraction provides a theoretical path for individual users to use post-quantum signature schemes for their wallets. However, the proof system quantum vulnerability requires a complete prover redesign — something that cannot be patched at the account abstraction layer.

Starknet

Starknet uses STARKs (Scalable Transparent Arguments of Knowledge) based on FRI — a proof system whose security reduces to hash collision resistance rather than elliptic curve discrete logarithms. This makes Starknet's proof layer the most quantum-resistant of any major production L2.

However, Starknet's wallet layer remains vulnerable:

Stark curve wallets: Starknet's default account abstraction uses ECDSA over the Stark curve (a custom curve designed for efficient ZK circuit representation). The Stark curve is an elliptic curve — Shor's algorithm applies. A quantum attacker can recover Stark curve private keys from published public keys.

secp256k1 wallets: Many Starknet wallets support Ethereum-style secp256k1 signatures for compatibility. These have identical quantum vulnerability to Ethereum mainnet.

Starknet's architecture (Cairo VM, account abstraction at the protocol level) makes it technically feasible to deploy post-quantum signature schemes as account contract logic. The Starknet Foundation has acknowledged this possibility, but no standard post-quantum account contract exists in production as of 2026.

Linea and Polygon zkEVM

Linea (Consensys) uses PLONK with KZG commitments — the same elliptic curve pairing construction as zkSync Era. Quantum vulnerable at both the wallet layer (secp256k1) and the proof system layer (BN254 pairings).

Polygon zkEVM uses a PLONK-based proof system with KZG commitments over BN254. Polygon has announced a research roadmap toward post-quantum ZK proofs (aggregating STARK proofs as the outer layer), but as of 2026 the production system uses quantum-vulnerable pairings throughout.

Comparison Table

L2 Network	Architecture	Proof Type	Proof Quantum Security	Wallet Quantum Security
Arbitrum One	Optimistic rollup	Fraud proofs (BOLD)	Vulnerable (secp256k1 signing)	Vulnerable (secp256k1)
Optimism / Base	Optimistic rollup	Fraud proofs	Vulnerable (secp256k1 signing)	Vulnerable (secp256k1)
zkSync Era	ZK rollup (validity proofs)	PLONK / KZG (BLS12-381)	Vulnerable (Shor breaks pairings)	Vulnerable (secp256k1)
Starknet	ZK rollup (validity proofs)	FRI-STARK (hash-based)	Resistant (~128-bit post-quantum)	Vulnerable (Stark curve ECDSA)
Polygon zkEVM	ZK rollup (validity proofs)	PLONK / KZG (BN254)	Vulnerable (Shor breaks pairings)	Vulnerable (secp256k1)
Linea	ZK rollup (validity proofs)	PLONK / KZG (BN254)	Vulnerable (Shor breaks pairings)	Vulnerable (secp256k1)

The ZK Validity Proof Quantum Risk Is Categorically Worse

A subtle but critical point deserves emphasis: the quantum vulnerability in zkSync Era's PLONK proof system is categorically more dangerous than the wallet-level vulnerability shared by all L2s.

If a quantum attacker compromises a user's secp256k1 wallet key, they steal that user's funds. The damage is bounded to that wallet's balance. Other users are unaffected unless their own keys are individually compromised.

If a quantum attacker forges a PLONK validity proof, they can submit a fraudulent state transition that appears valid to the L1 bridge contract. This can drain the entire L2 bridge — all user funds locked in the rollup contract — in a single transaction. The attack is not per-user; it is systemic. There is no fraud proof window to catch it, because validity proof systems accept the proof as final immediately upon verification.

This asymmetry means that from a quantum risk perspective, optimistic rollups (Arbitrum, Optimism) and ZK rollups using quantum-vulnerable proof systems (zkSync, Polygon zkEVM, Linea) are not equivalent. The optimistic rollups have a 7-day window during which observers could potentially detect and challenge fraudulent behavior — providing a partial mitigation even against quantum attacks on sequencer keys. ZK rollups with quantum-vulnerable proofs offer no such window.

The L2 Quantum Migration Timeline

Ethereum has no committed post-quantum migration timeline. The Ethereum roadmap (The Scourge, The Verge, The Purge, The Splurge) does not include a post-quantum signature migration as a near-term deliverable. Ethereum Foundation researchers have discussed EIP drafts for post-quantum account abstraction, but no EIP has been finalized.

L2s are entirely dependent on Ethereum for wallet-level quantum security. An L2 cannot unilaterally migrate user wallet signatures without Ethereum also accepting those signatures at the L1 settlement layer. This creates a coordination problem: even if zkSync or Starknet wanted to adopt ML-DSA-87 signatures tomorrow, Ethereum's L1 contracts would not recognize them.

For the proof system layer, ZK rollups theoretically have more independence: they could migrate from PLONK to STARK proofs without Ethereum's coordination, as long as the L1 verifier contract is upgraded. zkSync could theoretically replace Boojum with a STARK prover. The engineering cost is significant — it is effectively a complete redesign of the proving system — but it does not require Ethereum protocol changes. As of 2026, no major SNARK-based ZK rollup has announced a concrete plan to migrate its proof system to a quantum-safe construction.

What Does "Harvest Now, Decrypt Later" Mean for L2 Users?

The "harvest now, decrypt later" (HNDL) threat model describes adversaries who record encrypted communications or blockchain data today, intending to decrypt or exploit it once quantum hardware matures. For L2 users, this threat manifests in two ways:

Address re-use: Any Ethereum address that has sent transactions has published its public key on-chain. These public keys are stored permanently in Ethereum's history — and therefore in every L2 that inherits Ethereum state. A future quantum adversary can target these historical public keys and derive private keys to steal current balances, if users have not migrated their funds to fresh quantum-safe addresses.

Proof archive attacks: For ZK rollups using PLONK/KZG, the proving keys and verification keys are published on-chain. A future quantum adversary can run Shor's algorithm on the KZG commitments to recover trapdoor values. With the trapdoor, they can forge arbitrary proofs retroactively — but more practically, they can forge proofs for new fraudulent transactions at the time they launch the attack.

See our guide on the harvest now, decrypt later threat for a deeper analysis of this attack vector.

Account Abstraction as a Partial Path Forward

Ethereum's ERC-4337 account abstraction standard allows smart contract wallets to use custom signature verification logic. In principle, a user could deploy a wallet contract that validates ML-DSA-87 or SLH-DSA signatures instead of secp256k1 ECDSA. Several research projects (including ERC-7212 for P256/secp256r1, which is easier to verify than NIST post-quantum schemes) have explored this direction.

The practical limitations:

First, ERC-4337 does not change the L1 protocol — it works through a mempool layer that validators are not required to support. Post-quantum signature verification requires approximately 3–10x more gas than secp256k1 verification, making post-quantum wallets significantly more expensive per transaction.

Second, ERC-4337 wallets cannot receive ETH at an address before deployment (the address is derived from the factory and initcode hash). This changes the user experience significantly compared to standard EOA addresses.

Third, ERC-4337 does not protect the sequencer, validator, or bridge contract keys — only individual user wallets that opt in. The systemic quantum risks (sequencer compromise, proof forgery) require protocol-level changes, not account abstraction workarounds.

Starknet's native account abstraction (where every account is a smart contract by default) is more naturally positioned to adopt post-quantum signatures, since there are no EOAs at the protocol level. However, even on Starknet, the ecosystem has not standardized a post-quantum account contract.

QuanChain's Architecture in Contrast

QuanChain was designed from genesis with quantum resistance as a core requirement, not a future migration. All on-chain transactions use ML-DSA-87 + SLH-DSA composite signatures — both NIST-standardized post-quantum algorithms. The signature scheme selection eliminates the wallet-layer quantum vulnerability that all Ethereum L2s currently carry.

For applications requiring ZK proofs on QuanChain, the protocol requires hash-based proof systems (STARK/FRI constructions) rather than pairing-based SNARKs. This eliminates the proof system quantum vulnerability that zkSync Era, Polygon zkEVM, and Linea currently have.

This means QuanChain does not need a "migration timeline" for quantum resistance — the migration happened at genesis. Users on Ethereum L2s are exposed to quantum risk for the duration of the period between now and whenever Ethereum (and its L2 ecosystem) completes a post-quantum upgrade, which has no committed schedule.

For a comprehensive evaluation framework for comparing blockchain quantum security, see our guide on evaluating quantum-resistant blockchains. For the underlying cryptographic primitives, see our post-quantum cryptography explainer.

Conclusion

The quantum security analysis of major Ethereum L2s reveals a layered vulnerability problem. Every L2 inherits Ethereum's secp256k1 wallet-level vulnerability — this is non-negotiable until Ethereum migrates. ZK rollups using pairing-based proof systems (zkSync Era, Polygon zkEVM, Linea) add an additional, potentially more dangerous proof-system-level vulnerability that can enable systemic fund drainage rather than per-user theft. Starknet's proof system is the notable exception — FRI-based STARKs are quantum-resistant — but its wallet layer remains as vulnerable as any other L2.

The L2 quantum timeline is entirely dependent on Ethereum's governance and migration decisions. Given the complexity of a base-layer signature scheme migration and the lack of a committed timeline, L2 users face an indefinite exposure window. For applications where long-term cryptographic security is a requirement — financial infrastructure, identity systems, long-duration contracts — this exposure is a material risk that deserves explicit evaluation.