Google Just Set a 2029 Deadline. Bitcoin and Ethereum Aren't Ready

Yesterday, 25 March 2026, Google published a blog post setting an internal deadline of 2029 for completing its migration to post-quantum cryptography (PQC). The post, from VP of Security Engineering Heather Adkins and Senior Staff Cryptography Engineer Sophie Schmieg, is framed as both a corporate commitment and a signal to the rest of the industry. Google has adjusted its threat model to prioritise PQC for authentication services, and is already shipping PQC digital signatures via ML-DSA in Android 17.

The day before that, the Ethereum Foundation launched pq.ethereum.org, a dedicated hub consolidating over eight years of post-quantum research into a public roadmap. And Bitcoin’s BIP-360, the first formal quantum-resistance proposal to be merged into the official BIP repository, was merged in February. A third-party testnet implementation followed in March, but BIP-360 remains far from activation on Bitcoin itself.

Three ecosystems. Three migration efforts. Three very different starting positions. It is worth examining where each actually stands, and what happens if the timelines collide.

Table of Contents

Google: the luxury of centralisation

Google controls its own infrastructure. It can mandate certificate rotations, push firmware updates, and deploy PQC across Chrome, Cloud, and internal communications on its own schedule. When Google says 2029, it is setting a target it has the organisational authority to meet.

No consensus mechanism. No governance debates. No need to coordinate millions of independent node operators, wallet providers, and custodians. Google’s challenge is engineering at scale. A hard problem, but a fundamentally different one from the coordination problems facing decentralised networks.

The blog post references recent advances in quantum hardware, including Google’s own Willow chip, and falling resource estimates for cryptographic attacks. The subtext is clear: the window for comfortable migration is narrower than previously assumed.

Ethereum: structured governance, phased migration

The Ethereum Foundation’s approach is characteristically methodical. The new PQ hub outlines a multi-layer migration spanning execution, consensus, and data layers, delivered through a sequence of hard forks beginning with Glamsterdam (targeted H1 2026) with L1 protocol upgrades targeting 2029. The EF is explicit that there is no single fixed date, and that full execution-layer migration will take additional years beyond that.

The “Strawmap”, a living draft roadmap from the EF Architecture team, envisions seven incremental upgrades over about four years. At the consensus layer, the plan replaces BLS validator signatures with hash-based post-quantum alternatives (specifically leanXMSS). At the execution layer, the strategy leverages account abstraction to enable opt-in migration to quantum-safe authentication, avoiding a disruptive “flag day” where every wallet must switch at once.

That second point deserves emphasis. Ethereum’s account abstraction work, progressing through ERC-4337, EIP-7702, and now EIP-8141 (“Frame Transactions”), gives users a mechanism to upgrade their signature schemes without abandoning existing addresses. Native account abstraction at the protocol level means new post-quantum schemes can be deployed as smart contract validation logic, without requiring a fresh hard fork every time an algorithm changes. The Ethereum community calls this “cryptographic agility,” and it is arguably the network’s single greatest architectural advantage in this migration. If the PQC landscape shifts, if a lattice-based scheme is weakened, or a new candidate emerges, Ethereum’s structure can absorb that without a protocol-level crisis.

Ethereum’s quantum exposure is also materially smaller than Bitcoin’s. The Foundation estimates roughly 0.1% of ETH supply is associated with address formats where public keys are permanently exposed on-chain. That makes the urgency of user-level migration considerably lower.

The core risk for Ethereum is execution, not design. Seven hard forks in four years demands close coordination across more than ten client teams. Ethereum timelines have slipped before (the Merge was years late, Dencun saw delays) and any slippage here pushes the tail end of the migration closer to the threat window. But the governance infrastructure exists, the research is mature, and working code is already being tested on weekly interoperability devnets. Of the two blockchains, Ethereum is in a meaningfully stronger position.

Bitcoin: decentralised governance, constrained throughput

Bitcoin faces a fundamentally different challenge, and a harder one.

