Research Note · Quantum Risk in Digital Assets

Post-quantum security for Bitcoin and Ethereum: an account-type autopsy

Roughly 6.9 million bitcoin and 20.5 million ether sit behind public keys a quantum computer could invert. Which ones, and why, depends less on the wallet you chose than on what you did with it. A walk through the exposure, account type by account type.

In April 2026, a whitepaper appeared on arXiv with an unusual author list. Ryan Babbush, Craig Gidney, Hartmut Neven and colleagues from Google Quantum AI — the group that has spent a decade publishing the reference resource estimates for quantum attacks on cryptography. Justin Drake from the Ethereum Foundation. Dan Boneh from Stanford. Between them, the people who calculate how fast the attack is coming and the people responsible for the thing being attacked, signing the same document.[1]

Their headline number: solving the elliptic-curve discrete logarithm problem on secp256k1 — the curve securing Bitcoin and Ethereum — takes 1,200 logical qubits and 90 million Toffoli gates, or 1,450 logical qubits and 70 million Toffolis in a variant tuned the other way. Compiled onto a superconducting surface-code architecture, that is fewer than half a million physical qubits: a roughly twenty-fold reduction on prior estimates.

Their second, quieter decision matters at least as much. They did not publish the circuits. Instead they published a zero-knowledge proof — compiled through the SP1 zkVM, attested with a Groth16 SNARK — that lets anyone verify they possess a working circuit of the stated size without learning how to build it. The team that has always published everything has decided that this particular thing should not be published. That is a signal about proximity, delivered in the form of a cryptographic artefact rather than a press release.

This article walks through what that means concretely for Bitcoin and Ethereum: which account types are exposed, why, and what can be done. It assumes the general picture from our companion piece on what post-quantum cryptography actually breaks and replaces — in particular, the point that blockchains are a signature problem, and that a permanently published public key is the worst possible case for a signature scheme.

Three attacks, two clocks

The paper's most useful contribution is a taxonomy. Quantum attacks on a blockchain divide by how fast the attacker must be, and that turns out to depend on which hardware platform gets there first.

  1. On-spend attacks — the attacker breaks a key while the transaction is in flight, between broadcast and settlement. Needs the whole ECDLP solved inside a block interval: ~10 minutes for Bitcoin, ~12 seconds for Ethereum, ~400 milliseconds for Solana. Also called short-range or just-in-time attacks.
  2. At-rest attacks — the attacker works on a public key that has been sitting exposed for years. Days or weeks of compute are perfectly acceptable. Also called long-range attacks.
  3. On-setup attacks — the attacker breaks a fixed protocol parameter once, offline, producing a reusable exploit that needs no further quantum access. Bitcoin is immune. Ethereum's data-availability layer is not.

Which of these is feasible depends on the clock speed of the machine, and this is where the story connects to hardware. Superconducting, photonic and silicon spin-qubit processors have fast gates and short error-correction cycles — the paper calls them fast-clock architectures. Neutral atoms and trapped ions perform the same logical operations two to three orders of magnitude more slowly: slow-clock.

The consequence is stark. On a fast-clock machine, the authors estimate 70–90 million Toffoli gates resolve in 18 to 23 minutes. An attacker can precompute the half of Shor's algorithm that depends only on public protocol parameters and wait in that “primed” state until a public key appears, which halves the remaining time to roughly 9 to 12 minutes from the moment a key is revealed.

Nine minutes, against a Bitcoin block interval that averages ten.

Because mining is a Poisson process, the block time is exponentially distributed, and an attacker who needs 9 minutes succeeds whenever the next block happens to take longer than that — which is exp(−9/10) ≈ 41% of the time. That is not a distant threat to dormant coins. That is every transaction you broadcast.

RACE AGAINST THE BLOCK A fast-clock attacker needs ~9 minutes. Bitcoin gives it ten. 100% 75% 50% 25% 0% P(BLOCK NOT YET MINED) 0 10 20 30 40 MINUTES SINCE TRANSACTION BROADCAST ~9 min: key derived 41% — the theft window Bitcoin blocks still unmined at 9 min Bitcoin (10 min avg block) — 41% risk Litecoin (2.5 min avg block) — 2.7% risk
Figure 1. Block arrival is a Poisson process, so the wait for the next block is exponentially distributed: the chance it is still unmined at time t is exp(−t/T). That residual is exactly the attacker's window. A fast-clock attacker needing ~9 minutes to derive a private key from a public key revealed at broadcast succeeds whenever the block takes longer than that — 41% of the time on Bitcoin, ~2.7% on Litecoin, and under 0.02% on Dogecoin's one-minute blocks. Faster chains are safer against this particular attack. Curves computed from the mean block intervals; attack time from Babbush et al. 2026, §II.B.

