Quantum Computers Won't Break Your Wallet Tomorrow. Here's Why You Should Still Care Today

The quantum threat to blockchain is not a single event arriving on a known date. It is two separate clocks running simultaneously, and most engineers building wallet infrastructure are only watching one of them.

On March 30, 2026, a team at Google Quantum AI published a paper that should have reshaped crypto security conversations for months. The paper co-authored by Ryan Babbush, Craig Gidney, Justin Drake from the Ethereum Foundation, Dan Boneh from Stanford, and colleagues presented optimized quantum circuits for Shor's algorithm targeting the 256-bit elliptic curve discrete logarithm problem. That is the specific cryptographic primitive securing every Bitcoin and Ethereum wallet signature. Their finding: Shor's algorithm for this problem can execute with either fewer than 1,200 logical qubits and 90 million Toffoli gates, or fewer than 1,450 logical qubits and 70 million Toffoli gates. On a superconducting architecture running with physical error rates of 10⁻³, those circuits execute in minutes.

Previous estimates sat in the range of several thousand logical qubits for similar problems. This paper found the sweet spot in spacetime volume the product of logical qubit count and gate count that determines actual physical resource overhead that prior work had missed. The result is roughly a 10x reduction in the combined computational resources required.

I want to be precise about one thing the paper actually did, because precision is what most of the coverage missed. The authors did not publish the attack circuits. In the interest of responsible disclosure, they used a zero-knowledge proof to validate the results without disclosing attack vectors. That means the claim is verifiable in the cryptographic sense without being reproducible in the scientific sense: you can confirm the proof checks out, but you cannot inspect the actual circuit or run it independently outside Google. That is the correct place to direct technical skepticism.

Here is what that skepticism does not change: the engineering decisions wallet builders need to make this decade are identical whether or not this specific estimate holds up to independent scrutiny.

The Two-Clock Problem

The reason "quantum computers will eventually break your wallet" is an unhelpful framing is that it makes the threat sound like a single future event. The actual problem has two distinct components with different time horizons and different engineering implications. Conflating them produces wrong decisions in both directions.

The first component is Q-day the point at which a cryptographically relevant quantum computer exists that can run Shor's algorithm against real elliptic curve keys at scale. Nothing available today can do that. Current quantum hardware operates with thousands of noisy physical qubits. The engineering distance from there to the sub-million-qubit threshold the Google paper describes is still enormous. Estimates for when that gap closes keep compressing, but Q-day is not a date you can put on a calendar yet.

The second component is the harvest-now-decrypt-later problem, and it is already active. An attacker does not need a quantum computer today to exploit it. They need only to record signed transactions and public keys now, then decrypt that data once hardware matures. For ordinary web traffic, this matters but the exposure is bounded: most web sessions are ephemeral, and stored encrypted traffic becomes less valuable over time. For blockchain data, the situation is structurally different. The entire transaction history is public, permanently stored, and available to anyone. Every signed transaction that has ever been broadcast on Ethereum has exposed a public key that will remain permanently accessible to any future attacker with sufficient compute.

This means the exposure window for any given address opens the first time a signed transaction from it appears on-chain, and it does not close unless funds are actively moved to a quantum-resistant address before Q-day arrives.

These two clocks run independently. Q-day could be fifteen years away and the harvest-now-decrypt-later problem would still be active today.

Three Papers in Three Months

The March 2026 Google paper was the third significant resource-estimate reduction in roughly twelve months, and it is worth naming all three because the pattern they form is the actual signal.

Craig Gidney published analysis in 2025 showing that fewer than one million noisy physical qubits could factor a 2048-bit RSA integer in under a week. The prior leading estimate required millions of physical qubits. The reduction was entirely algorithmic better circuit compilation, better error correction architecture not driven by hardware progress.

Iceberg Quantum followed in February 2026 with a quantum LDPC-code architecture paper claiming RSA-2048 could be targeted with under 100,000 physical qubits, with hardware partners reportedly targeting that scale within three to five years.

Then came the Google paper targeting elliptic curves specifically, with the 10x reduction in spacetime volume noted above.

What these three papers have in common is more important than the individual numbers: none of the compression came from quantum hardware getting dramatically better. All of it came from better algorithms, better error correction schemes, and better circuit construction. That matters because it implies the resource floor keeps dropping even without hardware breakthroughs. The Google paper itself notes the principle directly: in cryptography, attacks always get better.