BIP-360, co-authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, was merged into the official BIP repository on 11 February 2026. It introduces Pay-to-Merkle-Root (P2MR), a new output type that functions similarly to Taproot but removes the quantum-vulnerable key-path spend. This is the first formal step toward quantum resistance on Bitcoin’s base layer.

But it is explicitly a partial measure. BIP-360 addresses long-range attacks, scenarios where an attacker has extended time to derive a private key from an exposed public key, by hiding the public key behind a Merkle root commitment. It does not protect against short-range attacks, where a quantum adversary extracts a private key from a public key exposed in the mempool during the roughly ten-minute window before transaction confirmation. Protecting against short-range attacks requires a subsequent soft fork introducing post-quantum signature algorithms (such as ML-DSA or SPHINCS+) as opcodes in Bitcoin tapscript. That is a significantly larger and more complex change.

Then there is the throughput problem, which I think gets underappreciated.

Bitcoin processes approximately 3–10 transactions per second. In my own research on Bitcoin’s UTXO migration, I calculated a strict lower bound of 76 days of continuous, dedicated block space to migrate all ~187 million UTXOs to quantum-safe outputs, and that assumes every single block is used exclusively for migration with zero regular transactions. At a more realistic 25% bandwidth allocation, that extends to approximately 305 days. These are non-tight lower bounds. The actual migration, in practice, would take considerably longer.

Ethan Heilman has estimated that a complete quantum-safe upgrade would take approximately seven years under optimistic assumptions: two and a half years for BIP development, code review, and testing; six months for soft fork activation; and then several more years for wallets, custodians, Lightning Network nodes, and treasury management software to catch up. His estimate for 90% ecosystem adoption is five years post-activation. As he put it: “Seven years total, but I’m just spitballing here. No one actually knows.”

That places full Bitcoin quantum resistance somewhere around 2033–2034, assuming work starts in earnest now.

The exposure is also substantially larger than Ethereum’s. Approximately 1.7 million BTC, roughly 8–9% of total supply, sits in legacy P2PK addresses where public keys are permanently visible on-chain. These are overwhelmingly dormant Satoshi-era coins. Broader estimates that include address reuse across P2PKH, P2WPKH, and Taproot outputs place total quantum-exposed supply somewhere in the range of 20–25% (the exact figure depends on how you define “exposed,” and estimates from Chaincode Labs, Deloitte, CoinShares, and Project Eleven vary considerably). Roughly 1.6 million BTC is believed to be in permanently lost wallets. Those coins can never be migrated, full stop. That creates a permanent quantum vulnerability that no software upgrade can fix without contentious governance intervention.

And governance is where things get truly difficult. Unlike Ethereum, Bitcoin has no foundation, no formal roadmap, and no mechanism to mandate upgrades. Consensus changes require broad community agreement through a process that has historically moved slowly and cautiously, by design. Proposals to freeze or burn vulnerable UTXOs after a migration deadline (such as QRAMP) remain deeply controversial. They would represent an unprecedented intervention in Bitcoin’s property model, and the community is nowhere near consensus on whether that is acceptable.

The 2029 scenario

So what happens if a cryptographically relevant quantum computer (CRQC) arrives in 2029? The outcomes diverge sharply.

Google would likely be substantially migrated. Centralised infrastructure plus an aggressive timeline gives it a realistic path to completion by that date.

Ethereum would be mid-migration. Core L1 protocol upgrades could plausibly be complete, but full execution-layer migration, the process of hundreds of millions of accounts actually transitioning to quantum-safe authentication, would still be underway. The account abstraction pathway means early adopters and anyone paying attention would be protected, but the long tail of wallets and smart contracts would remain exposed.

Bitcoin would be in the early stages at best. BIP-360 might be activated, providing a quantum-hardened output type for new transactions. But the vast majority of existing UTXOs would still be secured by ECDSA. The throughput bottleneck means that even with full community alignment, the physical migration of funds would have barely begun. Billions of dollars in exposed P2PK and reused-address UTXOs would be vulnerable, and the ~1.6 million BTC in lost wallets would be entirely unprotectable.

