# The quantum-resistance checklist

> Seven verifiable tests that separate a genuinely quantum-resistant blockchain from a marketing claim — and how to check each one yourself.

"Quantum-resistant" has become a marketing sticker. Dozens of projects use the phrase; only a handful actually meet it. The problem is that the sticker is unfalsifiable on its own — so this page gives you the falsifiable version. Seven tests, each one you can verify yourself against public documentation and source code. A chain that passes all seven is genuinely prepared; a chain that fails the first one is not quantum-resistant no matter what its homepage says.

## The one test that matters most

Before the other six: **what signature scheme authorizes a transaction?** This is the whole game, because [Shor's algorithm](/learn/glossary#shor) breaks exactly the math that today's signatures rely on.

| Signature scheme | Type | Quantum-resistant? |
|---|---|---|
| ECDSA (secp256k1) | Elliptic-curve | ❌ Broken by Shor |
| Schnorr / Taproot | Elliptic-curve | ❌ Broken by Shor |
| EdDSA / Ed25519 | Elliptic-curve | ❌ Broken by Shor |
| BLS | Pairing-based | ❌ Broken by Shor |
| RSA | Factoring | ❌ Broken by Shor |
| **XMSS / LMS** | **Hash-based** | ✅ Resistant |
| **SLH-DSA (SPHINCS+)** | **Hash-based** | ✅ Resistant |
| **ML-DSA (Dilithium)** | **Lattice-based** | ✅ Resistant |
| **FALCON** | **Lattice-based** | ✅ Resistant |

If the chain signs with anything in the top five rows, stop here — it is not quantum-resistant, and the rest of the marketing is moot. See [how quantum computers break cryptography](/learn/how-quantum-computers-break-crypto) for why the elliptic-curve schemes all fall to the same algorithm.

## The seven-point checklist

### 1. It signs transactions with a post-quantum scheme

Not "plans to." Not "in a future version." The signature that authorizes a live transaction today must be hash-based or lattice-based. **How to verify:** find the chain's transaction-signing code or spec and look for the scheme name. `secp256k1`, `ed25519`, `schnorr`, or `bls` in the signing path is a fail. `xmss`, `ml-dsa`, `dilithium`, `sphincs`, `falcon`, or `lms` is a pass.

### 2. The scheme is standardized, not homemade

Post-quantum cryptography is subtle, and a custom scheme that hasn't survived years of public cryptanalysis is a liability, not a feature. **How to verify:** the scheme should map to a NIST standard (FIPS 203/204/205, or SP 800-208) or an IETF RFC (e.g. RFC 8391 for XMSS). "Our proprietary quantum-safe algorithm" with no standard reference is a red flag. See [the NIST post-quantum standards](/learn/nist-post-quantum-standards).

### 3. It's live on mainnet — because of "harvest now, decrypt later"

A ledger is permanent. Every public key exposed today is recorded forever, and can be attacked the moment quantum hardware arrives — even years later. A migration *after* that point cannot un-expose those keys. **How to verify:** is the post-quantum signing active on the production chain right now, or is it a testnet demo / whitepaper promise? Only "live now" protects the coins you hold now. See [harvest now, decrypt later](/learn/harvest-now-decrypt-later).

### 4. It protects transactions, not just a side feature

Some chains bolt a post-quantum scheme onto one subsystem — state proofs, light-client bridges, a special key type — while ordinary account signatures stay elliptic-curve. That is a genuine improvement to that subsystem and a genuine *non*-answer for your wallet. **How to verify:** confirm that the scheme protecting your account's spending authority — not some auxiliary protocol — is the post-quantum one.

### 5. It handles public-key exposure sensibly

On most chains, spending a coin reveals your public key forever. Post-quantum design should minimize how long and how widely keys are exposed. Hash-based one-time schemes go further by never reusing a signing key. **How to verify:** does the chain reuse addresses freely with a Shor-vulnerable key sitting exposed, or is key exposure bounded by design? See [one-time signatures and OTS keys](/learn/one-time-signatures-and-ots-keys).

### 6. The hash functions are sized for Grover

[Grover's algorithm](/learn/glossary#grover) gives quantum computers a square-root speed-up against hash functions — a 256-bit hash drops to ~128-bit effective security. That is still strong, but a serious design accounts for it. **How to verify:** the chain uses generous hash sizes (256-bit minimum, larger for long-lived commitments) rather than relying on a slim margin. See [Grover's algorithm and hash functions](/learn/grover-and-hash-functions).

### 7. The claims are specific and checkable

This is the meta-test. A real project tells you *exactly* which scheme, which standard, which parameter set, and where in the code it lives. A marketing claim gives you an adjective. **How to verify:** can you name the scheme after reading their docs? "We use ML-DSA-87 (FIPS 204) for all transaction signatures" is checkable. "Quantum-secure by design" is not.

## Why the checklist beats the sticker

Every one of these tests is falsifiable — you can prove a claim true or false against public sources. That is the difference between engineering and marketing. When you evaluate any chain this way, most "quantum-resistant" claims collapse at test #1, because the chain is still signing with ECDSA or Ed25519. A few pass a subsystem test (#4) but fail on transactions. Very few pass all seven.

For a concrete, side-by-side application of this checklist across well-known chains, see [which blockchains are actually quantum-resistant](/learn/which-blockchains-are-quantum-resistant). For how QRL meets each point in practice, see [why QRL is quantum-resistant](/learn/quantum-resistance-explained).