TL;DR
No consumer wallet — hardware or software — signs Bitcoin or Ethereum transactions with a NIST post-quantum signature today. Trezor, Ledger, Coldcard, Keystone, and MetaMask all rely on ECDSA or Schnorr, both breakable by a large-enough quantum computer running Shor's algorithm. Quantum resistance is a firmware and protocol question: the wallet you already own probably gets you there via update, once the underlying chain activates a post-quantum signature scheme.
The exceptions are wallets on chains that already ship post-quantum signatures — QRL (XMSS), some IOTA workflows, and a handful of experimental L2 prototypes. See the chain rankings for that side of the picture.
What "quantum-safe" actually means for a wallet
A wallet touches post-quantum cryptography at three layers. All three matter:
- On-chain signatures. The signature the chain accepts to authorise a spend. Today: ECDSA / Schnorr / Ed25519. Post-quantum: ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). This can only change when the chain protocol changes.
- Key transport & confidentiality. The channel between the wallet device and the host, and any cloud backup. NIST's answer is ML-KEM (FIPS 203). Wallets can add this unilaterally; most have not.
- Seed / recovery. BIP-39 mnemonics themselves are classical entropy — they are not "broken" by quantum computers. The addresses derived from them are what a quantum attacker targets.
Comparison matrix
Compiled from each vendor's public documentation and firmware release notes as of Q2 2026. Corrections welcome — email support@quantumcryptorisk.com.
| Wallet | Type | Signs with | PQC transport (ML-KEM) | PQC signatures (ML-DSA / SLH-DSA) | Firmware / update path | Notes |
|---|---|---|---|---|---|---|
| Trezor Safe 5 | Hardware | ECDSA (secp256k1), Schnorr | No ML-KEM in host channel | None shipped; PQC on public roadmap | Open-source firmware, signed updates | EAL6+ secure element; well-positioned to add ML-DSA once Bitcoin activates a PQC opcode. |
| Ledger Nano X / Stax | Hardware | ECDSA, Ed25519, Schnorr | No ML-KEM; BLE/USB channel is classical | None; Ledger Donjon publishes PQC research | Closed-source firmware, signed updates | ST33 secure element supports large key sizes needed by SLH-DSA in principle. |
| Coldcard Mk4 / Q | Hardware (Bitcoin-only) | ECDSA, Schnorr | Air-gapped (PSBT); transport threat minimal | None; will follow Bitcoin BIP activation | Open-source firmware, dual secure elements | Air-gap sidesteps host-channel exposure entirely; still ECDSA on-chain. |
| Keystone 3 Pro | Hardware (multi-chain) | ECDSA, Ed25519, Schnorr | Air-gapped (QR) | None shipped | Open firmware, triple secure elements | Air-gap plus 3× SE gives flexibility for future PQC firmware. |
| MetaMask (browser/mobile) | Software | ECDSA (secp256k1) | TLS to RPC only — no PQC-hybrid TLS | None; depends on Ethereum EIP | Frequent auto-updates via extension store | Fastest path to add ML-DSA once account abstraction wallets are common on Ethereum L2s. |
| QRL Wallet (native) | Software (QRL chain) | XMSS (hash-based, stateful) | N/A — signatures are already PQC | XMSS shipped since mainnet 2018 | Open-source, native app | One of the few production wallets signing on-chain with a post-quantum scheme today. |
Hardware wallets
Trezor (Safe 3 / Safe 5)
Open-source firmware and a modern EAL6+ secure element. Trezor has publicly acknowledged post-quantum planning but ships no PQC signature or ML-KEM transport today. If Bitcoin activates a BIP to add ML-DSA outputs, Trezor is well-positioned to add signing support via a firmware update.
Ledger (Nano X, Nano S Plus, Stax, Flex)
Ledger Donjon (the vendor's security research group) has published on ML-KEM and hash-based signatures, but production firmware still signs classically. The ST33 secure element can, in principle, handle the larger key and signature sizes SLH-DSA requires — the constraint is protocol-side, not silicon-side.
Coldcard (Mk4, Q)
Bitcoin-only, air-gapped via PSBT. The air-gap sidesteps host-channel exposure entirely, so ML-KEM in transport is largely a non-issue. On-chain signing is still ECDSA / Schnorr; the wallet inherits Bitcoin's quantum timeline.
Keystone 3 Pro
Air-gapped via QR. Triple secure elements give firmware headroom for larger PQC keys. No shipped PQC signatures today.
Software wallets
MetaMask, Rabby, Rainbow
All EVM software wallets sign ECDSA on secp256k1. The fastest realistic path to a quantum-safe Ethereum experience is account abstraction (ERC-4337): a smart-contract wallet can validate ML-DSA signatures inside its own verification logic without a consensus hard-fork. Adoption is early but growing on L2s.
QRL native wallet
Signs with XMSS, a stateful hash-based scheme. This is genuine post-quantum signing on a live production chain — but only for QRL, not Bitcoin or Ethereum.
IOTA Firefly
IOTA transitioned to Ed25519 with the Chrysalis upgrade and has published Coordicide-era plans for hash-based signatures. Not fully PQC on the current mainnet.
How to choose today
- Pick hardware on non-quantum criteria. Supply-chain integrity, secure element, open firmware, recovery UX. Any of the four hardware wallets above can add PQC via firmware.
- Prefer never-spent addresses for cold storage. Public keys behind a hash are safer than public keys already published on-chain.
- Follow chain-level PQC activation, not vendor marketing. The chain has to accept the signature. See rankings.
- Scan before you send. Our Wallet Scanner gives a rules-based exposure score for a specific address.
Nothing on this page is financial or investment advice. See methodology and editorial policy.
Frequently asked questions
Is any hardware wallet actually quantum-safe today?
No consumer hardware wallet ships a NIST-standardised post-quantum signature (ML-DSA or SLH-DSA) for signing Bitcoin or Ethereum transactions today. Trezor, Ledger, and Coldcard all sign with ECDSA or Schnorr — both breakable by Shor's algorithm on a sufficiently large quantum computer. What differs between vendors is the roadmap: firmware update path, secure-element flexibility, and public commitments to add ML-KEM / ML-DSA once host chains support them.
What is ML-KEM and why does it matter for wallets?
ML-KEM (FIPS 203) is the NIST-standardised post-quantum key-encapsulation mechanism derived from CRYSTALS-Kyber. Wallets use KEMs for encrypted channels (host↔device, cloud backup, seed transport), not for on-chain signatures. ML-DSA (FIPS 204) is the signature standard that would replace ECDSA on-chain. A truly quantum-safe wallet needs both: ML-KEM for confidentiality of key material in transit, and ML-DSA (or SLH-DSA) once chains accept post-quantum signatures.
Should I buy a Trezor or Ledger for quantum-safety reasons?
Buy the hardware wallet that fits your threat model today — supply-chain integrity, secure element, open-source firmware, recovery workflow. Quantum resistance is a firmware/protocol question, not a hardware one, so any modern device with an active firmware channel can add post-quantum signatures later. This site does not give purchase advice.
Are there any 'quantum-safe' software wallets?
A handful of wallets on post-quantum chains (QRL, IOTA's Chrysalis+, some experimental Ethereum L2 prototypes) sign with hash-based schemes like XMSS or SLH-DSA. These are usable today for those specific chains but do not make Bitcoin or Ethereum quantum-safe. See /quantum-crypto-rankings for the scoring of the chains themselves.
What can I do while waiting for wallets to add PQC?
Use fresh, never-spent addresses for cold storage, sweep reused UTXOs, keep firmware current, and avoid parking large sums on address types whose public key is already published on-chain. Run a specific address through /wallet-scanner to see rules-based exposure.