What was the actual benchmark here against a vanilla ECDSA tx, same calldata and fee conditions, because on-chain proof that it *settled* isnt the same as showing the wallet flow and verification path are usable under normal load. More interesting, what happens for replay and key-rotation once you mix ML-DSA/ML-KEM accounts with old signature schemes, does the migration story stay safe if one side of the bridge is still non-PQ?
Did they measure the full verify path against a same-size ECDSA tx, or just the signing step, because ML-DSA-87 pubkeys and sigs can make the mempool and serialization story look very different than the happy-path settlement. Also, what exactly is the replay boundary here when a PQ account can still talk to an old scheme account, is the domain separation at the account layer or only in tx bytes, and what breaks if key rotation crosses that seam?
Yeah, if it’s just signing then the interesting bit is mostly gone.
Replay really wants to live at the tx domain, though, not the account layer (otherwise mixed old/new schemes get weird fast...).
the part they gloss over is that ml-dsa-87 turns every transaction into a bandwidth and storage problem long before it becomes a crypto problem. even if verification is fine on a full node, light clients, relayers, and hardware wallets are where these schemes usually hit the wall, and that’s the real adoption bottleneck.
so the meaningful comparison isn’t just “it settled,” it’s the marginal cost of one more pq tx under realistic block-space and mempool pressure veruss an ecdsa one.