There is a counterintuitive corollary worth sitting with: against on-spend attacks, the faster chain is the safer chain. Litecoin's 2.5-minute blocks cut the risk to under 3%; Zcash's 75-second blocks to roughly one in thirteen hundred; Dogecoin's one-minute blocks to less than one in eight thousand. Bitcoin's ten-minute interval, the conservative choice that makes it hard to reorganise, is precisely what hands a quantum attacker its window.

On slow-clock hardware — neutral atoms, trapped ions — on-spend attacks are off the table for the foreseeable future, and only at-rest attacks work. This is why the paper insists the community plan for two scenarios rather than one date: if fast-clock architectures win the race, active transactions are at risk from day one; if slow-clock platforms get there first, there is a reprieve for transactions but not for exposed keys.

The mitigation you need depends on which hardware architecture arrives first — which is not something the blockchain community controls, or can currently predict.

Bitcoin: your address prefix is not the point

Bitcoin has no accounts. It has unspent transaction outputs, each locked by a script. The script types differ in one respect that decides everything: whether the public key is written on the chain, or only a hash of it.

This matters because Shor's algorithm inverts a public key. It cannot invert a hash — that would need Grover, which as we covered in the companion piece is not a credible threat against SHA-256. So a hashed public key is genuinely protected, right up until the moment you spend, at which point you must reveal it.

Script typePrefixExposed viaNotes
P2PKn/aonchain · mempool · offchainPublic key written directly on chain. ~1.7M BTC, incl. Satoshi-era mining rewards.
P2PKH1…mempool · offchainHashed key. Immune at rest unless reused.
P2MSn/aonchain · mempool · offchainLegacy multisig; all n public keys on chain.
P2SH3…mempool · offchainScript hidden behind a hash until spent.
P2WPKHbc1q…mempool · offchainCurrently the most popular type.
P2WSHbc1q…mempool · offchainSegWit script hash.
P2TRbc1p…onchain · mempool · offchainTaproot. Stores the tweaked key unhidden — a regression to P2PK-era exposure.
P2MRbc1z…mempool · offchainProposed (BIP-360). Taproot minus the vulnerable key-path spend.

Three things in this table deserve more than a glance.

Taproot was a security regression

The 2021 Taproot upgrade is a genuine advance in privacy and expressiveness, and it reintroduced a vulnerability that Bitcoin had spent a decade designing away. P2TR records the tweaked public key directly in the locking script rather than hiding it behind a hash. From the standpoint of quantum security, a bc1p address is exposed the instant it receives coins — the same position as a 2009-era P2PK output.

A first-time buyer who receives bitcoin at a fresh bc1q address is immune to at-rest attacks. The same buyer receiving at a fresh bc1p address is exposed immediately. Same wallet software, same user, different risk class. BIP-360's proposed P2MR — published to the BIP repository in February 2026 and now in review, with a testnet implementation but no activation timeline — is essentially Taproot with the quantum-vulnerable key-path spend removed.[3]

Address reuse flattens every distinction above

This is the part that undoes the table. The protection offered by P2PKH, P2SH, P2WPKH and P2WSH is that the public key stays hidden behind a hash — but spending reveals it. If you spend some of the balance at an address and leave the rest, the public key is now permanently on the chain, and everything still sitting there is exposed to at-rest attack. The chain becomes, in the paper's phrase, a “cheat-sheet” that solves the otherwise-intractable problem of finding a public key from its hash.

So the safety of your address type is not a property of the prefix. It is a property of your behaviour. And in practice, reuse is pervasive — exchanges and merchants prefer stable, recognisable deposit addresses; some of the largest exposed holdings in the paper's analysis trace to major exchanges. Roughly 6.9 million BTC are vulnerable in total, against ~1.7M in P2PK alone.

