Wallet Keys Could Fall in Months. Is Your Stack Ready?

By Lazar Milicevic · Published October 9, 2026 · 7 min read

Your business probably depends on digital signatures in more places than you can name: payment webhooks, API signing secrets, TLS certificates, maybe a crypto wallet or two. A researcher just said a signature scheme underneath much of this could, in the worst case, fall within months. Nobody has broken it, but the migration problem is real either way, and it's the part you can prepare for this week.

What was actually claimed (and what wasn't)

Justin Drake, an Ethereum Foundation researcher, warned on October 7, 2026 that advances in AI and mathematics could break ECDSA, the signature scheme that authorizes blockchain transactions, "in the worst case in months not years," according to Cryptonomist's report. By "break," he means fast private key recovery, for example in one week, on available hardware such as a large GPU cluster (Gizmodo).

What this is not: a demonstrated attack. His statement describes a potential future threat, and he tied it to OpenAI's October 6, 2026 release of mathematical research from an internal model: 722 manuscripts in 372 result families, per Bitbase. OpenAI did not announce an attack on ECDSA, RSA, or wallets. Its own repository says results are at different stages of verification and some unformalized ones could have issues. The link to elliptic curves is Drake's inference, not OpenAI's claim.

The pushback is substantial. Coinbase's head of cryptography, Yehuda Lindell, said there is no evidence whatsoever pointing to a break of decades-old hardness assumptions like elliptic curve cryptography.

So the honest summary: one credible researcher has a personal worst-case timeline, a prominent cryptographer says there's zero evidence, and nobody can forecast AI math progress with confidence. That uncertainty is exactly why the useful response is structural, not reactive.

Two postures, and why both are right

Drake's recommended "bunker mode" is a gradual move of assets to fresh addresses whose public keys aren't exposed, with remaining funds moved again after any signing. He also said a rushed migration could do more harm than good.

Vitalik Buterin takes the risk seriously but opposes panic. He said users shouldn't scramble to move funds to new wallets today, while still wanting the ecosystem to reduce its dependence on cryptography vulnerable to quantum computers and possible AI-discovered shortcuts (Yellow). He also said botched migrations had cost him more than all hacks combined (CryptoPotato).

That last line is the most useful sentence in the whole story for a small business. The attack is hypothetical. Migration pain is guaranteed if a forced change ever comes. When a standard has to change, every system that signs or verifies has to change, and so does everything that depends on those systems.

One detail worth understanding even if you never touch a wallet: on Ethereum, an account that has only received funds hasn't exposed its public key onchain. Once it signs a transaction, the public key can be recovered from the signature (Bitbase). That's why Drake's advice centers on fresh addresses. The general principle carries over: exposure happens at the moment you use a key, so the number of places a key gets used matters.

Why this lands on a non-crypto business

Lindell made the point that a sufficiently general break of public-key cryptography would reach far beyond wallets. His examples: fake public-key certificates impersonating bank websites, and signed malware pushed as banking apps or operating systems. That's a much bigger blast radius, though it's a hypothetical about a general break, not about anything demonstrated.

I won't claim which specific vendors or APIs depend on ECDSA. That varies by provider, and you need to check each one's documentation. What I can say from my own experience building integrations: problems often come not from the clever part but from hidden coupling.

• A signing key hardcoded in one script.
• A vendor webhook that only accepts one verification method.
• An accounting export that assumes one format forever.
• The script someone wrote two years ago that nobody documented.

Tools that don't talk to each other are annoying on a normal Tuesday. On the day a standard changes, those same tools become a fire drill, because you don't know what breaks until it breaks.

Build the signature and key dependency map

This costs nothing and takes an afternoon. Open a plain spreadsheet. List every place your business creates or verifies a signature, or holds a secret:

• Crypto wallets, if you have any
• Payment provider webhooks that verify signed payloads
• API keys and signing secrets in your automations
• Anything authenticating with a certificate or signed token
• CI/CD and deploy credentials
• Code signing, if you ship software

For each row, write four columns:

Then mark each row green, yellow, or red. Green means isolated and swappable. Red means tangled into everything. An example of the output, with made-up systems:

system,protects,holder,blast_radius,swappable,status
stripe-webhook-handler,order fulfillment,env var on VPS,orders stall,yes (one file),green
invoice-export-script,accounting sync,hardcoded in script,books out of sync,no (3 callers),red
company-wallet,treasury,founder laptop,funds,partly,yellow
zapier-signing-secret,CRM updates,Zapier vault,lead routing,yes,green

This map is worth having whether or not any signature scheme ever falls. The red rows are also where your next outage is hiding.

Make signing logic live in one place

The single highest-leverage refactor: if you automate anything, put signing and verification in one clearly named module, not copy-pasted across ten scripts. One place to change beats ten places to forget.

# signing.py — the ONLY file that knows how we sign or verify
import hmac, hashlib, os

SCHEME = os.environ.get("SIGNING_SCHEME", "hmac-sha256")

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    if SCHEME == "hmac-sha256":
        expected = hmac.new(secret.encode(), payload, hashlib.sha256).hexdigest()
        return hmac.compare_digest(expected, signature)
    raise NotImplementedError(f"Unknown scheme: {SCHEME}")

Every handler imports verify_webhook instead of rolling its own. If a vendor changes what it signs with, or you add a second accepted method during a transition, you edit one file and run one test suite. Note this example uses HMAC with a shared secret, which is a different mechanism from ECDSA; the point isn't the algorithm, it's the seam. Your vendor decides what scheme their webhooks use, so check their docs.

Also worth doing while you're in there:

• Move secrets out of source and into one vault or environment layer.
• Write down the rotation procedure for each key. If rotating takes a day of archaeology, that's a red row.
• Test the rotation once, on purpose, while nothing is on fire.

What the standards bodies say (and what's still draft)

There is a real migration path in motion, independent of Drake's warning. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA, the stateless hash-based signature standard) on August 13, 2024, per NIST's publications page.

NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," is listed there as a draft released 11/12/2024. It proposes deprecating quantum-vulnerable public-key algorithms such as RSA and ECDSA after 2030 and disallowing them after 2035. Those dates are a proposal in a draft, not a binding mandate, so check NIST's page for current status before you plan around them.

Ethereum's own documentation says its Lean Ethereum roadmap targets 2029 for full post-quantum protection (ethereum.org). Treat that as a roadmap target, not a guarantee.

One caution that supports the "don't rush" argument: Buterin singled out lattice-based cryptography, including ML-DSA, as an area where AI-driven mathematical discovery could erode assumed security margins over the next two years (CryptoSlate). Even the replacement standards aren't immune to the same uncertainty. Drake's institutional advice mentions considering hash-based signatures like SPHINCS for critical signers, but that's from secondary coverage of his post, so read the original before quoting it.

The takeaway: you can't pick the "safe" algorithm once and forget it. You can only make switching cheap.

What this looks like in practice

The unglamorous layer is the one I enjoy most when building automations: consolidating credentials, keeping verification logic behind a single module, and noting which automation touches which secret. None of that requires predicting which cryptographic scheme survives. It just means the dependency map exists, the red rows get fixed first, and a rotation has been rehearsed before anyone needs it.

The part you control

Anyone giving you a confident date is guessing. A security timeline that depends on AI progress is one you can't forecast, so don't build your plan around the date. Build it around the cost of changing course.

A short checklist for this week:

1. Build the dependency map. Every signature, every secret, four columns.
2. Mark green, yellow, red. Fix the reds that are also your outage risks.
3. Consolidate signing and verification into one module.
4. Document and test one key rotation end to end.
5. If you hold crypto, read Drake's and Buterin's guidance and decide deliberately. Don't panic-migrate. Their warnings about rushed moves are the best-supported part of this story.
6. Check each critical vendor's docs for their migration plans.

A business that can rotate keys and swap verification in an afternoon is covered against this scenario and the next surprise too. Readiness beats speed. Boring, documented, swappable wins.

Want more like this?

I write about practical AI automation for solopreneurs and small teams.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building AI automations that actually ship.