Is 2029 actually realistic for Q-Day?

This is where I move from stating facts to offering an opinion. Google’s 2029 target is a migration completion date, not a prediction of Q-Day. But migration deadlines are not set in a vacuum. You set a completion date based on when you believe the threat could materialise. If Google believes its infrastructure needs to be fully migrated by 2029, the implication is that it considers a CRQC plausible not long after.

Recent advances have meaningfully compressed resource estimates for cryptographically relevant quantum computers. In May 2025, Google Quantum AI’s Craig Gidney estimated that factoring RSA-2048 would require roughly one million physical qubits. By February 2026, Iceberg Quantum’s Pinnacle Architecture, using quantum LDPC codes rather than conventional surface codes, brought that estimate down to fewer than 100,000 physical qubits under standard hardware assumptions (10⁻³ error rate, 1 μs code cycle time). Each order-of-magnitude reduction in the qubit requirement has arrived faster than the last.

Hardware roadmaps from IonQ, PsiQuantum, Diraq, and others project systems at the 100,000-physical-qubit scale within three to five years. Scott Aaronson, founding director of the Quantum Information Center at UT Austin, said in late 2025 that fault-tolerant quantum computing running Shor’s algorithm is a “live possibility” before the next US presidential election in November 2028. Caltech president Thomas Rosenbaum has spoken publicly about five to seven years to a functioning fault-tolerant machine.

These are serious people making serious projections. A 2029 Q-Day is not impossible.

But it is not, in my assessment, likely.

Having the qubits is necessary but not sufficient. Running Shor’s algorithm against a cryptographic key is not a single operation. It requires sustained, fault-tolerant computation over an extended period. Analysis of the Pinnacle Architecture’s resource estimates suggests that factoring RSA-2048 with ~98,000 superconducting qubits would require approximately one month of continuous computation. For slower modalities like trapped ions, qubit requirements scale to between 1.3 million and 58 million depending on achievable fidelities. Maintaining coherence across 100,000 physical qubits for weeks, with real-time QLDPC decoding at microsecond timescales, is an engineering challenge of a qualitatively different order from building the qubits themselves.

It is also worth noting that the Pinnacle benchmarks target RSA-2048. Bitcoin and Ethereum use secp256k1, a 256-bit elliptic curve. Shor’s algorithm cares primarily about key size, and as Aaronson has observed, elliptic curve cryptography is likely to fall to quantum computers somewhat before RSA-2048, not after. So while the Pinnacle paper is benchmarking a harder problem, the blockchain-relevant threshold may actually be lower.

As Gidney himself noted in response to the Pinnacle paper: the mileage depends entirely on how much you are willing to tolerate the additional demands being made of the hypothetical hardware. The qubits get fewer; the engineering gets harder.

And the Pinnacle Architecture remains a preprint: not yet peer-reviewed, validated through simulation rather than experiment, and reliant on hardware assumptions (particularly around non-local qubit connectivity) that no existing system satisfies.

Most engineering roadmaps, including the Ethereum Foundation’s own FAQ, place cryptographic relevance in the early-to-mid 2030s. That is the median expectation, not the tail risk.

But here is the point that actually matters: cryptographic security is not defined by median expectations. It is defined by the worst credible case. If a single ECDSA private key can be derived from its public key by a quantum computer, even once, even slowly, even in a laboratory setting, then the mathematical guarantee underpinning every elliptic curve signature on every blockchain is falsified. The security model does not degrade gracefully. One demonstrated key recovery means every exposed key should be considered compromised.

So the real question is not whether 2029 is the most probable year for Q-Day. It probably is not. The real question is whether the blockchain ecosystem can afford to behave as though 2029 is impossible.

Google has answered that question for itself. Ethereum is answering it with engineering. Bitcoin is still debating the first step.