BITCOIN SUPPLY BY QUANTUM EXPOSURE About a third of all bitcoin is already exposed. ~1.7M P2PK ~5.2M reused / exposed keys ~13M — hashed keys, not yet revealed ~6.9M BTC vulnerable ~35% of all bitcoin in existence Of the vulnerable supply, ~2.3M BTC has not moved in over five years — the dormant-asset problem. These coins cannot be migrated by their owners. Many have no owner left to migrate them. Source: Babbush et al., arXiv:2603.28846 (2026), Figs. 5, 7 and 13 · data from bigquery-public-data.crypto_bitcoin
Figure 2. Total bitcoin supply split by quantum exposure. P2PK, P2MS and P2TR outputs are exposed by construction; the remaining vulnerable supply comes from address reuse, where a past spend has published the public key. The ~13M “safe” portion is safe only while its keys stay unrevealed — a single spend moves a balance across the line. Figures are a point-in-time estimate and will drift.

The extended public key is a force multiplier

Modern hierarchical deterministic (HD) wallets derive a tree of keys from one seed, which is what lets you use a fresh address per transaction without managing a thousand backups. With normal derivation, child public keys can be derived from the parent extended public key (xpub) alone — the feature that lets a portfolio tracker or an auditor watch your addresses without holding any private key.

Against a quantum attacker this feature inverts. From a leaked xpub and a single derived private key, the attacker recovers the extended private key, and with it every key in the tree. One exposure, unbounded compromise.

The people most affected are not individuals. They are the services built on the premise that extended public keys are safe to share: portfolio trackers, custody integrations, accounting and audit tooling, and any provider that maintains a repository of customer xpubs. That premise was correct for fifteen years and stops being correct at Q-Day. Hardened derivation avoids it; a great deal of deployed infrastructure does not use hardened derivation.

What is not a threat: mining

One myth deserves killing, because it absorbs attention that belongs elsewhere. Quantum computers do not threaten proof-of-work. Grover's quadratic speedup against SHA-256 is consumed entirely by error-correction overhead and does not parallelise, while mining is the most parallelised computation on earth. The paper's estimate: under fantastical assumptions — a full SHA-256 evaluation per one-microsecond error-correction cycle — a quantum miner would still land two orders of magnitude below a single off-the-shelf ASIC. Under realistic assumptions it is ten orders of magnitude short. Their verdict is that this is not worth worrying about for several decades.

Ethereum: nothing to outrun, everything exposed

Ethereum inverts Bitcoin's risk profile. Its 12-second slots and mature private mempools make on-spend attacks impractical for early fast-clock machines — there is simply no window. Every one of Ethereum's five vulnerabilities is instead an at-rest attack, which means even slow-clock hardware is sufficient.

That is a worse position, not a better one. Bitcoin's exposure is a consequence of user behaviour and can partly be avoided by careful users. Ethereum's is structural.

ComponentVulnerabilityPrimitiveAt risk
Account modelAccount VulnerabilityECDSA20.5M ETH
Smart contractsAdmin VulnerabilityECDSA2.5M ETH + ~$200B
Smart contractsCode VulnerabilityECDSA, alt_bn128, KZG, BLS12-38115M ETH (L2 TVS)
ValidatorsConsensus VulnerabilityBLS12-38137M ETH staked
ValidatorsData Availability VulnerabilityKZG commitments15M ETH

Accounts cannot rotate

An externally owned account's address is derived from its public key, so securing it with a new keypair means abandoning the account entirely — along with its DeFi positions, governance history and reputation, all of which the ecosystem increasingly treats as identity. And the moment an account sends its first transaction, the signature publishes the full public key.

So: every EOA that has ever transacted is exposed, permanently, and no user action fixes it. The authors estimate a fast-clock attacker could crack the 1,000 highest-value Ethereum accounts — approximately 20.5M ETH — in under nine days.

Admin keys are the sharp end

The number that should concern anyone with institutional exposure is not the 20.5M ETH. It is the ~70 contract accounts, among the top 500 by ETH balance, that hold administrative privileges over the contracts governing roughly $200 billion in stablecoins and tokenised real-world assets. The authors estimate a fast-clock attacker could derive private keys for those 70 accounts in about fifteen hours.

Admin keys are rarely rotated, frequently used in public for governance votes and upgrades, and hold powers that make the balance in the account irrelevant. Compromising one can mean minting unbacked stablecoins to collapse a peg, draining the liquidity behind a cross-chain bridge, feeding false prices to an oracle to trigger cascading liquidations, or seizing a guardian's power to pause and modify a live DeFi protocol.

This is why balance-based risk models understate the problem badly. The exposure is not what the admin account holds; it is what it controls. The paper declines to put a single number on it, noting the true figure “almost certainly encompasses substantial fractions of the entire ecosystem's Total Value Secured” — over $600 billion.

