This guide separates what secure storage does from what makes assets resistant to a quantum attack, and lays out the practices that reduce exposure. It sits alongside our wider guide to protecting crypto from quantum.
What storage means, and what quantum changes
Storage, in crypto, is about protecting the private key: cold wallets, hardware devices, paper backups, or a custodian's vault. They defend against theft and malware, and against the everyday risk of losing access, which are risks you have to manage in any case.
Having said that, Shor's algorithm is a different kind of threat. It can recover a private key from an exposed public key, so the question it raises has nothing to do with where your key is kept. What's relevant here is whether the matching public key is exposed, and whether the signature scheme is one a quantum computer can break.
Why cold storage and hardware wallets don't make you quantum-safe
This is where the term can trip people up. Keeping a key offline, whether in cold storage or in a hardware wallet, reduces the risk of an attacker copying it. However, keeping a private key offline doesn't prevent a sufficiently capable quantum computer from deriving it from an exposed public key when the signature scheme is vulnerable. This exposure can happen on-chain or through information shared somewhere else. Our quantum-safe wallet guide walks through the same distinction for wallets specifically.
Custody only changes who holds the key. Handing coins to an exchange or custodian moves the key-management burden to them, and it leaves the signature that the blockchain checks before a spend as quantum-vulnerable as before. A custodian may harden its internal controls, or use post-quantum authorization where the network or a smart account supports it, and internal post-quantum approval on its own doesn't change a native account's classical spending rules. Assess the custody system and the on-chain authorization separately. Whether storage is cold or hot, yours or a custodian's, isn't what decides your quantum risk.
Secure storage protects your private key from theft; a quantum attack targets the public key already exposed. Two separate jobs.
What reduces quantum exposure
Two things change your exposure, and a third helps at the margins.
The first is keeping the public key undisclosed. On Bitcoin, fresh P2PKH or P2WPKH outputs hide the key behind a hash until the coins are spent, provided the same key hasn't been disclosed elsewhere. This doesn't pertain to every Bitcoin output: P2PK and Taproot carry a public key the moment funds arrive. Hence, check the output type and the key's disclosure history, and don't lean on an address simply looking fresh or unspent.
Whether a Bitcoin output hides your public key depends on the output type, not on an address being fresh.
Account-based chains follow the same principle. Ethereum-style accounts also hide the public key behind a hashed address until a recoverable signature and its signed message are available. A receiving-only account can keep that protection until it signs a transaction, and the same key signing elsewhere, on another chain or an off-chain message, can disclose it too. Reuse is what weakens this in practice, since an active account signs early and often.
Keeping the key hidden cuts the window for a long-running attack as long as the coins sit unspent. Spending reveals the key, so a fast enough quantum attacker could try to forge a competing transaction before yours confirms. Hidden-key storage lowers exposure without replacing post-quantum authorization.
The second detail is the authorization the ledger enforces. Post-quantum protection needs the network, or a smart account's own rules, to require a suitable post-quantum signature before a spend goes through. Producing one in a wallet isn't enough if a classical signature can still authorize the spend by itself.
Deployed protection comes from networks that already enforce post-quantum signatures, such as QRL's XMSS mainnet, or from suitably implemented smart accounts and application-layer vaults. A migration roadmap describes future protection until the relevant changes are live. A rule that demands both an ECDSA and a post-quantum signature keeps the protection, and one that accepts either leaves a classical bypass.
Finally, the third thing is separation. Keeping long-term holdings in a different account and under a different key from active trading limits the damage any single exposed key can do. It doesn't add post-quantum protection, and it limits how much is riding on any one key.
How soon does this count?
No publicly demonstrated quantum computer can do this today. In September 2026, IonQ published an estimate of 19,397 physical qubits and 25.7 days per attempt to recover a secp256k1 private key on a proposed fault-tolerant trapped-ion machine. IonQ ties that scale to its 2028 hardware roadmap. Neither the machine nor the attack has been demonstrated, and a single attempt isn't guaranteed to succeed.
Other forecasts spread across the 2030s and into the 2040s. QNews keeps a running comparison of Q-Day timelines. An exposed public key can be recorded today and attacked later if the funds are still controlled by that key, and moving funds into sound post-quantum authorization before any compromise removes that spending exposure, even though the old public key stays visible.
The app-layer option, and its limits
A correctly implemented vault can require post-quantum authorization before it releases funds. This guards against a compromise of the ordinary wallet key only if recovery, upgrades, key replacement, and other privileged controls can't bypass the requirement. And the vault still depends on the underlying network's security and availability. For example, on Hyperliquid, HyperEVM shares HyperBFT consensus with HyperCore, so adding a withdrawal check doesn't replace that consensus.
qLABS describes its qVAULT as a non-custodial HyperEVM vault that requires Falcon-based authorization for withdrawals (Falcon is a NIST-selected scheme whose standardization is still underway), with its qONE token paying for the verification. Considering these are product claims, you should check that the relevant audit covers the deployed vault and verifier versions, including the recovery and upgrade controls, and that those controls can't bypass the post-quantum requirement.
qLABS stands to benefit from qVAULT and qONE, so weigh that accordingly before relying on the protection. None of this is supposed to be taken as financial advice.
Also, qVAULT runs on HyperEVM and can't directly protect BTC held natively on Bitcoin. Bitcoin does support scripts and contract arrangements, and what it can't do is run this HyperEVM vault contract. Any protection proposed for native BTC has to be judged against Bitcoin's own spending rules, and wrapping BTC onto another chain adds custody or bridge dependencies that don't automatically protect the underlying Bitcoin. BIP 360 remains a draft proposal which would remove Taproot's key-spending path to reduce long-exposure risk, and it doesn't itself introduce post-quantum signatures or complete protection against attacks during spending.
What 'quantum-safe storage' comes down to
Quantum-safe storage isn't a product that makes an exposed key safe after the fact. It's a handful of practices. Keep public keys undisclosed where the output type allows, and favor assets whose network or account enforces a post-quantum signature. Underneath both is one habit: treating secure storage and quantum safety as two different jobs. Secure storage protects your key from theft today, whereas post-quantum authorization addresses future attacks on spending signatures, provided its implementation and remaining dependencies are secure. You need both, and neither one covers for the other.
FAQ
Is cold storage quantum-safe?
Not by itself. Cold storage reduces the risk of private key theft, but it doesn't prevent quantum key recovery from an exposed public key when the spending scheme is vulnerable. Cold storage and quantum safety solve different problems.
Is a hardware wallet quantum-safe?
Not on its own. A hardware wallet reduces the risk of your key being copied, but keeping it offline doesn't prevent a quantum attacker from deriving it from an exposed public key. It's worth having for everyday security, but on its own, it doesn't provide post-quantum transaction protection.
How do I store crypto to be quantum-safe?
Keep public keys undisclosed where the output type allows it, like fresh P2PKH or P2WPKH addresses on Bitcoin, which hide the key, unlike P2PK or Taproot, which show it. Favor assets whose network or account enforces a post-quantum signature, and on smart-contract chains consider an application-layer vault, checking its audited, deployed contracts and controls first.
Are my coins safe if I never move them?
On outputs that hide the key behind a hash, like Bitcoin's P2PKH and P2WPKH, an address you've never spent from keeps the public key undisclosed, which lowers quantum exposure. P2PK and Taproot outputs show a key from the start, and any earlier spend or reuse can expose it, as can the same key signing on another chain. Spending also reveals the key, so a fast attacker could try to beat your transaction to confirmation. Leaving coins untouched helps, but it's not a guarantee on its own.
When will quantum computers threaten stored crypto?
No one can put an exact year on this. IonQ's September 2026 estimate points to around 2028, and other forecasts stretch across the 2030s and 2040s, and so far, nobody has built the machine or run the attack. Where storage is concerned, the point is simpler. An exposed public key stays visible for good, so what protects you is moving funds into a post-quantum signature before that key could be broken. Even then, the contract and the network it runs on need separate assessment.
qLABS Editorial. Sources are linked inline. See the L1 Quantum Vulnerability Index for our full methodology and conflict-of-interest disclosure.
