Stacker News thread on Ledger adding NIST PQC support to hardware wallets, with the usual blockchain migration theater.
12 comments
Supporting ML-DSA or SLH-DSA in a hardware wallet is the easy part, the ugly bit is that most chains still have to fit larger public keys and signatures into address formats, transaction scripts, and fee models that were never sized for PQC. So this is useful for key storage, but it does not by itself solve the on-chain migration problem, which is where the real compatibility break sits.
Supporting ML-DSA or SLH-DSA in a hardware wallet is the easy part, sure. But calling that “useful for key storage” makes it sound much more concrete than it is, these wallets are just collecting compliance badges for a migration path nobody has.
The real problem is still on-chain encodings, fee pressure, and consensus changes, and none of that gets less ugly because Ledger added a couple of NIST names to a menu.
> this is useful for key storage
Not really, because a harwdare wallet that can only sign an algorithm nobody can actually spend to yet is just demoware. The real problem is chain-level migration, and until there is an actual script, address, and fee story for PQC, Ledger adding ML-DSA support mostly widens the marketing surface.
Key storage, sure, but wallet firmware support won’t shrink the eventual fee bloat.
Compared with ML-DSA, Falcon cuts fee bloat, but Ledger loses NIST standardization ease.
Are they exposing this as hybrid signing too, or just “PQC supported” in the marketing sense? For wallets, the migration path feels like the whole story.
> Are they exposing this as hybrid signing too, or just “PQC supported” in the marketing sense?
Probably the latter, because “PQC supported” on a wallet usually means it can hold a key and produce a signature, not that any chain path exists to use it. The migration path is the whole story here, but until the transaction format and verification rules change, hybrid signing on the device is just a demo feature.
> until the transaction format and verification rules change
What baseline are they comparing against for the on-device part, just “can generate a signature” or a full hybrid path with serialization, recovery, and verification against an actual spend format? And if it’s only the former, what happens when the chain later settles on a different PQC scheme than the wallet firmware picked, do you end up with a permanently stranded key type or another firmware migration layer?
Baseline is usually just “can generate a signature” and maybe store the key, not a full spend path. Once the chain picks a different scheme later, the old one mostly becomes a museum piece with better PR.
> what happens when the chain later settles on a different PQC scheme
The seed is not stranded, the deirved address/keypair is. Without a chain-agnostic abstraction for serialization and spend rules, the old app just becomes dead baggage when the network picks a different scheme.
PQC matters for the seed backup lifecycle, because archived wallet backups outlive current chains.
The annoying part is not the math, it's the encoding (again). New PQC key and sig formats means new canonicalization rules, and wallets love turning that into consensus bugs....