The KZG trusted setup: break once, own forever

The most under-appreciated item in the whole paper is Ethereum's Data Availability Sampling, which lets validators verify that a Layer 2 posted its data without downloading all of it. Since the Dencun upgrade in March 2024, the majority of L2 data volume depends on it. DAS uses KZG polynomial commitments on the BLS12-381 curve, and KZG requires a trusted setup: a one-time ceremony generating a secret scalar — the “toxic waste” — that must be destroyed, leaving behind public parameters called the Structured Reference String.

The toxic waste is mathematically recoverable as the discrete logarithm of two points in that public SRS. A CRQC can compute it from published data.

What makes this categorically different from every other attack in this article is what happens next: nothing further requires a quantum computer. The extracted secret is a permanent, tradable backdoor that lets any adversary forge data-availability proofs on ordinary hardware, indefinitely, until a new trusted setup ceremony replaces it. Every other attack here needs a CRQC per target. This one needs a CRQC once, ever, and then it is a commodity. Zcash's Sapling pool has the same structure and the same problem.

Consensus: safety in numbers, for now

Ethereum's ~1 million validators sign attestations with BLS12-381 signatures, aggregated for efficiency. Compromising more than a third of validators halts finality; more than half allows deep chain reorganisations; more than two thirds allows finalising inconsistent chains, an unrecoverable event requiring social consensus and a hard fork.

Here the sheer number of validators is a defence: the paper estimates that even 20 fast-clock CRQCs would need over nine months to compromise a two-thirds supermajority. But it flags the obvious caveat — that estimate assumes a uniformly decentralised validator set. Stake is not uniformly distributed. Lido alone accounts for roughly 20%, and an attacker who targets the key-management infrastructure of a few large staking providers reaches the thresholds far faster.

What actually exists today

The picture is not empty, and it is not close to sufficient.

Already running post-quantum in production: the Quantum Resistant Ledger has been post-quantum since inception in 2018 and is adding ML-DSA. Algorand deployed Falcon signatures for state proofs and executed its first PQC-secured transaction in 2025, and supports account key rotation. The XRP Ledger has deployed ML-DSA signatures on its AlphaNet test instance. Solana has an experimental Winternitz Vault using hash-based one-time signatures.

Bitcoin: BIP-360's P2MR is in review with no activation timeline. Off-chain, Project Eleven's yellowpages registry lets a holder bind an existing Bitcoin address to a new post-quantum keypair via a timestamped, publicly verifiable proof, without moving coins or touching the protocol — a paper trail of ownership that becomes useful precisely if ECDSA falls. It changes nothing on-chain, which is both its limitation and the reason it can exist today.[4]

Ethereum: Account Abstraction (ERC-4337) and EIP-7702 let accounts use customisable authentication logic, decoupling identity from a single ECDSA key. The paper is clear-eyed that these “mitigate the symptoms and not the root cause” — the only gateway into Ethereum remains the vulnerable EOA. EIP-7932 proposes precompiles for post-quantum signature schemes, without which smart contracts cannot verify PQC signatures at reasonable gas cost. The Ethereum Foundation has funded research into hash-based XMSS variants to replace BLS aggregation.

The obstacle is bytes, not cycles

It is widely assumed that what blocks post-quantum cryptography on a blockchain is that the algorithms are too slow. For the likely replacement it is not. ML-DSA verifies faster than Ed25519 and roughly 2.5× slower than RSA-2048 — and verification is precisely the operation a blockchain performs most, since every full node checks every signature in every block.[6] Signing is about seven times slower than Ed25519 and eighty times faster than RSA. None of that is disqualifying.

The obstacle is size. An ECDSA signature and compressed public key cost about 100 bytes; the ML-DSA-44 equivalent costs 3,732. Hold the block size fixed and a typical transaction grows by more than an order of magnitude, so the chain processes correspondingly fewer of them. That is a block-space argument, and Bitcoin has had one of those before — the 2017 dispute over block size ended in the hard fork that created Bitcoin Cash. The paper names the risk directly: increased resource requirements “portend network centralization, which is at odds with some of the foundational ethos of Bitcoin.”