Dan Boneh, who co-authored the March 2026 Google paper, said something in a May interview that deserves to sit alongside the technical headline: "A hasty transition to post quantum, in my mind, is more likely to cause a catastrophic bug than we'll be attacked by a quantum computer." His fuller framing was "don't panic, but don't ignore." Both halves of that statement are precise and intentional. The leading researcher contributing to evidence that the timeline is shorter than expected is also the one most explicitly warning that rushing the response carries its own catastrophic risk. Post-quantum cryptographic algorithms are newer, have more complex implementations, and carry substantially higher risk of subtle implementation bugs than the elliptic curve systems they would replace.

“A hasty transition to post quantum, in my mind, is more likely to cause a catastrophic bug than we'll be attacked by a quantum computer.”
Dan Boneh

What the On-Spend Attack Actually Means

The Google paper introduced a specific attack mechanism that had not previously appeared clearly in public estimates: an on-spend attack against transactions during the confirmation window.

When you broadcast a transaction on Ethereum or Bitcoin, your public key is exposed in the mempool before the transaction is included in a block. Under normal conditions, this window is irrelevant because deriving the private key from the public key is computationally infeasible. On a network where a cryptographically relevant quantum computer exists, the window becomes the attack surface. An attacker intercepts the broadcast public key, derives the private key using Shor's algorithm, constructs a fraudulent transaction redirecting the funds to their own address, and races to get it confirmed first.

The paper's resource estimates are calibrated specifically for this scenario: minutes of execution time on a superconducting architecture is the relevant benchmark for whether the attack completes within the ten-minute Bitcoin block time or Ethereum's equivalent window.

Ethereum's address derivation is slightly different from Bitcoin's. Ethereum derives address from the hash of the public key, which means the public key is not necessarily visible until a transaction is signed. That provides partial protection: addresses that have never signed a transaction expose only their public key hash, not the key itself. But for any address that has already sent transactions, the public key is on-chain permanently. For long-running agent identity systems, treasury accounts, or any address with significant transaction history, this distinction provides no practical protection.

Where Ethereum Actually Stands

The Ethereum Foundation's response is worth reading from the primary source rather than through secondary coverage. The ethereum.org post-quantum page states plainly: "Your funds are safe. No quantum computer today can break Ethereum's cryptography." It also states that the milestone targets are planning milestones, not guaranteed commitments, and that names and ordering may change.

What is concrete is the following. NIST finalized its first post-quantum cryptographic standards in August 2024: ML-KEM (key encapsulation), ML-DSA (lattice-based digital signatures), and SLH-DSA (hash-based signatures, the standardized successor to SPHINCS+). The Ethereum post-quantum roadmap is explicitly built around these standards.

The Ethereum Foundation's Protocol cluster published its current priorities on September 7, 2026, stating that full quantum resistance across execution, consensus, and data layers by December 2029 is the "north star." The September post is specific about the upgrade sequence:

I* a post-quantum public key registry arrives here, establishing the protocol foundation for account registration using post-quantum keys.

J* the minimum viable post-quantum milestone, covering a post-quantum consensus heartbeat, leanDA sampling on the data layer, and leanSPHINCS transactions on the execution layer. This is designed as a temporary safeguard that could keep Ethereum operating through Q-day with reduced guarantees.

L* full post-quantum readiness across all three protocol layers: execution, consensus, and data.

Reaching L* by December 2029 from Glamsterdam's projected December 2026 mainnet requires an average fork cadence of 7.2 months. The EF Protocol blog described this as aggressive and leaving little room for error. There is a contingency path: a 12-month cadence from Glamsterdam can reach the J* minimum viable milestone by December 2029, even if L* slips.

What the Ethereum milestones mean

The active implementation work is not just roadmap planning. More than ten client teams are participating in weekly post-quantum interoperability devnets. Open-source implementations leanXMSS, leanVM, leanSig, leanMultisig are all available under the leanEthereum GitHub organization. The Ethereum Foundation's Poseidon Prize offers $1 million for improvements to hash-based cryptographic primitives. This is engineering work in progress, not theoretical planning.

Ethereum's consensus layer uses BLS signatures to aggregate votes from hundreds of thousands of validators. BLS relies on elliptic curve pairings, which a quantum computer running Shor's algorithm could break. The replacement for BLS on the consensus layer is leanXMSS, a hash-based signature scheme. The leanVM is a minimal zkVM that aggregates the larger quantum-safe signatures efficiently, addressing the practical concern that hash-based signatures are substantially larger than elliptic curve signatures.

The Account Abstraction Migration Path

