Inside the Quantum Window
Why the people who could break Bitcoin aren't thinking about Bitcoin — and why that's the bad news.
(Note: This is the first part of a multi-part rabbit hole I went down that lead to the creation of a cookbook for a next generation viewpoint on cryptocurrency, central banks and the future of digital value)
I served as the inaugural Chief Innovation Officer of the FDIC. The job teaches you one thing the policy schools can’t: financial systems do not fail the way their operators are ready for. They fail in the corner you didn’t game out. The credit shock is the one you priced. The run is the one you didn’t.
I left that role for reasons I’ve written about elsewhere. The discipline I took with me was simple: go back to first principles, demand evidence that’s been challenged in public, be honest about what your data can and can’t tell you. It’s why I’ve publicly said CAMELS ratings need a serious refresh. In Q3 2023 I pointed that discipline at digital money and didn’t like what I found.
The shorthand for the project I started afterwards is “an L1 I’ve been building.” I’ll name it in post three. For now what matters is the question I started from, and why it sent me back to first principles for three years.
The question was simple and unkind: what would a digital monetary system have to look like to survive across cryptographic regime change and if a central bank were to get behind it (without going down the central bank digital currency route)?
What’s on the table
Bitcoin market cap: ~
$1.57T(Apr 2026)NIST FIPS 203 / 204 / 205 (post-quantum signatures and KEMs): finalized August 2024
The current best public CRQC estimates from the labs whose numbers I trust: a range, not a date. Center of the range, optimistic side, is uncomfortably close
“Q-Day” used in this series: the first day a cryptographically relevant quantum computer exists in private hands and is willing to use it
Working assumption in this series: the parties most likely to hold a CRQC first are not optimizing for Bitcoin’s market cap
❦ ❦ ❦
The problem
Bitcoin can’t survive cryptographic regime change. That’s not a slur, it’s a property. It’s the most-watched, least-upgradable cryptosystem in the world. Roughly a tenth of the supply sits in addresses whose public keys are already on chain in plaintext. The signing primitive — ECDSA over secp256k1 — is one of the things a working quantum computer breaks first. The protocol governance is, charitably, slow. Less charitably, it ships a hard fork roughly never. The process to do so would come at the last minute, with lots of hand wringing and cause significant market chaos. None of this is news to anyone in the room. None of it is fixed.
The objection, if you’ve spent any time around this conversation, is “we have years.” I don’t think that’s true anymore. And the reason isn’t a paper.
Here’s the part I want you to read precisely.
The parties capable of fielding a cryptographically relevant quantum computer first — whichever ones get there, in whichever order, on whichever timeline — are not optimizing for the market cap of Bitcoin. They are optimizing for sovereign-scale advantage. Encrypted diplomatic cable archives. Banking system interception. Adversary code that has to stay secret for forty years. Digital regime change. Weapons telemetry. The list is long and Bitcoin is not on the front page of it. Bitcoin is collateral.
That sounds like good news for a Bitcoin holder. It is not.
Three reasons.
One. Once a CRQC exists for any of those other reasons, the Bitcoin attack becomes cheap. The capital expenditure was made for someone else’s problem. Cracking the coins out of pre-2010 P2PK addresses is a side project on the same hardware. Cheap is relative — these are not laptop programs — but the marginal cost line, once the platform exists, is well inside the upside.
Two. Harvest-now-decrypt-later already applies. Every transaction graph, every public key, every Groth16 proof published to a public chain since inception is in the harvest. A patient adversary doesn’t need to attack the network the day the machine boots. They need to wait until the machine boots. Recent AI advancements have already proven this point.
Three. The people who do hold this capability, if anyone does, are not signaling. Operationally, they cannot. Once they signal, every adversary’s encrypted backlog gets airgapped or rotated. The default state of a working CRQC, if one already exists, is silence. “We’re not there yet” is consistent with both worlds — we are not there yet, and we are there and choosing not to say. If you bet on the announcement, you’re betting the wrong direction.
Put those three together honestly and “we have years” stops being a forecast. It becomes a hope. I am not willing to design a monetary system around a hope.
That’s the window. It might already be closed and we wouldn’t necessarily know.
The decision
The decision I made three years ago, and that the rest of this series unpacks, is the one most projects defer: treat post-quantum resilience as a property of the whole stack, not a future migration.
This is unpopular for a reason. PQ primitives are slower, larger, less battle-tested, and more annoying to integrate. They eat block space. They make wallets harder to write. They make every elegant cryptographic shortcut twice as hard. People put them off because the deadline is hypothetical, the cost is real, and the next-quarter incentives reward shipping today.
The trade looks different if you take seriously that the deadline is not hypothetical, and that if the wrong week arrives, every signature you ever produced is retroactively reversible. Which is to say: every commitment you ever made, every payment, every proof of compliance, every privacy guarantee. All of it back on the table, retroactively, at the speed of whoever is decrypting first.
You don’t migrate out of that. You design around it from the start.
Here is the honest version of how far that gets you, today, April 2026.
| Phase | Status (Apr 2026) | What it gives you | |—|—|—| | Phase 1 | Production | Groth16 for ZK, BLS for aggregation. Battle-tested. Performant. Not quantum-resistant. Acknowledged. | | Phase 2 | 12–18 months out | Hybrid. Hash-based commitments alongside the existing proof system. Buys integrity through the migration window. | | Phase 3 | The destination | STARK-based or lattice-based ZK end-to-end. Larger proofs. Slower verification. Quantum-resistant. |
I will not pretend Phase 3 is finished. It is not. The cookbook on sultanismyname.com lays out exactly which primitives are production-ready as of this writing and which are 12 to 18 months out. There is real work between here and there. Anyone telling you otherwise is selling something. Launching a L1 is a non-trivial process. This is the first in a series of steps to not only do that but also make it work in a modern regulatory construct AND to operate as a replacement to fiat currencies in a central bank, post Bretton Woods, context
What I will say is this. The architecture commits to it. The protocol does not have an ambiguous we’ll figure it out clause where the migration belongs. The migration is on the roadmap with a number next to it. That, structurally, is the difference.
What the decision touches
The thing I didn’t expect, three years ago, was how much else this single decision pulled in.
Once you take cryptographic regime change seriously, you can’t have a stability mechanism that depends on signatures being unforgeable forever. You have to design escalation rules that survive a primitive being broken. The rules have to be written down — in code, immutably — before the panic, because you cannot patch them during it. Which means the resolution waterfall has to be immutable. Which is the central-banking question. Which is the FDIC question, in different clothes.
Once you take it seriously, you can’t have privacy guarantees that decay when the proof system breaks. The privacy layer has to be designed for a proof system you will eventually swap out. Which forces compliance attestations onto the same migration path. Which is the regulatory-perimeter question.
Once you take it seriously, you can’t have an MEV story that depends on transaction ordering being tamper-proof under cryptographic assumptions you don’t trust across decades. So you build threshold-encrypted ordering with primitives chosen for the long arc.
Each of those is a post in this series. Each of those is a chapter in the cookbook. The thread connecting them is the one I started this post with: a digital monetary system has to fail well across cryptographic regime change, or it isn’t a digital monetary system. It’s a digital wager.
See also
This is post one of six.
Post 2 — Bagehot Was Right. Why every stablecoin failure is a failure of escalation, not of code. The five-layer stability regime, the bounded-dilution proof, why one specific number is the entire ballgame.
Post 3 — Make the Waterfall Immutable Or Don’t Bother. What the FDIC actually does, and what crypto refuses to import. The L1 gets a name in this post.
Post 4 — Privacy and Compliance Aren’t Enemies. The view-key model, ZK compliance attestations, and what regulators actually object to (it isn’t privacy).
Post 5 — The False Binaries. Five tradeoffs the industry treats as inviolable, plus a sixth — deal with quantum later — that has the same problem the others do.
Post 6 — Money Without a Master Key. Hand-off to the long-form cookbook on sultanismyname.com, including the open problems I’m still arguing with myself about.
Closer
I’m not selling a token in this series. There won’t be one to sell during the run of these posts and there isn’t an allocation to ask for at the end. If that changes I will tell you, in plain text, in the post where it changes, before the rest of the post.
Pick a recipe — even just the threat model in this post — and use it this week. If you run a stablecoin treasury, an exchange, a custody desk, a fund: the harvest-now-decrypt-later assumption is one your auditors should already be on. Print this post and hand it across the table. If your security review doesn’t have a post-quantum migration plan with a number next to it, you are running on hope.
Hope is not a forecast.
— Sultan