Compute does bite in two narrower places. On the EVM, execution is metered by gas, and with no post-quantum precompiles a contract must implement verification in bytecode — prohibitively expensive rather than merely slow, which is what EIP-7932 exists to fix. And on the consensus layer the problem is neither speed nor size but capability: ML-DSA cannot aggregate the way BLS12-381 does, and Ethereum compresses tens of thousands of validator attestations into a few dozen signatures precisely by aggregating. Replacing BLS means finding a post-quantum scheme that preserves that property — which is why the Ethereum Foundation is researching hash-based XMSS variants rather than simply dropping ML-DSA in. Losing RSA and ECC costs the ecosystem a set of tricks, not just a byte budget.

A reality check on the demonstrations

In April 2026, Project Eleven awarded its 1 BTC Q-Day Prize to Giancarlo Lelli for running a variant of Shor's algorithm against a 15-bit elliptic-curve key on publicly accessible quantum hardware — a 512× improvement on the previous public demonstration, and the largest such attack to date.[5]

Fifteen bits. Bitcoin uses 256. The gap is not a factor of 17; it is the entire problem. Public demonstrations track the frontier of what can be done openly on cloud-accessible devices, which is a very long way from what a purpose-built machine could do.

But the paper makes a sharper point about these ladders, and it cuts the other way. Progress in quantum computing is lumpy: it arrives when a scaling barrier falls, not incrementally. A team that overcomes its barriers may go from 32-bit to 256-bit with little in between, and no one should expect the most advanced cryptanalytic work to be published at all. The authors' conclusion is worth quoting: a successful public demonstration on a 32-bit curve “should not be seen as a wake-up call to adopt PQC as much as a potential signal that PQC adoption has already failed.”

Waiting for a convincing demonstration is a strategy that only produces the demonstration you were waiting for once it is too late to act on it.

Questions a risk committee should be asking

This is where the analysis becomes operational. Not “is my wallet safe” — that framing does not survive contact with the structural findings above — but what exposure exists, who owns it, and what governs it.

  1. Custody: what is the address hygiene of our provider? Do they reuse deposit addresses? Do they hold coins in bc1p Taproot outputs? Reuse converts a nominally safe script type into an exposed one, and it is invisible from a balance statement.
  2. Extended public keys: where have we shared xpubs? Portfolio trackers, auditors, tax tooling, custody integrations. Each is a potential total compromise of a derivation tree rather than a single address, and this is a contractual and vendor question, not a technical one.
  3. Issuer key governance: who controls the admin keys behind our tokenised exposure? For any stablecoin or tokenised RWA position, the relevant risk is not the issuer's reserves — it is whether their upgrade and minting keys are rotatable ECDSA keys that have already been used in public. The reserves can be perfectly sound while the peg collapses.
  4. Layer 2 proof systems: which cryptography secures our bridged assets? zk-STARKs are hash-based and currently quantum-resistant. Optimistic rollups, pairing-based zk-SNARKs and standard bridges are not. The paper puts ~15M ETH of Total Value Secured in quantum-vulnerable L2 architectures, dominated by the largest optimistic rollups.
  5. Cross-chain migration: is the option priced? Assets living on multiple chains — USDC, USDT — can withdraw from lagging chains toward post-quantum ones. Circle's 2024–25 wind-down of USDC on TRON took a full year between ceasing minting and ending redemptions. That is the realistic timescale for an orderly exit.
  6. Dormant assets: what happens to the price when 2.3M BTC moves? Not a security question, a market one — and it lands on anyone holding the asset, not just holders of the vulnerable coins.

You can run the underlying resource estimate yourself: our interactive Shor estimator takes a key size and returns logical qubits, Toffoli count, physical qubits and runtime. Entering ECC-256 puts the whitepaper's numbers in the same frame as the RSA figures most institutions have been tracking — and shows why the elliptic-curve target is the easier one.

The dormant-asset problem has no technical solution

Around 2.3 million BTC in vulnerable addresses has not moved in over five years. Roughly 1.7M sits in P2PK scripts from the earliest era, including approximately 1 million bitcoin generally attributed to Satoshi Nakamoto. The most common theories are that these keys were lost, discarded or never recorded — the coins were worthless when mined.

These coins cannot be upgraded. A protocol change enabling post-quantum scripts protects coins whose owners can sign a migration transaction; nobody can sign for these. They are a fixed, growing, multibillion-dollar target that will eventually become accessible to whoever builds a CRQC first.