This is the section that most general-audience articles miss, because it requires understanding both the post-quantum landscape and the smart account architecture simultaneously.

A conventional Ethereum externally owned account is cryptographically tied to its key pair at the protocol level. The address is derived from the key. Migrating to a post-quantum signature scheme means creating a new account and moving all assets, because there is no in-place upgrade path for a standard EOA. Every active address has to move, and that migration transaction itself temporarily exposes the public key.

A smart account built on ERC-4337 is structurally different. The signature verification logic lives in the account's own code, not as a protocol-level hardcoded assumption. The account validates signatures by calling its own verification module, and that module is updatable. A smart account can therefore switch its signature scheme from ECDSA to SLH-DSA or ML-DSA without abandoning its address, its history, or any on-chain reputation accumulated under that address. The identity survives the cryptographic migration.

ERC-7579 modular accounts extend this further by standardizing the module interface, meaning a post-quantum signature module built once can be dropped into any ERC-7579-compliant account. ERC-7484 module registries provide the auditing and security assurance layer: a post-quantum signature module registered through ERC-7484 carries a security attestation rather than being an ad-hoc implementation.

EIP-7702 adds another migration option: it lets an EOA delegate execution to a smart contract implementation, which could include a post-quantum verification module, without requiring a full account migration. This is relevant for users who have not already moved to smart accounts and need a bridge.

EIP-8141, which introduces native account abstraction and is being considered for the Hegotá upgrade, would make signature agility a first-class protocol feature rather than a smart account workaround. Under EIP-8141, individual accounts can choose their own signature verification scheme at the protocol level, meaning a post-quantum migration would not require every user to be on a smart account first.

What Modular Signature Verification Looks Like

interface ISignatureValidator {
    function validateSignature(
        bytes32 digest,
        bytes calldata signature
    ) external view returns (bool);
}

contract SmartAccount {
    ISignatureValidator public validator;

    function validate(
        bytes32 digest,
        bytes calldata signature
    ) external view returns (bool) {
        // Today: ECDSA
        // Future: SLH-DSA / ML-DSA
        return validator.validateSignature(digest, signature);
    }
}

The important idea is not the contract itself. The account delegates signature verification to a module. Today that module could verify ECDSA. Later, it could be replaced with a post-quantum signature verifier without changing the account's address.

The practical gap is this: the architecture for post-quantum migration exists. What does not yet exist is a production-ready, audited, gas-efficient SLH-DSA or ML-DSA verification module for ERC-7579 accounts. That module is what turns the architectural possibility into something a wallet team can actually ship.

Understanding the Algorithms: What Matters for Wallet Builders

I have covered the mathematics of both SLH-DSA and lattice-based cryptography in separate articles, so this section focuses on the practical tradeoffs that matter for wallet infrastructure specifically.

SLH-DSA (the standardized SPHINCS+ successor) is a hash-based signature scheme. Its security depends on the hardness of finding hash preimages and collisions, which Grover's algorithm attacks quadratically rather than exponentially. Moving to larger hash output sizes SHA-384 or SHA-512 rather than SHA-256 provides adequate post-quantum security margins. SLH-DSA has the most conservative security story of any post-quantum candidate: it depends on properties of hash functions that have been studied for decades, with no known efficient quantum attack. The tradeoff is signature size. SLH-DSA signatures range from roughly 8 KB to 50 KB depending on parameter set selection, compared to roughly 65 bytes for ECDSA. That size difference matters for gas costs when verifying signatures on-chain, and it is why leanXMSS and leanVM together are needed on Ethereum's consensus layer: the signatures are large enough that you need an efficient aggregation mechanism.

By late 2026, Boneh had updated his preferred migration path to hash-based schemes specifically, citing the constraints of existing blockchain infrastructure. He had previously supported lattice-based solutions, but shifted position toward SLH-DSA as the more realistic near-term path given the implementation complexity of lattice schemes and the higher auditing burden they carry.

ML-DSA (lattice-based, standardized from CRYSTALS-Dilithium) produces substantially smaller signatures, typically under 3 KB, with faster signing and verification than SLH-DSA. Its security relies on the hardness of the Module Learning With Errors problem. The concern with ML-DSA is not its current security posture but its relative maturity: lattice cryptography has been studied seriously for roughly fifteen years compared to hash functions' much longer security track record. Implementation complexity is also higher, which connects directly to Boneh's warning. A flawed ML-DSA implementation is more likely than a flawed SLH-DSA implementation, because the underlying mathematics is harder to implement correctly.

