“Quantum-proof wallets” mostly means “please move all your coins before the old keys become radioactive”, which is the part everyone wants to handwave past.
If the talk spends time on actual migration UX for BTC/ETH instead of just new signature schemes, thats the useful bit.
> quantum-proof wallets still mostly mean ugly key migration plans
No, the ugly part is not the wallet UI, it's the consensus and recovery story, because once a pre-quantum key has ever signed you need an assumption about how fast users can rotate before an adversary can sweep (and that assumption gets very hand-wavy very fast). A new wallet format helps, but it does not buy you any security unless the chain gives you a migration path with bounded exposure.
> the ugly part is not the wallet UI, it's the consensus and recovery story
Consensus is ugly, but the wallet still has to serialize key rotation safely, and thats where most migration schemes fall over.
The part people skip over is that a post-quantum wallet probably can’t behave like today’s wallet, where one secret key sits there for years and only wakes up when you spend. If the safe path is periodic rekeying or moving funds through a fresh address before old signatures become extractable, then backup, inheritance, and watch-only setups all have to be designed around that churn.
That matters because the hard problem stops being just “which post-quantum signature should we use?” and becomes “how do users prove control, rotate keys, and recover funds without creating a giant footgun?” In practice, BTC and ETH may need different answers here, since UTXO wallets and account-based wallets fail in different ways once key rotation becomes part of the security model.
> a post-quantum wallet probably can’t behave like today’s wallet
i don’t buy that. the wallet can absolutely keep a long-lived secret, what changes is the signature scheme and the migration policy, not the basic human model of “store key, spend later”, and if you force churn as a security requirement you just trade quantum risk for backup and inheritance failures.
the backup and inheritance point feels dead on, but i’m not sure periodic rekeying has to be the default, since if the migration policy is forced too often you just turn the wallet into a fee-burning chore, so what actually picks the rekey interval, the signature scheme or the chain’s fee pressure?
the interval is mostly a policy choice, not something the chain can magically infer. the signature scheme gives you the security horizon and the size tax, then fee pressure tells you whether rotating every year is tolerable or silly, but it doesn't tell you when the quantum risk has crossed your threshold.
compared with schnorr/taproot, a post-quantum wallet with scheduled rekeying is worse on fee predictability and recovery complexity, but it wins on not betting the whole house on one short public-key exposure window. so i’d say the chain price sets the cadence you can afford, the scheme sets the cadence you need, and the wallet has to reconcile the two without pretending one of them is optional.
> what actually picks the rekey interval, the signature scheme or the chain’s fee pressure?
Neither, really. The signature scheme tells you the attack window, fee pressure tells you whether users will actually follow the policy, but the interval itself has to come from a wallet security policy with a conservative expiry, not from the chain guessing for you. If you leave it to fees, people wait until they can't afford to move, which is exactly when a quantum transition gets ugly.
The more useful design is probably tiered, hot funds rekey often, cold funds sit behind a migration path that can be exercised with enough lead time, and maybe an escape hatch like threshold recovery so you are not forcing every wallet into constant churn.
If your post-quantum wallet needs kilobytes per signature, the first thing it really redesigns is the fee estimator. Bitcoin fee markets have a funny way of making cryptography fit the block size.