The Core Problem With Migrating Classical Blockchains To Post-Quantum Cryptography
26th June 2026
A deep-dive conversation with Dr. Joseph Kearney, Michael Strike, and Ryan Malinowski on the QRL Show
Show Opening / Overview
Hey everyone, and welcome back to another episode of the QRL Show—the place where you come for the crypto and stay for the quantum.
On today’s episode, my co-host Michael Strike and I are joined by Dr. Joseph Kearney. Joseph is a post-quantum cryptography expert, technical advisor to the QRL, and brings a wealth of experience at the busy intersection of blockchain, crypto, and quantum tech. He previously worked as a research associate at the University of Kent in the UK and has spent the better part of a decade focused on mitigating the risks that quantum computing poses to the cryptographic systems underpinning modern blockchains.
Today’s topic is one of the most pressing challenges facing the entire crypto industry: the core problem with migrating classical blockchains to post-quantum cryptography. We’re going to walk through seven generalized migration strategies that have been proposed across the industry, examine the good and bad of each, and discuss the limitations that come with them. If quantum-era blockchain security is up your alley, you’re going to want to read this one.
QRL Has Been Post-Quantum Native Since the Genesis Block in 2018
Before diving in, Michael offers some quick context for newcomers:
“The QRL has been post-quantum resistant since the genesis block in 2018 using NIST government-grade cryptography. We were the first blockchain in the world, in fact, to implement post-quantum security from block one. So all of the migration problems that we’re going to talk about today—and the generalized, blockchain-agnostic solutions that are being proposed—none of them apply to us. QRL doesn’t have any of these issues because no post-quantum migration is necessary.”
Michael goes on to note that QRL is in the final stages of moving from proof-of-work to proof-of-stake through Project Zond, with two independent third-party audits (Trail of Bits and Halborn) currently wrapping up. The new network introduces the QRVM—an EVM-friendly execution environment forked from the Ethereum Virtual Machine—making it the world’s first non-compromising post-quantum secure smart contract platform. As the QRL team noted in a recent theqrl.org press release, this means developers will be able to deploy Solidity-based smart contracts onto a chain that’s quantum-secure by design.
A key takeaway heading into the rest of the conversation: with every migration strategy we’ll discuss, there is no automatic or passive upgrade path for existing wallets. Users will need to perform a deliberate on-chain action to migrate. There will be procrastinators, lost keys, and people who simply don’t understand the risk. This creates a fundamental tension with the principle of “not your keys, not your crypto”—essentially becoming “not your migrated key, not your crypto.”
Michael frames this as more of a philosophical and ideological problem than a purely technical one:
“The post-quantum secure upgrade from classical to quantum isn’t really as much of a technical problem as it is a philosophical and ideology problem. There’s almost inevitable or certain property confiscation at play here. This is what was already brought up by CZ just a couple of days ago—proposing confiscating Satoshi’s keys on Bitcoin. The ecosystem is really starting to catch up to what the transition from classical cryptography to post-quantum cryptography actually means and how that has the potential to rewrite ideologies and philosophies of blockchain. If you can accept that property confiscation is likely, then that undermines the original Bitcoin white paper. ‘If it’s your private key, you own the Bitcoin.’ And now we’re looking at a situation in which this could be potentially voted out either democratically on chain or through consensus.”
Dr. Kearney adds his framing to the problem:
“99.999% of cryptocurrencies that you go to CoinMarketCap—almost all of them—are going to have to migrate in some way or another. There’s maybe two or three blockchains that aren’t going to have to do that because they were post-quantum native. The migration process starts with introducing some mechanism of protecting from quantum computing. I know that sounds obvious, but there’s a cryptographic change that has to occur. And I think the key thing for the listeners to understand is there are two aspects of the blockchain that cause this to be a major difficulty. The first is the immutability of the blockchain—nothing can be overwritten, deleted, or removed from the ledger’s history, meaning that revealed public keys are always accessible. The second part is the permissionless aspect—you hold your own keys and you are the only one that can actually spend any cryptocurrency associated with those keys. But that also means that no central authority can upgrade for you. You have to do it yourself.”
In Blockchain, What Does Migration Even Mean?
Before we dig into the proposed solutions, we need to define what “migration” actually means in this context.
Michael draws a critical distinction:
“It’s one thing to add the ability to utilize post-quantum signatures, but it’s a completely different proposition to have the entire network in such a state that there aren’t any vulnerable key sets still active. That’s what we’re talking about with migration—the movement from a blockchain that’s quantum-vulnerable to a blockchain that’s quantum-resistant. If you had a quantum device, there would be nothing you could do to that network to negatively impact it.”
“A blockchain could introduce some new output type—Falcon, ML-DSA, whatever—but if they haven’t completed the migration to post-quantum cryptography, they’re still vulnerable to quantum attack. A post-quantum secure transaction does not a post-quantum secure blockchain make.”
As the Quantum Resistant Crypto migration playbooks note, these transitions are far from simple software updates. Every node must adopt the new scheme, millions of keys must be regenerated without compromise, and historical transactions must remain verifiable—all while maintaining backward compatibility. For established chains like Bitcoin, where the original coins are tied to exposed public keys in early Pay-to-Public-Key (P2PK) outputs, the stakes are particularly high: a sufficiently powerful quantum computer could potentially forge signatures for dormant addresses and move those coins.
Direct Integration of Post-Quantum Signature Schemes via Soft Fork Mechanisms
The first strategy on the list is direct integration of post-quantum signature schemes via soft fork mechanisms—essentially what BIP 360 (the “Pay to Quantum-Resistant Hash” proposal) is suggesting for Bitcoin.
How it works: A new post-quantum secure digital signature algorithm—such as ML-DSA (formerly CRYSTALS-Dilithium), FALCON, or SLH-DSA (SPHINCS+)—is introduced as a new transaction output type. Users would take their existing wallet or coins and “bump” them manually to a new address that is now available as part of the wallet. This requires a soft fork to facilitate the new transaction type.
The good: This is the base-level step every project needs to take. It allows users to take control of their own crypto and migrate at their own pace. The new digital signature scheme is post-quantum secure, and ECDSA is, as far as we know, secure today (it just won’t be in 5–10 years).
The limitations:
- Adoption dependency: This strategy relies on users being knowledgeable enough to reach critical mass on their own. It also requires every wallet provider—MetaMask, Ledger, whatever—to integrate the new signature type. If a user can’t easily migrate through their existing wallet, the whole thing falls down.
- Fungibility problem: Under the same ticker, some coins will be under different layers of security. This creates a valuation issue: are these post-quantum-secure coins worth more than those still on classical signatures? Eventually, someone will have to make a call on abandoned wallets, and that’s when the property confiscation narrative really starts to take effect.
- Lost functionality: The new signature schemes don’t always have the same properties as the old ones. For example, Schnorr signatures were used by Bitcoin in Taproot to enable multi-sig. That’s impossible with current post-quantum schemes. That’s a problem that hasn’t been solved yet.
- It’s not actually a full migration: Adding a post-quantum secure transaction type doesn’t make a blockchain post-quantum secure. There will be orphans, and at some point, somebody will have to handle those.
As the QRL guide on post-quantum blockchain security points out, QRL avoids this entire class of risk by having been post-quantum secure from day one, rather than relying on a future migration to plug the gap.
Hybrid Cryptographic Schemes
The next strategy is the hybrid cryptographic scheme approach, where users are required to have both a classical (ECDSA) and a post-quantum key pair, and the system combines the security of both.
The premise behind it: Lattice-based cryptography—the foundation of schemes like ML-DSA and FALCON—is significantly less battle-tested than the trapdoor problems underlying ECDSA. There’s a concern among some cryptographers that classical algorithms could eventually solve the shortest vector problem in polynomial time. The hybrid approach hedges against that risk: if the post-quantum signature fails, you’ve still got ECDSA as a backup. If Q-Day happens, you’ve got the post-quantum layer there.
The critical flaw: The entire premise of a hybrid system relies on knowing when Q-Day arrives. And as Joseph notes:
“The premise behind that is that you know when QDay happens. That’s the critical flaw, in my opinion, for hybrid-based systems. You’re under the assumption that you know when a CRQC exists. It creates a false sense of security that you can always transition over when you know Q-Day happens, but it’s unlikely that you will.”
Michael expands on this with a broader perspective:
“When Q-Day happens, you won’t know. State intelligence, encrypted communications—‘harvest now, decrypt later’—information nowadays is more valuable than fiat. The development of CRQCs is being done under a veil of secrecy by some of the smartest people in the world. What we see being published in the news is really just the top of the iceberg. There is no incentive for a nation-state to publish its actual progress on a cryptographically relevant quantum computer. And if a quantum computer were to steal or move funds, you would not be able to tell at the node level—because a transaction by a CRQC would be cryptographically identical to a legitimate user transaction.”
This is further complicated by the fact that some post-quantum schemes are already better understood than others. As Joseph mentions, there are implementation issues with FALCON, but ML-DSA is generally considered more mature. Even so, the dependence on knowing the timing of Q-Day is what fundamentally undermines the hybrid approach.
zk-STARKs and Zero-Knowledge-Based Authorization
Next on the list: zk-STARKs and zero-knowledge-based authorization. A lot of protocols have been talking this up, but there are important nuances to understand.
A critical distinction first: zk-SNARKs (with an “N”) are quantum-vulnerable—they’re based on the same foundational problem as ECDSA. So if any project claims quantum resistance because they use zero-knowledge proofs but they’re using zk-SNARKs, that claim is false, unless they’re using a special lattice-based variant.
zk-STARKs, on the other hand, are not quantum-vulnerable and offer some genuinely interesting properties. With a zero-knowledge proof, you can prove a transaction fulfills all the rules of the blockchain (not exceeding your balance, not printing tokens, etc.) without revealing any information about yourself. Crucially, with a STARK-based approach, you would never need to reveal your digital signature or public key, so there’s nothing for an attacker to target.
The EDDSA angle: Joseph brings up an interesting application from a recent paper. EDDSA—used by Solana and a few other chains—requires users to produce a seed phrase. Because of that, you can create a proof of knowledge of that seed phrase to demonstrate ownership over a public-private key pair. Theoretically, this could allow a “trivial” migration path: lock down the entire blockchain, and all that would be required to migrate is for users to create a proof of their existing key.
The limitations:
- zk-STARKs aren’t true zero-knowledge yet. The amount of information they leak is minimal, but they aren’t true zero-knowledge. True zero-knowledge STARKs are still being developed by companies like StarkWare.
- Proof size uncertainty: We don’t know how large these proofs would need to be. They could be absolutely massive.
- Not all wallets use seed phrases. Bitcoin Core, for instance, is just a UTXO. The seed-phrase-based proof approach doesn’t apply to chains where the wallet model is different.
- Requires user action: You still have to do something. And in some cases, you need to do something today in order to be able to recover tomorrow—which automatically excludes a large number of older, wealthier accounts that may not take action in time.
As an interesting parallel, Anchorage Digital has published research on a post-quantum key migration mechanism using zero-knowledge proofs of hash preimage knowledge, where a STARK-based proof demonstrates knowledge of a private key while a new post-quantum key pair is deterministically derived via HKDF. It’s a novel approach but, like everything else, still requires the user to take action.
Commit-Reveal, Delayed-Reveal, and Time-Lock Migration Protocols
The next strategy is commit-reveal, delayed-reveal, and time-lock migration protocols—something that has been proposed in various forms for Bitcoin.
How it works: Users first publish an on-chain commitment (a hash or some kind of migration intent). After a delay, time-lock, or later reveal phase, they prove control using a post-quantum secure scheme. This is a mix of classical and post-quantum inputs being accepted, but outputs are restricted to post-quantum only. The idea is to prioritize certain types of outputs over others in order to give more time for migration to take place.
Why it exists: The main motivation is the size problem. Post-quantum signatures like ML-DSA, FALCON, and SLH-DSA are significantly larger than ECDSA signatures. As the Quantum Resistant Crypto migration playbooks highlight, PQC signatures can be on the order of ~2.3 KB compared to ~72 bytes for classical ECDSA. This has major implications for storage, bandwidth, and gas costs. A commit-reveal approach allows the network to delay the full impact of those larger signatures until they’re actually needed.
The limitations:
- It asks users to do two things rather than one. Users have to send a proof that they own an address, and then in the future, they need to send an ML-DSA transaction proving that they owned it. It’s essentially migrating twice.
- Key loss risk: If you create an on-chain proof and you own your ECDSA keys, but you lose your ML-DSA keys, you could potentially lose access to everything. There are mitigations, but the risk is real.
- Same fundamental flaw: Users still have to do something. There’s just no getting around it.
Account Abstraction and Smart Contract Wallet Migration
The next approach is account abstraction and smart contract wallet migration—one of the more debated strategies in the Ethereum ecosystem, and one where Mike and Joseph actually have a productive disagreement.
How it works: A user hands their wallet over to a smart contract, which handles all the rules and migration logic for them. This preserves the user’s address and balance but introduces smart contract complexity, gas costs, and the requirement that the user still performs a step (or two).
Michael’s skepticism (the engineer’s view):
“I think it’s kind of a dirty approach in that it increases on-chain complexity. It centralizes the migration process to a smart contract. I don’t like single points of failure. I don’t like the complexity of it. I don’t like having multiple post-quantum secure options—I’d rather have it be more singular. That introduces more fungibility and different types of security wrappings around the same token. I’d rather have everything stay contained, singular, doesn’t confuse the hell out of the user, doesn’t make any external calls, and doesn’t create value disparity.”
Joseph’s enthusiasm (the crypto-agility view):
“I completely disagree. I think account abstraction is, certainly for Ethereum, one of the best mechanisms that they can use. It gives you massive crypto-agility. It doesn’t matter what the core protocol determines—you gain the ability to spend your tokens in whatever way you want. You could have a smart contract that allows you to spend using FALCON, ML-DSA, or SLH-DSA, whichever one you choose. You could create a smart contract that allows you to use zero-knowledge groups. It gives you true crypto agility and you’re self-sovereign over your keys.”
“The advantage is that it allows wallet providers and post-quantum companies to provide options without the underlying protocol having to change. Ethereum could fail to implement changes—we’ve seen the Ethereum Foundation cutting staff over the last week. Account abstraction provides an option for that specific blockchain to have some post-quantum safety without the core protocol changing.”
The consensus: It’s a great option, but the setup costs are real, and more options means more potential vulnerabilities. User still has to do something.
Hybrid / Parallel Chain or Bridged Migration Strategies
The penultimate strategy: hybrid/parallel chain or bridged migration strategies. This is the model that almost all post-quantum “projects” have been following since QRL’s genesis in 2018.
How it works: You have an ERC-20 or BRC-20 token that is DeFi-compatible (allowing liquidity on Uniswap, PancakeSwap, etc.), plus a separate L1 chain that is post-quantum secure, with a bridge between the two. The idea is that you get the advantages of classical blockchain liquidity while being able to bridge over to a post-quantum secure network.
The problems:
- Valuation disparity: Are the tokens on the classical blockchain worth the same as the ones on the post-quantum secure L1? This creates the same fungibility problem as other strategies.
- It’s the same problem Bitcoin has. You’re essentially recreating up front what looks like a post-quantum secure chain, but it has the same migration issue—users have to move their ERC-20s over to the new L1, and eventually the bridge has to be cut. There will be orphans. The narrative will become: “These are obviously abandoned tokens.”
- It weakens both sides. As Joseph puts it: “I don’t even see this as a migration strategy. I wouldn’t consider it to some extent. It’s just a way of trying to get the best of both worlds when in reality, you’re just weakening both sides.”
The QRL contrast: QRL has taken a different approach—isolated from classical DeFi ecosystems, purely post-quantum secure. When QRL 2.0 launches, post-quantum secure bridges could be created, but the difference is that users would make a conscious choice to take their QRL and use a QRVM smart contract on a classical chain. Ideally, a “DeFi reset” occurs and a new purely post-quantum-secure ecosystem emerges, where existing Ethereum smart contracts can be ported over to QRL 2.0.
As Joseph also notes, there are even more aggressive parallel-chain strategies where a quantum version of Bitcoin matches transactions one-for-one and holds a database of migrated users—essentially trying to reach critical mass so that a fork can eventually be recognized. But once again, “nothing beats simplicity” in his view.
ZK-Based Rescue and Recovery Protocols for Legacy Assets
The final strategy on the list: ZK-based rescue and recovery protocols for legacy assets.
How it works: The idea is that you utilize zero-knowledge proofs to create a proof of knowledge today that you can use into the future to recover your cryptocurrency. This gives you a much longer window—potentially allowing you to recover Bitcoin well after Q-Day has arrived.
The limitations:
- If you’ve already revealed your public key, it’s redundant. You’re already vulnerable. This adds complexity without much gain on something that needs to be as simple as possible.
- Proof size matters. The only exception would be if we know the proof sizes for the EDDSA mechanism and they’re small enough that you’re not uploading kilobytes per user of data per upgrade. For Bitcoin, and maybe even Ethereum, there are likely better options.
Michael closes out this section with a pragmatic observation:
“At the end of the day, I think what’s going to happen is essentially Bitcoin or other classical blockchains are just going to take a more simple approach. The more complicated you make these approaches, the more confused the users become, and then participation starts to drop. I see these as negative correlations. Complexity goes up, user participation goes down.”
His prediction: A post-quantum secure DSA gets added to classical chains. Users are forced to perform a transaction. A block height is set. Either the old DSAs are deprecated and can no longer be used, or they’re left in place and it becomes survival of the fittest based on whoever develops the first CRQC. It’s a messy, complicated process, but simplicity wins.
Closing Thoughts
As we wrap up, the key takeaways are clear: this is a dynamic environment. In three months, six months, or a year, we may be discussing entirely new potential methods—or improvements to existing ones. The migration space is evolving rapidly.
What hasn’t changed is the fundamental message: if you want to avoid the entire migration problem altogether, the simplest answer is to use a chain that has been post-quantum secure from the very beginning. QRL has been doing exactly that since 2018, and with QRL 2.0 on the horizon, the project is bringing post-quantum security to the smart contract world with EVM compatibility, the QRVM execution environment, and the Hyperion smart contract language.
As Dr. Kearney notes in closing:
“My first academic paper looked at various blockchains and how the differences in their protocols affect their post-quantum vulnerability. Because each protocol is so wildly different, while the cryptography is the same, the actual underlying protocol is so different—the migration path that is optimal for each individual chain is going to vary massively. What’s right for Bitcoin is not necessarily right for Ethereum. It’s not right for Solana.”
The industry needs to have these conversations openly, even when they’re uncomfortable—because the alternative is waiting until Q-Day is already upon us, and by then, as we’ve discussed, you likely won’t even know it’s happening.
Outro
For those of you watching who want to dive deeper into post-quantum blockchain security, the QRL Discord is a vibrant town square where academics, developers, retail crypto users, and forward-thinking institutions are having exactly these conversations every day. Until the next episode, keep those digital assets post-quantum secure.
Thanks to Dr. Joseph Kearney and Michael Strike for joining us on this deep dive. We’ll see you in the next episode of the QRL Show.
Resources mentioned in this episode:
26th June 2026
