This year, two developments raised a question the blockchain industry has long treated as distant: how long will the elliptic curve signatures behind Bitcoin, Ethereum and Solana stay safe?
In March, Google Quantum AI estimated that a quantum computer could break elliptic curve signatures with far fewer resources than previously believed. In October, a large release of AI-generated mathematics from OpenAI led Ethereum researcher Justin Drake to call for the industry to "calmly begin planning for 'bunker mode'."
No one has demonstrated a break of ECDSA or any elliptic curve scheme, and respected cryptographers dispute the reasoning behind the call. The sections below cover how Turnkey's security team sees the risk, what it would and would not reach, and the steps Turnkey recommends.
Why recent developments are raising quantum security concerns
Three releases this year raised fresh concerns about the long-term security of elliptic curve signatures: Google's revised quantum computing estimates, OpenAI's large collection of AI-generated mathematics, and, a day later, Drake's call for "bunker mode."
Drake's proposal involves moving funds to fresh addresses whose public keys have never been exposed onchain, prompting swift responses from researchers across the industry.
| Date | Event |
|---|---|
| March 30, 2026 | Google Quantum AI and co-authors, including Drake and Stanford's Dan Boneh, publish revised quantum resource estimates for breaking elliptic curve cryptography |
| October 6, 2026 | OpenAI publishes a repository of 722 mathematical manuscripts produced by an internal model |
| October 7, 2026 | Drake posts his bunker mode call on X |
| October 7 to 9, 2026 | Vitalik Buterin, Yehuda Lindell and Emin Gün Sirer respond publicly |
Google reveals new quantum attack estimates
On March 30, 2026, Google Quantum AI published a paper on quantum attacks against elliptic curve cryptocurrencies. The researchers estimated that a quantum computer could potentially crack the cryptography protecting Bitcoin and other cryptocurrencies.
The research suggested that breaking the elliptic curve signatures that protect cryptocurrency wallets could require far less quantum computing power than previously believed. The Google Quantum AI researchers chose to withhold the specific circuits "in the interest of responsible disclosure," publishing a zero-knowledge proof of their results instead.
The paper notes that cryptographically relevant quantum computers do not exist today, and it urges vulnerable cryptocurrency communities to migrate to post-quantum cryptography "without delay."
OpenAI releases AI-generated math research
On October 6, 2026, OpenAI published a repository of AI-generated mathematical manuscripts produced by an internal model that was given approximately 4,000 problems to work on. OpenAI's initial release contained 722 manuscripts, and the repository itself cautions that "some of the unformalized results could have issues."
Why Justin Drake is calling for bunker mode
A day later, Drake posted his bunker mode call. Drake wrote that "it is now reasonable to brace for the possibility that ECDSA breaks before qday, in the worst case in months not years." Q-day refers to the point when quantum computers become powerful enough to break the widely used public-key cryptography that protects digital communications, financial transactions and other sensitive data.
Drake defines a break as "fast private key recovery (e.g. in one week) on available hardware (e.g. a large GPU cluster)." Drake's scenario is a hypothetical classical break, driven by AI-accelerated mathematics, with no quantum computer involved.
His recommendation is "a controlled mass migration of assets to fresh addresses," starting with large and sophisticated holders. He says this "does not require new cryptography or new wallets," and he is equally direct about pace, warning, "Don't rush."
Why some researchers disagree
Other researchers pushed back on the premise or the pace.
Yehuda Lindell, Head of Cryptography at Coinbase, wrote that "there is no evidence whatsoever pointing to a break of decades old hardness assumptions like elliptic curve cryptography."
Emin Gün Sirer, Co-founder and CEO of Ava Labs, argued that "we will see AI exploit systems-level bugs far before ECDSA falls," while calling a backup cryptosystem sensible.
Vitalik Buterin said he does not recommend that anyone scramble to move funds today, though keeping funds in addresses that have never sent a transaction is "a good idea" if it is not difficult.
Buterin also cautioned that lattice-based schemes, a leading post-quantum family, could take serious hits from AI math over the next two years. That is one reason hybrid designs, which pair a classical scheme with a post-quantum one, come up in the actions below.
Turnkey's view: prepare, don't panic
Turnkey's security team does not see a reason for a rushed migration. No one has demonstrated a break of an elliptic curve scheme, Drake's scenario is hypothetical, and a hurried migration carries risks of its own. Buterin put it plainly: "I personally have lost more money in botched migrations than I have lost in all hacks combined."
What the scenario does justify is planning. For threat modeling, Turnkey's security team treats any elliptic curve public key that is visible onchain as if its private key could one day be recovered. That turns a frightening headline into ordinary security work: know which of your keys are exposed, protect the ones that control the most value first, and keep a migration plan you could run calmly if it were ever needed.
What these risks mean for wallet providers and their customers
If Drake's scenario ever happened, the risk would fall on any key whose public key is already visible, whichever wallet provider holds it. An attacker who could recover a private key from its public key could sign transactions directly onchain, without going through Turnkey or any other provider.
Which wallets are most vulnerable?
Exposure depends on the chain and the address type. The Google paper describes when each type reveals its public key:
| Address type | When the public key becomes visible | Funds at rest |
|---|---|---|
| Bitcoin P2PK | Recorded directly in the locking script | Exposed from receipt |
| Bitcoin P2TR (Taproot, bc1p) | Recorded onchain in the receive transaction | Exposed from receipt |
| Bitcoin P2PKH, P2WPKH, P2WSH | Only a hash is onchain until the first spend | Protected until the address spends |
| Ethereum and EVM externally owned accounts (EOAs) | Revealed by the first signed transaction | Protected until the first send |
| Solana | The address is an encoding of the Ed25519 public key | Exposed as soon as the address is shared |
A few details matter. Spending part of a Bitcoin balance exposes the key for whatever remains at that address, and sharing an extended public key (xpub) exposes every address derived from it. Exposure also carries across chains: a key that has signed on one network is exposed on every network where the same address holds funds.
Drake's post specifically mentions ECDSA, but Turnkey's security team believes the same threat applies to Solana. Both ECDSA and EdDSA rely on complex mathematical algorithms that quantum computers could potentially break. If those fail, both are vulnerable.
Solana is the clearest case: unlike other blockchains, it has no separate concept of an address. A Solana address is the public key itself. A team planning for Drake's scenario should treat everything on Solana as exposed.
How Turnkey protects private keys
Turnkey generates keys, signs transactions and evaluates policies inside secure enclaves that have no persistent storage, no interactive access and no external networking. Keeping keys inside the enclaves prevents them from being copied or exfiltrated.
Turnkey's policy engine decides what transactions get signed based on rules set by the org's (Turnkey's customers') root quorum. Policies deny by default, an explicit deny always wins, and consensus rules can require more than one approver, which limits what a stolen credential or a mistaken request can do.
Where Turnkey's protections end
Enclaves protect where a key lives. Turnkey's comparison of blockchain post-quantum readiness makes the same point: holding a key inside an enclave "does not change what happens onchain." If someone derived a private key mathematically from an exposed public key, they could sign outside Turnkey, and no Turnkey policy would ever see that transaction.
How Turnkey is addressing quantum risks
Turnkey is not fully post-quantum today. The main reason Turnkey is not fully post-quantum is the blockchains it supports. Standard accounts on Bitcoin, Ethereum and Solana accept only elliptic curve signatures, so Turnkey has to sign with the curve each network requires. For those standard accounts, no wallet provider can make the signatures quantum-resistant on its own, and signing can change only when the networks do.
Migrating safely with Turnkey Verifiable Cloud
If you decide to migrate, as Drake recommends, the riskiest part is the move itself: funds sent to a wrong or compromised address, or a single person or credential deciding where funds go.
Turnkey Verifiable Cloud (TVC) can help here. TVC runs your own code, such as migration tooling that builds transfers to fresh addresses, inside the same kind of secure enclaves Turnkey uses for its own key management.
As networks add post-quantum signature schemes, the same setup can run a signer for them before Turnkey supports them natively.
Steps to reduce your quantum exposure
Take a gradual approach.
These steps reduce exposure to certain quantum attacks, but they are temporary precautions.
Protecting Bitcoin funds from quantum attacks Keep large balances in addresses that have never spent, and send change to a fresh address.
Reducing risks for Ethereum and EVM accounts Move funds to a new address that has never signed, starting with high-value accounts that rarely transact.
Understanding Solana's quantum vulnerabilities The fresh-address mitigation does not exist here. Protection has to come from each network's post-quantum roadmap.
Protecting critical signing keys These deserve extra attention: identify critical keys and require multiple approvals.
Securing API keys, passkeys and sessions Switching curves won't remove the threat. Limit permissions, require multiple approvals and keep sessions short.
Protecting applications and infrastructure Keep OpenSSH current and ask your TLS provider about hybrid post-quantum key exchange.
How to plan a secure wallet migration If you decide to move, list and rank your assets first, restrict where funds can go, and test with a small amount.
Protecting Bitcoin funds from quantum attacks
For Bitcoin you're holding rather than spending, the goal is to keep your public keys hidden for as long as possible.
- Use addresses that haven't spent funds. Some Bitcoin address types only reveal their public keys when you spend from them.
- Choose address types carefully. P2WPKH and P2PKH hide public keys until funds are spent. P2TR and P2PK expose them earlier. Google's paper recommends keeping public keys hidden where possible.
- Avoid reusing addresses. Generate a new address for each transaction, including change.
- Limit public key sharing. Only share extended public keys (xpubs) with third-party services when necessary.
Turnkey supports the main Bitcoin address types (P2PKH, P2SH, P2WPKH, P2WSH and P2TR) and lets you create new addresses within an existing wallet.
Reducing risks for Ethereum and EVM accounts
An exposed Ethereum key cannot be hidden again, so the fix is a new wallet that has never signed, starting with high-value accounts that rarely transact.
Turnkey wallets are hierarchical deterministic (HD) wallets, so a fresh Ethereum account can come from the same wallet seed, with no new backup, as long as the wallet's extended public key (xpub) has never been shared.
Understanding Solana's quantum vulnerabilities
Solana is different because its wallet addresses are derived directly from public keys. Solana's address design means your public key is exposed as soon as you share your address, even if you've never made a transaction.
Creating a fresh address doesn't provide the same protection as it can on Bitcoin or Ethereum.
For Solana and other networks whose address is the public key, longer-term protection will depend on adopting quantum-resistant cryptography. Follow their plans for upgrading.
Protecting critical signing keys
Some private keys control much more than a single wallet. They can authorize contract upgrades, manage bridges or control large amounts of cryptocurrency.
These keys deserve extra attention because compromising just one could put substantial funds at risk. Google's paper found that at least 70 of the 500 largest Ethereum contracts by ETH balance, holding about 2.5 million ETH, can be taken over through an administrator key.
Recommended precautions include:
- Identify critical keys. List accounts that control contracts, upgrades or large balances.
- Use fresh addresses. Where practical, move administrative permissions to addresses that haven't signed transactions.
- Require multiple approvals. Use policies such as Turnkey's two-approver access control to prevent one person from authorizing sensitive actions.
- Rotate signing keys. For critical systems such as oracles and L2 security councils, Drake suggests using a different signing key for each message, adding quantum-resistant signatures or both.
- Keep signatures private when possible. Buterin suggests collecting multisig approvals offchain to reduce public exposure.
Securing API keys, passkeys and sessions
Turnkey supports P-256, secp256k1 and Ed25519 for API authentication. All three API key types use elliptic curve cryptography, so switching between them won't eliminate the quantum threat.
Instead, focus on limiting what an attacker could do if a key were compromised.
- Limit permissions. Give users and applications access only to the operations they need.
- Protect root access. Set the root quorum above one so a single root user cannot authorize changes alone.
- Use short-lived sessions. Keep sessions brief and limit what they can do.
- Rotate API keys. Create a replacement key, update and test your integration, then remove the old key.
- Limit public key exposure. Avoid putting API public keys in public repositories or logs.
- Restrict key transfers. Allow private key imports and exports only when necessary, since these operations currently rely on P-256-based encryption.
Protecting applications and infrastructure
Wallets are not the only thing that relies on elliptic curves. Two everyday security protocols do too: TLS, which encrypts traffic between your users and your website or API, and SSH, which engineers use to log in to servers. Both start every connection with a key exchange, the step where the two sides agree on a shared secret key, and that step usually uses elliptic curves today. That puts both inside Drake's scenario.
The protection is a hybrid key exchange, which combines a classical method with a post-quantum one, so an attacker would have to break both to read the traffic.
- Keep SSH software updated. OpenSSH has used a hybrid key exchange by default since version 9.0, and the latest version is 10.6.
- Ask your providers about TLS. Your CDN, the network that serves your site from servers around the world, and your load balancer, which spreads traffic across your servers, often handle TLS for you. Ask whether your CDN and load balancer support a hybrid key exchange.
How to plan a secure wallet migration
If you decide to move funds or update your security setup, take a gradual approach.
- Identify your assets. List wallets, blockchains, address types, balances and any exposed public keys.
- Prioritize risks. Start with high-value wallets and accounts with exposed public keys.
- Choose new addresses. Decide where funds should move and who must approve transfers.
- Restrict transfers. Use Turnkey policies to limit where funds can go.
- Run your migration tooling on TVC. With Turnkey Verifiable Cloud, the code that builds transfers to your new addresses runs inside a secure enclave.
- Avoid root accounts. Use non-root users for transfers so Turnkey's security policies remain enforced.
- Test before moving everything. Send a small amount, confirm it arrives, then complete the migration.
These steps can reduce exposure to certain quantum attacks, but they are temporary precautions.
Get help from Turnkey's security team
If you have questions about your exposure or a migration plan, reach the team through the dashboard support chat or [email protected]. Enterprise customers can also use their shared Slack channel.
Turnkey will never ask for private keys, seed phrases, recovery bundles or session credentials in a support request.
Learn more about Turnkey's security architecture.