For wallet builders making decisions now, the practical guidance is to design your signature verification as a swappable module and let the audited implementation landscape mature before committing to either scheme specifically. The architecture decision is more urgent than the algorithm selection.

The practical tradeoff

The Harvest Problem in Concrete Terms

The harvest-now-decrypt-later problem becomes concrete when you think about specific categories of addresses rather than "wallets" in the abstract.

Any address that has sent a transaction has its public key permanently on-chain. For ordinary user wallets with occasional activity, the exposure is the historical balance and transaction history if Q-day arrives while funds remain at that address. The fix is straightforward in principle: move to a quantum-resistant address before Q-day, and do so far enough in advance that the migration transaction does not complete during Q-day itself.

For agent identity systems like ERC-8004, the exposure is structurally worse. An agent identity accumulates a signed history over months or years of continuous operation. Every signed attestation, every authorized transaction, every recorded reputation event is a data point. If the underlying signature scheme is ECDSA, that entire history becomes retroactively attackable once the hardware exists. The damage is not just financial: a successful forgery over an agent's historical identity record does not merely steal funds. It allows impersonation of the agent's entire reputation history. The trust infrastructure built on that identity collapses, and unlike a wallet balance it cannot be moved to a new address without breaking continuity with everything that referenced the old one.

This is why I have argued separately that agent identity registries need to be built quantum-resistant from the start. The cost of doing this correctly during initial design is low. The cost of retrofitting it after millions of agents have accumulated reputation histories under ECDSA-signed identities is much higher, and there is no clean migration path that preserves both continuity and security.

What to Actually Do Now

None of this is an argument for dropping everything and rearchitecting this month. The threat is real, but it is not imminent. The standards are finalized but the implementations are not yet mature. Boneh said it precisely: a hasty migration is more likely to cause a catastrophic bug than the quantum threat. Both halves of that sentence are true.

The practical version of post-quantum preparedness for wallet infrastructure builders looks like architectural decisions made now rather than production deployments made now.

Quantum Readiness: Do This, Not That

Design signature verification as a swappable module. If you are building on ERC-4337 or ERC-7579, your verification module should be structured so it can be replaced without migrating the account address. This costs almost nothing to get right during initial development and is extremely expensive to retrofit after deployment. ERC-7484 module registries provide the framework for doing this with auditable security boundaries.

Track EIP-8141. If signature agility lands at the protocol level in Hegotá, the architecture for per-account signature scheme selection becomes a first-class protocol feature rather than a workaround. The proposal is actively being evaluated for Hegotá. Watch AllCoreDevs notes for whether it makes the final cut.

Understand the sequencing. The Ethereum post-quantum roadmap is now specific. The public key registry at I* is the foundation. The minimum viable post-quantum layer at J* includes leanSPHINCS transactions on the execution layer. L* delivers full cross-layer resistance. Building against that sequence tells you which layer to target first rather than trying to anticipate the complete migration in one design pass.

Do not confuse algorithm selection with architectural readiness. The algorithm debate between SLH-DSA and ML-DSA will continue for some time. The architectural question, whether your account can upgrade its signature scheme at all, is more immediately actionable and more important to get right now.

Monitor algorithmic progress, not just hardware news. The three papers from 2025 to 2026 all reduced resource estimates through algorithms, not hardware. If that trend continues, the timeline compresses faster than hardware progress alone would suggest. The right signal to watch is not "when does quantum hardware reach X qubits" but "what is the current best estimate of spacetime volume for ECDLP-256."

The Honest Version

There is a version of this topic that ends with "quantum computers are coming, be afraid." Another ends with "decades away, ignore it for now." Both produce bad engineering decisions, just in opposite directions.

The accurate version is more boring and more useful. The exposure window is already open for any address that has signed a transaction. The standards to close it were finalized in 2024. The architecture that makes closure possible without a disruptive migration, smart accounts with swappable signature modules, is already being built. Ethereum's Protocol cluster published a specific, sequenced roadmap with December 2029 as the stated target, explicitly calling it a planning milestone and acknowledging that the cadence required is aggressive. NIST anticipates deprecating ECDSA by 2030 and disallowing it entirely by 2035. Google, Cloudflare, and Microsoft have independently set 2029 as their internal PQC migration target.

The work left is sequencing, auditing, and disciplined implementation, not invention.

The goal is not to predict Q-day. The goal is to make the account ready for cryptographic change before Q-day arrives.

That is a less alarming headline than either extreme, and it is also the one that is actually true.