The quantum risk to a blockchain is measured in seconds, not decades
Most discussion of quantum computing and blockchains goes like this: one day a machine will break the elliptic-curve signatures that secure wallets, so everyone must move to post-quantum signatures before that day. True, but it skips the part that matters for a working network, which is when a key is actually exposed.
A key is only exposed while a transaction waits
On most chains an address is a hash of the public key, and the public key itself is not revealed until the owner spends. From the moment a transaction is broadcast until the moment it is written into a block, that public key sits in every node's mempool for anyone to read. That is the window in which a quantum attacker who can derive the private key from the public key could sign a competing transaction and get it mined first. This is the on-spend attack.
So the exposure of a transaction is not a property of the signature scheme alone. It is the time the transaction spends waiting: the mempool residence time. And residence time is a queueing quantity, which means it depends on load, on fees and on block capacity, all of which an operator can measure and, to a degree, control.
Two consequences that are easy to miss
First, there is a floor. If it takes an attacker a certain time to derive a key, and a block is produced every so often, then no policy can push exposure below what that ratio allows. Faster blocks or shorter waits help; clever ordering of the queue helps only up to that floor.
Second, and this is the uncomfortable one: blanket migration to post-quantum signatures can endanger the accounts that cannot move. Post-quantum signatures are several times larger than the ones they replace. If every active account switches at once, those larger signatures consume block space, blocks fill, waiting times rise, and every transaction still using a classical key now sits in the mempool for longer. The dormant accounts, the lost-key wallets, the cold storage that nobody has touched in years, are exactly the ones that cannot migrate, and they are the ones whose exposure goes up.
Protecting the accounts that can move, by moving all of them at once, raises the risk to the accounts that cannot.
What this means for anyone running or regulating a chain
- Measure mempool residence time as a security metric, not just a performance one. Its tail matters more than its mean; a policy tuned to the average is blind to the transactions that wait longest.
- Plan migration as a paced process with a budget of block space, not as a flag day.
- Treat the fraction of traffic that can safely be post-quantum at a given load as something to compute for your chain, not something to assume.
This is the line of work behind our Q-MEMShield paper at IEEE ICACT 2026 and its journal extension, which derives the exposure bounds and tests the migration policies in simulation. If you operate a chain or are assessing one, I am glad to talk it through.