Bitcoin's options are all bad in different ways. Do nothing: preserve property rights and immutability, accept that a quantum actor eventually takes the coins. Burn: render dormant coins unspendable after a date — prevents theft by expropriating, permanently, anyone who failed to migrate in time, and sets a precedent that cuts against the entire premise of the asset. Hourglass: rate-limit spending of dormant coins to smooth the shock, which mostly transfers the wealth to miners via fee auctions. An informal poll at the 2025 Presidio Bitcoin Quantum Summit reportedly split roughly evenly across all three. The paper adds a fourth — a “bad sidechain” that accepts off-chain ownership proofs to return salvaged assets to rightful owners — explicitly modelled on the bad-bank mechanism from traditional finance.

And it makes an argument governments will eventually have to engage with: laws criminalising the taking of these coins, absent protocol changes, do not protect them. They only ensure that whoever eventually takes them is someone willing to break the law. Hence the discussion of regulated “digital salvage,” by analogy to sunken treasure and unclaimed-property law — which the authors also show does not cleanly fit, since frameworks like the Revised Uniform Unclaimed Property Act presume a “holder” in possession, and nobody possesses a coin whose key is lost.

An honest position

No CRQC exists. The largest machines available today are orders of magnitude away in both qubit count and error rate, and the half-million-physical-qubit figure assumes a scaled-up device with error rates that have been demonstrated only in small systems — a gap we have written about at length. Nothing in this article says the money moves tomorrow.

What has changed is the shape of the target, and the identity of the people describing it. When Google's resource-estimation team, the Ethereum Foundation and Dan Boneh jointly conclude that the community should “join the migration to PQC without delay,” and simultaneously decline to publish their circuits, that is a considered position from the people with the most information.

Their own summary of the timing is the fairest note to end on: the time remaining before CRQCs arrive still exceeds the time needed to migrate — though the margin for error is increasingly narrow. That is not a crisis. It is also not room to wait for a clearer signal, because the analysis above suggests the clearer signal may never arrive in public.

All figures here are a point-in-time snapshot from a fast-moving landscape. The authors say so about their own numbers, repeatedly, and we repeat it: the Layer 2 and RWA figures in particular will be wrong before they are old.

A note on names. The paper cites Project 11's “Risq List,” a public registry of Bitcoin public keys at risk of at-rest attack. It has no relation to RISQ, JoS QUANTUM's quantum risk platform. The naming collision is coincidental.


References

  1. R. Babbush, A. Zalcman, C. Gidney, M. Broughton, T. Khattar, H. Neven, T. Bergamaschi, J. Drake, D. Boneh (Google Quantum AI, UC Berkeley, Ethereum Foundation, Stanford), Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations, arXiv:2603.28846 (April 2026). arxiv.org/abs/2603.28846 — the primary source for the resource estimates, the attack taxonomy, and the Bitcoin and Ethereum exposure figures throughout this article.
  2. D. Litinski, How to compute a 256-bit elliptic curve private key with only 50 million Toffoli gates, arXiv:2306.08585 (2023).
  3. BIP-360: Pay to Merkle Root (P2MR), Bitcoin Improvement Proposal, published February 2026. github.com/bitcoin/bips · bip360.org
  4. Project Eleven, yellowpages — a registry of post-quantum proofs of Bitcoin ownership. projecteleven.com · open-source tooling at github.com/p-11
  5. Project Eleven, Project Eleven Awards 1 BTC Q-Day Prize for Largest Quantum Attack on Elliptic Curve Cryptography to Date (April 2026). projecteleven.com — see also The Quantum Insider and CoinDesk.
  6. B. Westerbaan, Cloudflare, ML-DSA will have to do (2026) — normalised signing/verification benchmarks across ECC, RSA and the post-quantum signature schemes, and why ML-DSA's cost is size and lost versatility rather than CPU time. blog.cloudflare.com/ml-dsa-will-have-to-do
  7. ERC-4337, Account Abstraction Using Alt Mempool. eips.ethereum.org/EIPS/eip-4337
  8. EIP-7702, Set EOA account code. eips.ethereum.org/EIPS/eip-7702
  9. NIST, FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024). csrc.nist.gov/pubs/fips/204/final
  10. C. Gidney, How to factor 2048-bit RSA integers with less than a million noisy qubits, arXiv:2505.15917 (2025).
  11. Google Quantum AI et al., Quantum error correction below the surface code threshold, Nature 638, 920 (2025) — the Willow surface-code result underlying fast-clock feasibility.
  12. S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008) — source of the original recommendation to use a fresh address per transaction.
  13. BSI, Entwicklungsstand Quantencomputer, Version 2.2 (December 2025).