Is ZKsync Quantum Safe?

Is ZKsync quantum safe? It is a question every serious holder of ZK tokens or assets on the ZKsync Era network should be asking right now. ZKsync is one of Ethereum's most prominent Layer 2 rollups, praised for its zero-knowledge proof architecture. Yet the "ZK" in its name refers to zero-knowledge proofs for scalability and privacy, not post-quantum cryptography. Underneath the rollup machinery, ZKsync still relies on the same elliptic-curve signature schemes that protect every standard Ethereum wallet. This article dissects exactly where the quantum exposure lies, what a realistic threat timeline looks like, and what the migration path could involve.

What Cryptography Does ZKsync Actually Use?

To answer whether ZKsync is quantum safe, you first need to separate two distinct cryptographic layers that the protocol relies on.

The Zero-Knowledge Proof Layer

ZKsync Era uses zk-SNARKs (specifically a PLONK-based proving system) to batch and compress transaction data. These proofs allow anyone to verify that thousands of off-chain transactions were executed correctly without re-executing every step. The mathematical hardness assumptions underlying these proof systems include certain pairings over elliptic curves (BN254 in particular) and polynomial commitments.

Pairing-based SNARKs are not classically broken, but they are not quantum safe. A sufficiently powerful quantum computer running Shor's algorithm can solve the discrete logarithm problem over elliptic curves, which would undermine the security of BN254 pairings. The timeline for breaking pairing-friendly curves with a quantum computer is debated, but the structural vulnerability is acknowledged by cryptographers.

The Account and Signature Layer

This is where the exposure is most immediate and most familiar. Every ZKsync Era account is an Ethereum address. To authorise a transaction, users sign with their ECDSA private key (specifically secp256k1, the same curve Bitcoin and Ethereum mainnet use). ZKsync processes that signature and includes it in the proof batch.

ZKsync also supports EIP-712 structured signing and, via its native account abstraction, can accept other signature schemes including EdDSA (Ed25519). Account abstraction is relevant here because it means ZKsync accounts can theoretically be upgraded to use different signing logic, but the default path for the vast majority of users remains ECDSA.

Summary of cryptographic components:

---

Understanding Q-Day and Why It Matters for ZKsync Users

Q-Day is the hypothetical point at which a cryptographically relevant quantum computer (CRQC) becomes operational. A CRQC capable of running Shor's algorithm at scale could derive a private key from a publicly known public key in polynomial time. That single capability would compromise every ECDSA-secured wallet on every major blockchain.

What Gets Exposed on ZKsync at Q-Day?

When you interact with ZKsync Era, your public key is exposed on-chain at the moment of your first transaction (Ethereum addresses are a hash of the public key, but the full public key appears in the signature data). From that point forward, a quantum adversary with sufficient capability could:

1. Observe your public key from historical transaction data.
2. Derive your private key using Shor's algorithm.
3. Sign fraudulent transactions draining your account before you can react.

Crucially, ZKsync's rollup architecture does not provide any additional cryptographic protection against this. The rollup compresses and validates transactions, but the underlying signature authority still flows through the same ECDSA key. If that key is compromised, the rollup cannot distinguish a legitimate transaction from a fraudulent one.

The Reused Address Problem

A widely misunderstood nuance: if you have never sent a transaction from an address, your full public key is not yet exposed. The address is a Keccak-256 hash of the public key, which is quantum resistant under Grover's algorithm (the hash preimage is not recoverable by a quantum computer in practical time). However, the moment you transact, you lose that protection permanently. Since ZKsync is a high-throughput Layer 2 designed for frequent use, essentially every active ZKsync address is a public key that is visible on-chain and thus theoretically extractable by a CRQC.

---

ZKsync's Account Abstraction: A Partial Mitigation Path?

ZKsync Era is built with native account abstraction (AA) from the protocol level, unlike Ethereum mainnet where AA requires smart contract workarounds. This is the most plausible near-term path toward quantum resistance for ZKsync users.

How Account Abstraction Could Enable Post-Quantum Signatures

Under ZKsync's AA model, an account is governed by a smart contract that defines its own validation logic. In theory, a developer could deploy an account contract that validates transactions using a lattice-based signature scheme such as CRYSTALS-Dilithium or FALCON, both of which are NIST PQC-standardised algorithms. The contract would reject any signature that does not conform to the post-quantum scheme.

This is architecturally possible. The practical barriers are:

