Stop Reusing Addresses. Google's New Quantum Disclosure Has a Free Mitigation Hiding Inside It.

Google Research just published a whitepaper estimating that future quantum computers could break the elliptic curve cryptography behind most cryptocurrencies with fewer than 1,450 logical qubits, under 500,000 physical qubits, and runtimes measured in minutes. That is roughly a 20-fold reduction in physical qubits versus prior estimates. The headline is alarming. The deployable mitigation sitting in the same post is almost free, and almost nobody is talking about it. Per Google Research, the short-term recommendation is straightforward: refrain from exposing or reusing vulnerable wallet addresses. That guidance costs nothing to implement today, and it buys real time.

What Google Actually Published, in Plain English

The May 2026 post is authored by Ryan Babbush, Director of Research, Quantum Algorithms, and Hartmut Neven, VP of Engineering, Google Quantum AI. They lay out updated resource estimates for breaking ECDLP-256, the elliptic curve problem behind most blockchain signature schemes. The two compiled circuits they describe need fewer than 1,200 and 1,450 logical qubits respectively, with Toffoli gate counts of 90 million and 70 million, fewer than 500,000 physical qubits, and runtimes in the minutes range. That is an order-of-magnitude tightening from where the industry was two years ago.

Babbush and Neven do not just publish numbers. They also publish a method. To prove their resource estimates are credible without handing every adversary a usable attack circuit, they wrap the supporting math in a zero-knowledge proof. Quoting the post directly: "we substantiate our resource estimates without sharing the underlying quantum circuits by publishing a state-of-the-art cryptographic construction called a 'zero-knowledge proof', which allows third parties to verify our claims without us leaking sensitive attack details." That is a useful disclosure precedent for the rest of the industry to copy.

The post lists four recommendations for the crypto community. Transition to post-quantum cryptography. Refrain from exposing vulnerable wallet addresses. Refrain from reusing vulnerable wallet addresses. Consider policy options for abandoned coins. We covered the protocol-roadmap angle in detail when the earlier estimates landed in April's piece on Google's quantum numbers. Tonight is about the second and third recommendations, which most wallets and exchanges can act on this quarter.

Why Address Reuse Is the Cheap Mitigation Almost Nobody Is Deploying

The mechanics matter, so let me make them concrete. Most blockchains use ECDSA or a related signature scheme over a 256-bit elliptic curve. The wallet address you publish is usually a hash of your public key, not the public key itself. The public key is only revealed when you spend, because the signature publishes the key alongside the proof of ownership. As long as the public key stays hashed, even a quantum adversary has to invert the hash before they can attack the curve. Inverting a modern hash with a quantum computer is much, much harder than running Shor's algorithm on an exposed elliptic-curve public key.

That asymmetry is the whole basis of the mitigation. If you spend from an address and never use it again, your public key is only exposed for the brief window of one transaction. Any adversary who wants to harvest your funds has to run Shor's algorithm against your specific exposed key before that transaction confirms. Today that is impossible. In a decade it might be expensive but possible. Reusing the address turns that one-shot exposure into a permanent target.

This is not a new insight. Bitcoin Core developers have been recommending one-time use addresses for years. What is new is that Google's published resource estimates make the timeline concrete enough that exchanges and wallet vendors can no longer treat this as a theoretical hygiene tip. It is the cheapest piece of harvest-now-decrypt-later defense available. Pair it with the longer protocol-level migrations we walked through in the post-quantum readiness checklist for L1 and L2 builders, and you have a layered defense that costs almost nothing in the short term.

Who Has the Most Address Reuse Exposure Today

If you are designing security for a real organization, you want to know where the concentration risk lives. Three categories stand out.

1. 1. Centralized exchange hot and cold wallets. Exchanges typically aggregate deposits into a small set of well-known addresses, then sweep periodically. Those aggregation addresses are reused thousands of times and their public keys are permanently exposed onchain. A single quantum break against one major exchange's cold address could move billions.
2. 2. Treasury wallets for foundations, DAOs, and DeFi protocols. Many treasuries publish their primary address publicly for transparency, then transact from it for years. The good intention defeats the mitigation. The public key is exposed and stays exposed.
3. 3. Smart contract deployer keys. Many production contracts are deployed by an EOA whose public key is in the deployment transaction and whose address is referenced in every subsequent admin action. Rotating those keys is operationally painful, so teams put it off. That deferred rotation is exactly the exposure vector Google is flagging. The same hygiene we recommend in the smart contract audit checklist should now include deployer key rotation as a first-class item.

The pattern in all three cases is the same. Operational convenience leads to address reuse. Address reuse leads to permanent public key exposure. Permanent exposure leads to harvest-now-decrypt-later risk. Breaking the first link in that chain is mostly an engineering effort, not a research effort.

What Wallets and Exchanges Should Ship in Q2 2026

If you operate a wallet or exchange, here is the minimum bar to clear before the next disclosure cycle. Decrypt's recent coverage of the wallet quantum-proofing race shows custody providers are already moving on the multi-year version of this problem with MPC and NIST-selected schemes. The shorter-term hygiene work is what most teams have not shipped yet.

