Stay Up to Date
Subscribe to our newsletter
Last month, four documents arrived in close succession: the Coinbase advisory board's position paper on quantum computing and blockchains, a Google announcement accelerating its internal cryptography deadline to 2029, a Caltech-linked preprint slashing qubit estimates by two orders of magnitude, and a public statement from the field's most prominent skeptic naming the same year. No single document says the window has closed. Read together, make a single argument: the cryptographic migration that most organizations have deferred to 2035 needs to begin now.
Most organizations have anchored their quantum migration plans to NIST's 2035 deadline. That anchor has shifted. In the span of five weeks this spring, three developments reset the threat timeline in ways that 2035-based planning does not account for.
On March 25, Google accelerated its own internal post-quantum cryptography deadline to 2029, citing faster-than-expected progress in quantum hardware, error correction, and factoring resource estimates. Days later, Oratomic published research showing that a fault-tolerant quantum computer capable of running Shor's algorithm could be built with as few as 10,000 qubits, roughly 100 times fewer than prior estimates. Then Scott Aaronson, a member of the Coinbase advisory board and the researcher who spent two decades as the field's most prominent skeptic, wrote publicly that the most reputable people in quantum hardware are now telling him a cryptographically relevant machine ought to be possible by around 2029.
The Coinbase paper itself is deliberately measured on timelines. But read alongside these three signals, its core warning is clear: preparation has lead times that already exceed the uncertainty in the threat window. An organization planning against 2035 and migrating on a 2035 schedule is not being conservative. It is assuming nothing changes between now and then. That assumption no longer holds.
The threat is not abstract. It sits on-chain today.
Roughly 6.9 million BTC are held in UTXOs whose public keys are visible on-chain in clear text. Approximately one million of those BTC are concentrated in eleven addresses. Every Ethereum slot aggregates attestations from hundreds of thousands of validators using BLS signatures — a primitive with no quantum-resistant equivalent at current production performance levels. Every major proof-of-stake chain that depends on aggregate or threshold signatures is in the same position. Solana, Algorand, Sui, Aptos, and the L2 ecosystem are each at different stages of acknowledging this. None has finished.
These are not migration problems in the conventional sense. They are redesign problems, and the research that would make them tractable migrations is still incomplete in several critical areas.
Hash-based and lattice-based signature schemes do not aggregate the way BLS does. Chains that depend on aggregate or threshold signing will require consensus-protocol changes, not just primitive swaps. Ethereum's current plan involves SNARK-based aggregation over hash-based signatures. Most other chains do not have a comparable plan documented and on the record. That gap has consequences for anyone building on or integrating with those chains.
Every chain will eventually face a binary choice: a flag day after which unmigrated assets are considered abandoned and removed, or a permanent population of quantum-vulnerable balances sitting on-chain as an increasingly attractive target. There is no stable third option. The Coinbase paper notes that market uncertainty on this question is already deterring investment, which means the cost of delay is not hypothetical. It is measurable today.
Wallets, custodians, and key-management systems will need to support whatever post-quantum scheme each chain selects. Most chains have not yet selected. A custodian or infrastructure provider planning against 2035 has time to wait for those decisions to settle. One planning against 2029 does not.
The Coinbase paper's practical recommendations are well-calibrated. For organizations carrying cryptographic risk, four actions are overdue:
At Horizen Labs, quantum-resistant cryptography is not a roadmap item. Our cryptography and engineering teams have been working through the implications of the post-quantum transition for some time, and that work is what underpins the practical guidance we offer.
The Quantum Threat Assessment (QTA) service that Horizen Labs offers to enterprise and institutional clients is a necessary first step that every organization needs to take. Its purpose is to deliver a high-level, strategic security assessment, identifying critical areas for immediate attention and defining clear next steps for quantum readiness. The goal is to give CISOs and security teams a clear picture of where they stand, before they have to make decisions under pressure, without requiring the time and resource commitment of a full cryptographic scan or CBOM analytics upfront.
The Coinbase paper, Google's accelerated deadline, and the Oratomic resource analysis are three separate signals pointing in the same direction. Organizations that are still planning against 2035 are operating on assumptions that the people closest to this problem no longer hold. The work of closing that gap is not research. It is engineering, governance, and honest accounting of where the risk actually lives.
If your organization has not yet run a cryptographic inventory or applied Mosca's theorem against a realistic threat timeline, the first step is understanding where your exposure is concentrated.
Learn how Horizen Labs approaches quantum-resistant security assessment and migration planning: https://horizenlabs.io/quantum-security
Are You Ready for the Post-Quantum Era?
Get a Free Quantum Threat AssessmentBLOG

The quantum threat isn't waiting for a sufficiently powerful computer to exist. It's already operational in the form of state-sponsored actors intercepting your encrypted data today, stockpiling it, and waiting for a quantum computer to finish the job.

An agent says it ran 16 security checks on your smart contract. Did it actually run all 16? Did it run any? Right now, there's no way to know.

Autonomous AI coding agents are powerful when you take the brakes off. On a blockchain engineer's machine, that also means the agent has access to private keys, deployment credentials, and API secrets for production systems. A single leak is irreversible. The recommended fix, Docker sandboxing, falls short in ways that actually matter in practice. We needed something that contained the blast radius without breaking the workflow. This is what we built.