• Proof overhead. Verifying a lattice-based signature inside a zk-SNARK circuit is computationally expensive. Lattice operations do not map cleanly to the arithmetic constraints that SNARKs are optimised for, meaning proof generation time and cost would increase substantially.
• No native protocol support. As of mid-2025, ZKsync Era has no roadmap item that commits to native post-quantum signature verification at the protocol level. AA-based PQC wallets would be third-party deployments, not a system-wide upgrade.
• User migration friction. Even if PQC account contracts were available, moving assets from a legacy ECDSA account to a post-quantum account requires a standard ECDSA-signed transaction, meaning the user must expose their public key one final time before migrating.

What Matter Labs Has Said

Matter Labs (the team behind ZKsync) has not published a formal post-quantum migration roadmap as of the time of writing. Their public communications focus on scaling, decentralisation of the sequencer, and the Elastic Chain vision. Post-quantum cryptography is not listed among the near-term priorities in public documentation or ZKsync Improvement Proposals (ZIPs).

This is broadly consistent with the position of most Layer 2 teams. The prevailing assumption is that Ethereum mainnet will address post-quantum security at the protocol level, and Layer 2s will inherit those changes. Whether that assumption is correct, and whether Ethereum mainnet upgrades will arrive before Q-Day, is an open question.

---

How Ethereum's PQC Roadmap Affects ZKsync

Ethereum's post-quantum roadmap falls under the "Splurge" phase of Vitalik Buterin's roadmap, which is the latest and least defined phase. Concrete proposals have been discussed, including:

• Replacing ECDSA with a hash-based or lattice-based signature scheme at the protocol level.
• EIP-7212 and related proposals exploring alternative curve support.
• A potential hard fork that would enable accounts to be converted to post-quantum equivalents.

Vitalik has written publicly that Ethereum could implement an emergency fork to address a quantum threat if necessary, and that much of the infrastructure for doing so already exists in the form of smart contract wallets. However, "could implement" is very different from "has a tested, deployed plan."

For ZKsync users, the dependency on Ethereum's PQC progress is nearly total. If Ethereum upgrades its signature scheme, ZKsync would need to update its circuits and proof systems to accommodate those new primitives. That secondary upgrade cycle would add further latency.

---

Lattice-Based Post-Quantum Wallets vs. Standard Crypto Wallets

For users who want quantum protection now rather than waiting for protocol-level upgrades, the practical alternative is to hold assets in a wallet that uses post-quantum cryptography at the key management layer.

NIST PQC-standardised algorithms (as of 2024):

• CRYSTALS-Kyber (now ML-KEM) — key encapsulation
• CRYSTALS-Dilithium (now ML-DSA) — digital signatures
• FALCON (now FN-DSA) — compact lattice signatures
• SPHINCS+ (now SLH-DSA) — hash-based signatures, no lattice assumption required

These algorithms are built on mathematical problems (Learning With Errors, Module-LWE, NTRU lattices) that have no known efficient quantum algorithm. They represent the current frontier of quantum-resistant cryptography.

Projects building wallets around these primitives, such as BMIC.ai, which implements lattice-based post-quantum cryptography aligned with NIST PQC standards, represent a different architectural philosophy: rather than waiting for incumbent chains to migrate, they build quantum resistance into the key layer from day one.

The trade-off is ecosystem breadth. A purpose-built PQC wallet may not yet interface with the full ZKsync DeFi ecosystem the way a MetaMask or Rabby wallet does. But for users whose primary concern is the long-term security of their holdings against a quantum threat, the calculus is straightforward: quantum resistance today versus a migration promise at an unspecified future date.

---

Realistic Timeline Assessment: When Does This Actually Matter?

No credible institution has confirmed a CRQC capable of breaking secp256k1 in the near term. IBM's quantum roadmap targets error-corrected, fault-tolerant systems in the 2030s. The US National Security Agency has mandated migration to post-quantum algorithms for national security systems by 2035. NIST completed its PQC standardisation in 2024, reflecting the view that the threat window is now open even if Q-Day itself is years away.

Scenario analysis:

The "harvest now, decrypt later" threat is underappreciated. Sophisticated state-level adversaries may already be recording encrypted blockchain transaction data with the intention of decrypting it once a CRQC becomes available. For ZKsync, this means historical transaction data including public keys is already at potential future risk.

---

Key Takeaways for ZKsync Holders

• ZKsync uses ECDSA (secp256k1) for transaction signing. This is not quantum safe.
• The "ZK" in ZKsync refers to zero-knowledge scalability proofs, not post-quantum security. The zk-SNARK layer is also vulnerable long-term.
• Native account abstraction gives ZKsync a theoretical migration path to post-quantum signatures, but no concrete roadmap or native protocol support exists yet.
• ZKsync's PQC future is substantially dependent on Ethereum mainnet's own post-quantum upgrade timeline.
• Users with a long-term security horizon should evaluate purpose-built post-quantum wallets as a complementary or transitional holding strategy.