• Make address reuse opt-in, not the default. Most wallets already derive fresh receiving addresses on demand. What they do not do is push users toward fresh addresses for outbound transactions. Add a default behavior that warns when a user is about to spend from an address whose public key has already been exposed.
• Publish a deployer-key rotation policy. If you run protocol-level contracts, document how often you rotate deployer EOAs and which contracts have been re-deployed under fresh keys in the last 12 months. Make this part of your security disclosures, not buried in an internal runbook.
• Treat exchange aggregation addresses as critical infrastructure. If your cold storage has had the same address since 2021, that address has years of accumulated public-key exposure. Plan a migration to a multi-address sweep model with periodic rotation, even before mainnet PQC signatures land.
• Adopt hybrid signature support where the chain allows it. If you are on a chain with a hybrid ECDSA + PQC signature option in beta, opt in for treasury and operator keys first. The performance overhead is real but bounded, and your highest-value keys are the ones worth slowing down.

The Zero-Knowledge Disclosure Precedent Matters More Than the Numbers

Most coverage of the Google post focused on the qubit count. The more durable contribution is the disclosure mechanic. Babbush and Neven faced a classic responsible-disclosure problem. Their resource estimates are credible only if other researchers can verify them. But the underlying quantum circuits, if released, are roughly equivalent to an attack manual. Their solution was to publish a zero-knowledge proof that demonstrates the estimates are accurate without revealing the circuit. Third parties can verify the math. Adversaries cannot use the math to attack.

This is exactly the disclosure pattern the rest of the cryptography community should standardize. Every research team that finds a sharper attack on ECC, lattice schemes, or hash-based signatures has the same problem Google had. Most teams default to delaying publication or publishing partial details. Both choices have costs. A ZK-backed disclosure splits the difference cleanly. We have written about how the same primitive enables post-quantum auditable privacy for banks and Web3 platforms. The disclosure use case is the same machinery, pointed at a different problem.

Expect more groups to copy this pattern. If your security team consumes vulnerability disclosures, build the workflow to verify ZK-backed proofs alongside conventional CVE reporting. It will not be the last time this happens.

Why This Lands Hardest on the Agentic Payments Stack

The same week the Google paper landed, AWS previewed Amazon Bedrock AgentCore Payments, built with Coinbase and Stripe, with USDC settling on Base and Solana. MEXC's writeup of the preview describes AI agents purchasing web content and APIs through metered USDC microtransactions. That product category multiplies every concern in this post. Agent wallets transact constantly. They reuse addresses by default. Their public keys are exposed across thousands of small transactions, not one big one. We covered the L1 design implications in the piece on agentic payments and crypto rails and in the multi-chain stablecoin settlement rails analysis.

If you are designing an agent payments runtime today, address rotation is not an optional feature. It is the difference between a system that ages gracefully and a system that bleeds funds the day a sufficiently large quantum machine arrives. The agent identity work we walked through in the AI agent identity and post-quantum signatures piece gives you the credential side of this. Address rotation gives you the cryptographic-key side.

Where Autheo Fits in the Layered Defense

Autheo treats post-quantum security as a base-layer property, not a future feature. The chain's signature scheme accommodates NIST-selected algorithms including ML-DSA and Falcon, and identity is a first-class object rather than a wallet address layered with off-chain attestations. We covered the broader design in the complete Autheo guide and the introductory piece on post-quantum cryptography for blockchains. The point worth emphasizing here is that operational mitigations like address rotation are necessary even on a PQC-capable chain. The two layers complement each other.

The same logic applies to token utility. THEO's demand model is not driven by speculative governance flows but by measurable consumption of compute, storage, identity, and inference, all of which scale with agent traffic. We mapped the six demand vectors in the THEO token utility piece. When you stack address hygiene, PQC signatures, machine identity, and metered utility together, you get a chain whose properties actually compose. That is the bar to aim for.

Identity Is the Other Lever, and It Compounds With Address Hygiene

Address rotation is a key-hygiene practice. Identity is the durable property that survives the rotation. If your wallet address changes every transaction, you still need a way for counterparties and regulators to know they are dealing with the same principal. That is the self-sovereign identity story, and we have argued before that the quiet shift toward self-sovereign ID is exactly the primitive that makes aggressive address rotation viable. Without portable identity, every fresh address looks like a new entity. With it, address rotation becomes invisible to the user and the counterparty while still buying real cryptographic safety.

Combine the two and the operational story gets simple. Use a stable, verifiable identity for the principal. Use fresh keys for every transaction. Rotate before reuse, not after exposure. Anchor the whole stack on a chain whose signature scheme can absorb the post-quantum transition without forcing a wholesale migration.

Key Takeaways

• Google's May 2026 whitepaper estimates ECDLP-256 can be broken with under 1,450 logical qubits, fewer than 500,000 physical qubits, and minutes of runtime. That is roughly a 20-fold physical qubit reduction versus prior estimates.
• The same post quietly recommends refraining from exposing or reusing vulnerable wallet addresses. That is a free, deployable mitigation that buys time before mainnet PQC migrations.
• Exchanges, foundation treasuries, and smart contract deployer keys carry the most reuse exposure today. They are the highest-priority targets for rotation.
• Babbush and Neven used a zero-knowledge proof to substantiate their estimates without releasing the attack circuit. Other research teams should copy this disclosure pattern.
• Agentic payments stacks like AWS Bedrock AgentCore Payments amplify the reuse problem because agent wallets transact constantly. Address rotation has to be built in from day one.
• Pair address rotation with self-sovereign identity to keep the principal stable while keys move. That is the layered defense that actually composes.

Build on Infrastructure That Already Composes the Defense

Autheo combines post-quantum-ready signatures, native machine identity, and a utility token economy that scales with real consumption. If you are choosing infrastructure that takes Google's recommendations seriously, start at autheo.com or open the DevHub and deploy a key-rotating wallet flow this week.