Post-Quantum Security Review Checklist for Wallets and Dapps
How to use this list
No large quantum computer can break today's signatures yet, and expert timelines vary; see Q-Day explained. This checklist is about being ready, not panicking. Work through it per product, record answers, and revisit it when standards or your chain's plans change. It is educational and not a security audit or financial advice.
1. Inventory
- List every use of public key cryptography: wallet signing, account recovery, API auth, webhooks, JWTs, app updates, TLS to every backend and third party.
- Record the algorithm, library, version and key lifetime for each.
- Mark which keys protect long-lived secrets. Data recorded now can be decrypted later (harvest now, decrypt later).
2. Key exposure
- Does your design publish public keys on-chain or in logs before funds move? Read exposed public keys and address reuse.
- Do you encourage address reuse? Fresh addresses limit exposure on chains that hash the key.
- Are seed phrases and private keys handled only on-device, never logged, and never sent to your servers? See seed phrases and private keys.
- For custody products: how many accounts have exposed keys, and how would you contact or migrate those users?
3. Signature agility
- Can your wallet or SDK support a second signature type without a rewrite? Is the algorithm named in a field rather than assumed? See crypto agility in code.
- Does your contract or program verify signatures through a replaceable module, or is the scheme baked in?
- Does your transaction format reserve room for different key and signature lengths?
- Have you read your chain's published plans? The Solana Foundation reported that the Anza and Firedancer validator client teams independently concluded Solana needs a compact post-quantum signature scheme and selected Falcon, with a staged plan: continue research, adopt for new wallets if the threat becomes credible, then migrate existing wallets. These are plans, not deployed changes. See Ethereum and Solana plans and Bitcoin BIP-360 and BIP-361.
4. Size, cost and UX
- Recompute transaction size, storage, fees and QR or deep-link limits using the numbers in signature sizes and block space. Reported ML-DSA-44 signatures are 2,420 bytes versus 64 to 72 for ECDSA.
- Test hardware wallets and mobile devices for memory and speed. Hardware signers may have strict limits.
- Check that your UI can display, copy and verify longer addresses or identifiers if the scheme changes them.
5. Libraries and transport
- Update TLS libraries and runtimes. OpenSSL 3.5, Go 1.24 and recent browsers enable hybrid key agreement by default. See trying post-quantum TLS.
- Review any dependency flagged as experimental. The library maturity guide explains which are fit for production.
- Do not ship pre-standard or research-only code paths to protect user funds.
- Test for handshake failures from larger key shares in your CDN, proxy and mobile networks.
6. Stateful and one-time schemes
- If you consider XMSS, LMS or Winternitz-style schemes, answer who owns the counter, how rollbacks are prevented, and what happens on backup restore. See hash-based signatures for builders.
- If you adopt a one-time design, make sure the program forces a fresh key after every use.
7. Upgrade and incident plan
- Define the trigger for migrating: standards finalized, chain upgrade shipped, or a credible threat advisory. Government timelines are in government deadlines.
- Test key rotation and a staged rollout with a rollback.
- Check upgrade authority keys. The vault README notes a program whose update authority is an ordinary key can still be at risk.
- Prepare user messaging in plain language. Be wary of copycat scams: quantum-proof coin scams spike whenever the topic is in the news.
8. Evidence and review
- Add tests that fail if a new algorithm is added without test vectors.
- Get an independent review before any custody change. Cloudflare recommends keeping software current, automating certificate issuance and being able to install multiple certificates.
- Track your answers with the company migration checklist.
Sources and further reading
- Solana Foundation: quantum readiness
- solana-winternitz-vault README (Dean Little)
- PostQuantum.com: fixing Bitcoin, signature sizes and throughput
- Cloudflare blog: state of the post-quantum Internet in 2025
- OpenSSL 3.5 series release notes
- Go 1.24 release notes (crypto/mlkem, X25519MLKEM768)
- NIST: stateful hash-based signatures (SP 800-208)
- RFC 10033: hash-based signatures, state and backup management
Reported as of 2026-10-09. Library versions, defaults and standards status change often, so check the primary documents and test on your own stack before relying on anything here. Nothing here is financial advice or a security audit. The QNT memecoin is independent of Quantinuum Ltd, the real company, and of every project, library, lab and chain named on this page.
Frequently asked questions
What is the first step in a post-quantum review?
Make an inventory of every place you use public key cryptography, with algorithm, library, version and key lifetime.
Do wallets need to change signatures today?
Not necessarily. Most chains have not shipped post-quantum signatures, and plans are staged. The work today is inventory, agility and avoiding avoidable key exposure.
Is post-quantum TLS enough to protect my dapp?
It protects the transport against later decryption but does nothing for on-chain signatures or exposed keys.
Where do I read my chain's plans?
Check the official foundation and improvement proposal pages for the chain, and see our Ethereum and Solana guide for a summary as of this date.
Keep reading
- A Plain English Post-Quantum Migration Checklist for Companies
A step by step checklist any company can follow to get ready for post-quantum cryptography, including how banks and financial firms are prioritizing. - Exposed Public Keys and Address Reuse: Who Is Actually Vulnerable to Quantum?
Why some coins are more exposed to a future quantum attack than others, and how address reuse and Taproot play into it. - Ethereum and Solana Post-Quantum Plans: What Is Real in 2026
Ethereum's four-part quantum roadmap and Solana's Winternitz Vault and testnet work, with dates and honest caveats. - Post-Quantum Signature Sizes and Block Space: Why Blockchains Feel the Squeeze
Post-quantum signatures are many times bigger than today's. Here is what that means for block space, fees and throughput, in plain English. - Crypto Agility Explained: Preparing for Algorithm Change
Crypto agility is the ability to swap cryptographic algorithms without rebuilding a system. Learn why it matters for the post-quantum shift and for blockchains.
All Quantum computing guides | Back to top | Search the site
Main pages: Quantum computing explained | Quantum and crypto | Companies | Quantum news | Glossary