Most people learn about quantum computing through a headline, but the headlines aren’t saying the same things. One set says a machine is about to read every password on the internet, while the other says the field is absorbing billions on promises that will never leave the lab.
Neither position accurately reflects what is actually published. Below are the five assumptions that follow from believing one version or the other, and what each one gets wrong.
Myth 1: “Quantum computers will break encryption and crypto wallets in no time, and there’s no time to prepare”
Can a quantum computer drain your crypto wallet overnight?
No. As of August 2026, no machine capable of breaking public-key cryptography exists.
What has changed is the estimated price of building one. In March 2026, Google published a sharply lower estimate for breaking 256-bit elliptic-curve cryptography, and security teams stopped treating this as a research curiosity once the numbers started falling that fast.
Those numbers need one distinction to read correctly, which is why the same threat gets described as needing a thousand qubits or half a million. Logical qubits are error-corrected and stable enough to run a long computation; physical qubits are the raw hardware, and it currently takes roughly one thousand of them to build one logical qubit. Google’s estimate works out to fewer than 1,200 logical qubits, or fewer than 500,000 physical ones. Today’s leading processors operate around 100 to 150 physical qubits.
Which coins and wallets are actually exposed?
Any wallet whose public key has been published, which probably doesn’t include everything you own.
Nearly every wallet in crypto is secured by elliptic-curve cryptography (ECDSA) or a close relative, and Shor’s algorithm, given a large enough quantum computer, derives a private key from its matching public key. So one’s exposure depends on whether that public key is visible. A Bitcoin address you have never spent from exposes only a hash of the public key. Spending publishes the key itself, which leaves funds in previously used addresses carrying the real risk. Chains where the public key is visible by default give you no such buffer.
Knowing which of your holdings sit in each category tells you what is vulnerable and what can be left as is.
Has anyone actually deployed a quantum-resistant wallet?
Yes, on Starknet mainnet on July 22, 2026. The transaction settled in public and can still be looked up on the block explorer.
The transfer cost about six cents and used Falcon-512, a lattice-based signature scheme with unusually compact signatures. S2morrow demonstrated a working Falcon-512 account written in Cairo, and OpenZeppelin published deployable versions and built the account behind that mainnet transfer. It’s important to point out that the account is experimental and unaudited, built for research rather than production. However, real value moved through it regardless, using a signature no quantum computer can forge and cryptography anyone can deploy today.
This puts both the panic framing and the complacent version in a bad light. Quantum computing isn’t coming for your keys tonight, and the preparation is already cheap enough that one wallet did it for a few cents.
Myth 2: “We don’t need to act until a cryptographically relevant quantum computer (CRQC) actually exists”
Is there anything to do before a quantum computer exists?
Yes. The machine does not have to exist for your data to be exposed to it.
An adversary can record encrypted data today and hold it until the hardware arrives, a type of attack the industry calls, “harvest now, decrypt later.” Anything with a confidentiality requirement that extends into the 2030s, which covers things like health records, financial data, legal files, and state secrets, needs post-quantum protection from the moment it was created, because a copy taken that day can be decrypted once the hardware exists.
Onchain data follows the same logic: a public key exposed today sits in permanent public storage, waiting for a machine that does not exist yet, meaning a bad actor who copied it can derive the private key and drain the account once a large enough quantum computer exists.
What are the actual deadlines?
The deadlines are published ones. Regulators stopped waiting for a hardware forecast and began assigning dates.
Executive Order 14412, signed on 22 June 2026, gave US federal agencies 90 days to submit a migration plan and requires all high-value assets and high-impact systems to use post-quantum cryptography for key establishment by 31 December 2030, and for digital signatures by 31 December 2031. Federal contractors are likely to be pulled in through procurement rather than by direct mandate: the same order directs the FAR Council to publish a proposed rule requiring covered contractors to comply with applicable NIST FIPS by 31 December 2030. That rule still has to clear notice-and-comment rulemaking, and it will define who counts as a covered contractor.
National security systems run on a different schedule. The NSA’s CNSA 2.0 suite stages its transition by product category, with the overall window falling roughly between 2030 and 2033. New National Security Systems (NSS) acquisitions are expected to support CNSA 2.0 from 1 January 2027, and full quantum resistance across NSS is expected by 2035 under NSM-10. CNSA 2.0 is NSA guidance rather than law, and the per-category exclusive-use dates have been refined since the 2022 announcement, so universal dates should be questioned.
The National Institute of Standards and Technology’s (NIST) own transition roadmap, IR 8547, deprecates RSA and elliptic-curve cryptography after 2030 and disallows them after 2035.
None of these dates is affected by hardware developments.
Myth 3: “Our cloud provider will handle quantum readiness for us”
Will your cloud provider handle post-quantum migration for you?
No, they can ship post-quantum support, but they cannot find your own cryptography for you, and that is what determines whether you finish.
AWS, Azure, and Google Cloud will all ship post-quantum support, some of which has already shipped. None of it addresses finding your own cryptography, and you cannot migrate what you cannot see. Most organizations do not know where all their keys and certificates live, which is why serious frameworks open with discovery and a cryptographic bill of materials, meaning a full inventory of which algorithms, keys, and certificates you have and what depends on them. That inventory has to reach embedded keys in legacy applications, certificates issued by teams that no longer exist, hardcoded cryptography in firmware, and third-party libraries nobody has audited since procurement approved them.
No vendor can produce that list for you. Until it exists, you cannot tell whether a product covers your exposure or just a fraction of it.
Does the same apply to exchanges and custodians?
Partly, and which part depends on who holds the keys.
When a custodian holds your assets, their migration is theirs to solve, but it is important to understand whether they can address it with specifics rather than reassurances. Ask which layer they have addressed and on what schedule. A custodian who only discusses wallet signatures has answered half the question, for reasons Myth 4 covers below.
If you hold your own keys on a dapp, nobody will upgrade anything on your behalf. That work is yours to tackle, but this also means that you can start without waiting for a governance vote.
Myth 4: “Post-quantum migration is a simple software swap, like a normal encryption update”
Is post-quantum migration just a software swap?
No. Replacing the algorithm accounts for a small fraction of the total effort.
The work encompasses key management infrastructure, hardware security modules, certificate lifecycle and issuance, protocol negotiation, hybrid schemes that run classical and post-quantum in parallel, re-encryption of historical archives, and retraining for the staff who operate all of it. An organization that waits for quantum hardware before starting will be years behind on a program that takes years to run.
Are the replacement algorithms finalized?
Not all of them, which is another reason why a one-step replacement is the wrong mental model.
NIST selected Falcon in 2022 and is standardizing it as FN-DSA under FIPS 206. NIST submitted that draft on 28 August 2025, and as of August 2026 the final version is expected in late 2026 or early 2027. The three finished standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), were finalized in August 2024.
Crypto-agility, therefore, belongs in your requirements as a hard constraint. Committing to a scheme you cannot change later means committing to a specification that is a moving target.
Does swapping the signature make a system quantum-safe?
No, because a chain carries two separate exposures and a signature upgrade only reaches one.
The account layer is the signature that authorises a transaction from your wallet, and nearly all coverage stops there. The verification layer is the cryptography the network uses to establish that every transaction and balance is valid, and most readers have never been told it exists. A quantum computer threatens both, since most chains use elliptic curves in both places. A quantum-safe wallet on a chain whose verification can be forged protects nothing. Any token marketed as quantum-proof is making a claim about one layer or the other, and a launch post rarely says which. Ask.
Bitcoin wires elliptic-curve signatures into the protocol, so migration means a new output type and asking every holder to move funds. Ethereum has already started to loosen this. Account abstraction lets a wallet define its own verification logic, and EIP-8141 would make that native, so accounts can migrate one at a time instead of in lockstep.
Their verification layers differ more than the coverage suggests. Bitcoin validates state through hashing rather than a proof system, so Shor’s algorithm has nothing to attack there. Ethereum is exposed at this layer in two places. Consensus attestations use BLS signatures and blob commitments use KZG, both built on elliptic-curve pairings, and both are being replaced across a sequence of forks.
Pairing-based rollups inherit their signature scheme from the base layer, but their proof systems are built on elliptic curves. Replacing one means rebuilding the prover and the on-chain verifier contract that secures the bridge.
Starknet’s position comes from two decisions that predate the quantum conversation. StarkWare’s STARK proof system establishes computation using hash functions instead of elliptic curves, so the proving layer was never a target for Shor’s algorithm. That advantage covers the proof system and not every primitive in the protocol, and its strength depends on which hashes and parameters are chosen. The remaining work is published. Pedersen hashing, which inherits elliptic-curve assumptions, is being replaced with BLAKE2, and the Ethereum-facing bridge moves only when Ethereum does. The second decision is that every Starknet account is a smart contract, so no signature scheme is fixed in the protocol: each account decides in its own code what it accepts. Neither choice was made for quantum reasons, but both now shape the requirements of the migration roadmap.
Are zk-rollups and STARK-based chains in the same position?
No, and the difference sits in the proof system rather than the layer number.
Most zk-rollups run on SNARKs built on elliptic curves, inheriting exactly the assumption Shor’s algorithm attacks, so fixing them means rebuilding core cryptography from the inside. On the verification layer, that leaves most of them worse off than the base layers they settle to.
StarkWare’s STARK proof system establishes computation using hash functions instead. No quantum algorithm breaks a hash function outright the way Shor’s algorithm breaks an elliptic curve. Grover’s algorithm weakens a hash rather than breaking it, and the cost of that weakening depends on the parameters a system chooses.
But hash-based proving is not automatically hash-based verifying. Many systems generate a STARK and then wrap it in a pairing-based SNARK to cut on-chain costs. Once wrapped, L1 soundness rests on the wrapper, rather than on the proof underneath. Starknet’s L1 verifier checks the hash-based proof directly.
One clarification, since supporters and critics both get this wrong from the same bad premise. Neither STARKs nor BLAKE2 belongs to a FIPS family. That is not a mark against BLAKE2, which descends from BLAKE, a SHA-3 finalist with years of public cryptanalysis behind it. FIPS 205 standardizes SLH-DSA, a hash-based signature scheme, and it is worth citing only as evidence that NIST accepts hash-based security assumptions as a foundation for post-quantum standards. It tells you nothing about STARKs specifically.
What does a real staged migration look like?
An upgradeable account layer, and a published schedule for everything else.
Every Starknet account is a smart contract, and no signature scheme is hardwired into the Starknet protocol. Each account decides in its own code which signatures it will accept, so verifying a post-quantum signature is ordinary contract logic. No hard fork is needed, and no network-wide deadline forces everyone to move at once. An account can also swap its verification logic in place while keeping the same address and the same funds, so adopting Falcon-512 today does not commit that account to Falcon-512 permanently. That is relevant while FIPS 206 is still in draft.
StarkWare published a three-phase roadmap for Starknet on 30 June 2026. Phase one secures all new activity by replacing the remaining elliptic-curve-dependent hashing in state commitments, contract address derivation, and network configuration. Part of that has shipped, since Starknet v0.14.3 replaced Pedersen with a BLAKE2s-256-based construction for the OS program hash and OS config hash, and the change is live on mainnet. Phase two extends the same protection to existing contracts, and as of August 2026 StarkWare describes that tooling as under research. Phase three moves in step with Ethereum, because the bridge carrying messages and assets and the data availability layer where Starknet posts its data both still inherit elliptic-curve cryptography from Ethereum. Information about StarkWare’s quantum plans is available on the quantum hub.
Myth 5: “Quantum computing is either about to change the world or it’s pure hype, so why plan against uncertain
timelines?”
Is quantum computing all hype?
No, though the vendor record justifies skepticism about any specific date. PsiQuantum said it would reach a million qubits by 2025, then moved that target to 2027 with a year left on the original. BCG, reviewing its own 2021 forecast, conceded that its assumptions about near-term value creation had proved optimistic and needed revising. A vendor quietly revising its own date tells you more than a vendor missing one.
Meanwhile the work itself has kept moving. IBM has published a roadmap targeting quantum advantage by the end of 2026, with fault tolerance to follow in 2029. The number worth tracking is not a launch date but the cost of an attack. In March 2026, Google Quantum AI, the Ethereum Foundation and Stanford published resource estimates for breaking 256-bit elliptic curve cryptography: two circuits, one using fewer than 1,200 logical qubits and 90 million Toffoli gates, the other fewer than 1,450 logical qubits and 70 million. That is roughly a twentyfold reduction against prior estimates, and it came from algorithmic work rather than bigger hardware. Movement on that scale is what turns a research topic into a procurement question.
If the timeline is uncertain, why plan now?
Because your planning inputs are already fixed.
Harvest now, decrypt later exposure exists today. The 31 December 2030 US federal target is published, CNSA 2.0’s window runs 2030 to 2033, and NIST disallows RSA and elliptic-curve cryptography after 2035. A quantum-resistant signature moved value on Starknet mainnet for about six cents. Those facts hold whether a fault-tolerant machine arrives in 2030 or 2040.
An eighteen-month inventory does not become shorter while you wait for better forecasting.
Where should you start?
Start with the inventory, because everything downstream depends on knowing what you hold.
Find your cryptography and write it down, then work out which data carries a confidentiality requirement extending past 2030, since that sets your priority queue rather than any vendor’s roadmap. With those two in hand, migrate one small system end-to-end so your team learns what the work costs before a deadline sets the schedule for them.
That leaves timing as the thing to design for. For most systems, protection arrives when someone else’s fork, patch cycle, or governance deadline says it does. On Starknet, in 2026, it was already available to any holder who wanted it, at the address they already used, and an institution treating quantum readiness as a compliance question gets that same control over its own schedule.
_______________________________________________________________
FAQ
Can quantum computers break Bitcoin?
Not as of August 2026, since no quantum computer capable of breaking elliptic-curve cryptography exists. Bitcoin secures accounts with elliptic-curve signatures, so the exposure is real, but only appears when funds move from a previously used address.
Are STARK proofs quantum-resistant?
Yes. StarkWare’s STARK proof system relies on hash functions rather than elliptic curves. The strongest known quantum attack on a hash, Grover’s algorithm, only accelerates brute-force search, which is offset by a larger hash output.
Are zk-rollups quantum-safe?
Generally no, because most zk-rollups use SNARK proof systems built on elliptic curves, the same type of cryptography Shor’s algorithm attacks.
Is Starknet quantum-resistant?
Partly, and the answer depends on the layer. StarkWare’s STARK proof system relies on hash functions rather than elliptic curves, so the verification layer was never quantum-vulnerable. At the account layer, every Starknet account is a smart contract that can adopt a post-quantum signature without a hard fork, and a Falcon-512 account has transacted on mainnet, although that account was experimental and unaudited.
The remaining migration work is published as three phases: forward compatibility to secure all new activity, backward compatibility to cover existing contracts, and lastly, the Ethereum dependencies; namely, the bridge and data availability layer.
Is Falcon-512 a finalized NIST standard?
No. NIST selected Falcon in 2022 and is standardizing it as FN-DSA under FIPS 206, submitting the draft on 28 August 2025, and as of August 2026 the final standard is expected in late 2026 or early 2027. FIPS 203, FIPS 204, and FIPS 205 were finalized in August 2024.
What is “harvest now, decrypt later”?
Harvest now, decrypt later means recording encrypted data today and decrypting it once quantum hardware becomes available, which puts long-lived secrets at risk from the day they are created.
When is the post-quantum migration deadline?
For US federal agencies, Executive Order 14412 of 22 June 2026 sets 31 December 2030 for post-quantum key establishment and 31 December 2031 for digital signatures, covering high-value assets and high-impact systems. The NSA’s CNSA 2.0 stages National Security System transitions across roughly 2030 to 2033, with full quantum resistance expected by 2035 under NSM-10.
Last Update: August 20, 2026
