Quantum computers powerful enough to threaten today’s cryptography don’t exist yet, and your assets are safe today. But this is the kind of shift worth preparing for early rather than late. ThunderCore has started that work, and as a continuation of our previous article, this post explains how we’re thinking about it.

Why We’re Publishing This Now

Almost every blockchain, including ThunderCore, is secured by a type of cryptography that today’s computers can’t realistically break. A sufficiently advanced quantum computer could, eventually, change that. Nobody knows exactly when (credible estimates vary widely), which is precisely why we’d rather begin preparing well ahead of time than scramble later.

Think of it like upgrading the locks on a building. You don’t wait until someone invents a tool that can pick the old ones; you plan the upgrade calmly, in advance, while everything is still secure.

Standards bodies are already thinking this way: NIST has signaled that today’s classical public-key cryptography should be deprecated by around 2030 and phased out entirely by 2035. Those dates are guidance for the industry at large, not a countdown for your wallet — but they’re a useful signal that “early and calm” is the right posture.

What is Actually at Risk

It’s worth being clear-eyed rather than alarmed. The main thing a future quantum computer could threaten is the “signature” that proves you own your wallet and authorizes your transactions. That’s the part we’re focused on protecting (It should be noted that validator/consensus signatures, bridge-validator keys, and governance/upgrade keys are also quantum-exposed and need migration).

Just as importantly, here’s what this is not: it’s not a problem affecting you today, it’s not a reason to move or change anything right now, and it’s not something we’re treating as a sudden emergency. It’s a long-horizon shift, and we’re treating it like one.

One worry you may have seen elsewhere is “harvest now, decrypt later” — the idea that attackers could record encrypted data today and unlock it once quantum computers arrive. That threat mostly applies to secret data. Blockchains are different: the ledger is already public by design, so there’s nothing to “decrypt” later. The real question is signature forgery — could someone fake the authorization for a transaction — and that’s exactly what this roadmap addresses.

Principles Guiding Our Approach

Rather than promise a destination, we’re committing to principles we believe will hold regardless of how the standards landscape settles.

• Stay flexible. The most valuable thing we can do now is ensure ThunderCore can adopt stronger protections smoothly when the time comes, without disruptive last-minute overhauls.
• Don’t lock in too early. The new security methods are still being tested and standardized worldwide. We’d rather keep our options open than bet on one approach prematurely. That said, we are actively evaluating the candidates to understand which trade-offs matter most for our ecosystem.
• Protect users first. Whatever path we take should keep you in control of your own assets and avoid breaking the apps and tools you rely on.
  
  

Our Roadmap

We think about the work in four broad phases. These are directional, a way of sequencing our thinking, not a fixed calendar. We believe that by tackling each phase with the following information in mind, we will be much more prepared for the future.

Workstream	Phase 1 Preparation	Phase 2 Infrastructure	Phase 3 Migration	Phase 4 Full Transition
Cryptography & Signatures	Research NIST-approved PQC standards.	Add precompiles for PQC algorithms (e.g. signature verification, gas pricing).	Standardize hybrid signatures (ECDSA + PQC).	Native PQC signature validation at the protocol level; deprecate quantum-vulnerable public-key cryptography.
Accounts	Adopt account abstraction (EIP-4337).	Deploy quantum-safe smart-contract wallets.	Develop tooling (e.g. EIP-7702 delegation) to help existing accounts adopt quantum-safe smart-contract features.	Address dormant EOAs with exposed public keys.
Consensus & Networking	Audit BLS signature vulnerabilities.	Explore PQC key encapsulation mechanisms (KEMs) for node-to-node communication.	Run parallel PQ-consensus testnets with PQC validator signatures.	Phase out classical key exchange between nodes; a future network upgrade could move consensus fully onto post-quantum signatures.
State & Storage	Research how larger signatures affect block size, bandwidth, and long-term data growth.	Evaluate statelessness and related data-efficiency techniques to absorb the heavier load.	Increase block size and adjust gas limits for larger PQC payloads.	Optimize data structures for PQC signature data.

Please keep in mind these phases describe direction, not commitments.

Phase 1: Preparation

The groundwork phase, focused on research and assessment rather than shipping changes.

• Cryptography & Signatures: Study the maturing body of NIST-approved post-quantum standards and what they imply for a chain like ours.
• Accounts: Explore account abstraction — both smart-contract wallets (EIP-4337) and the newer ability for existing accounts to adopt smart-contract features in place (EIP-7702) — as a flexible substrate that could make future signature-scheme changes far less disruptive.
• Consensus & Networking: Audit the networking and signature surfaces — BLS signatures among them — to understand where quantum exposure actually sits. This is one of the harder problems in the space: the compact, combinable signatures that make modern consensus efficient don’t yet have a mature post-quantum equivalent, which is exactly why we’re starting the homework early.
• State & Storage: Post-quantum signatures are much larger than today’s — kilobytes instead of tens of bytes — so we’re researching what that means for block sizes, network bandwidth, and how much data the chain accumulates over time.
  
  

Phase 2: Infrastructure

Assembling the optional building blocks that a transition would eventually rely on.

• Cryptography & Signatures: Investigate precompiles for PQC algorithms (for example, signature verification) and how such operations would be priced.
• Accounts: Prototype quantum-safe smart-contract wallet designs.
• Consensus & Networking: Explore post-quantum key encapsulation mechanisms (KEMs) for securing node-to-node communication.
• State & Storage: Evaluate statelessness and related techniques to absorb the heavier data load.
  
  

Phase 3: Migration

Exploring how an actual transition could happen smoothly and voluntarily, ahead of any requirement.

• Cryptography & Signatures: Examine hybrid signatures (classical ECDSA combined with a PQC scheme) as a transitional, defense-in-depth approach.
• Accounts: Develop tooling that could help users move from externally owned accounts toward smart-contract accounts.
• Consensus & Networking: Run parallel post-quantum consensus testnets using PQC validator signatures to learn from real conditions.
• State & Storage: Revisit block size and gas parameters so larger quantum-safe payloads remain practical.
  
  

Phase 4: Full Transition

The most distant and least defined phase. We include it for completeness and to be transparent about where the path could lead, not because any of it is decided.

• Cryptography & Signatures: In a fully realized transition, the network could eventually validate PQC signatures natively at the protocol level and phase out reliance on quantum-vulnerable public-key cryptography.
• Accounts: Accounts with long-exposed public keys present one of the hardest open questions in this space. Approaches are being actively discussed across the industry, and any measure here would require significant community deliberation and governance before it could be considered.
• Consensus & Networking: A future network upgrade could move consensus fully onto post-quantum primitives. The form and timing of any such upgrade remain open.
• State & Storage: Data structures would be optimized for the realities of PQC signature data.
  
  

On Standards

The good news is that this work isn’t starting from zero. In 2024, the U.S. National Institute of Standards and Technology (NIST) finalized its first post-quantum standards — ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures — with more on the way. Each comes with different trade-offs in size, performance, and maturity, and the industry is still learning which fits blockchains best.

We intend to align with credible, well-vetted standards bodies and industry work as it solidifies, and to choose based on the trade-offs that matter most for ThunderCore and its users when the decision is ripe.

Because ThunderCore is fully EVM-compatible, we also benefit from the enormous research effort happening across the Ethereum ecosystem, where post-quantum signatures, account migration, and state growth are all being actively worked on. We intend to stay aligned with that direction wherever it makes sense, so that the wallets, tools, and contracts you already use keep working here.

Conclusion

Quantum readiness is a long game, and the chains that handle it well will be the ones that started early, stayed flexible, and were honest about what they did and didn’t yet know. That’s the posture we’re choosing. We’ll keep sharing as the picture comes into focus.