A sufficiently capable quantum computer could break digital-signature systems used by major blockchains. It would not simply “decrypt the blockchain,” erase every block or make hash functions useless overnight. The risk is specific: an attacker able to derive a private key from exposed public-key information could forge signatures and spend assets controlled by that key.
Which cryptography is exposed?
Bitcoin uses elliptic-curve signatures, including ECDSA and Schnorr constructions based on secp256k1. Ethereum externally owned accounts also rely on elliptic-curve signatures. Shor’s algorithm provides a theoretical quantum method for solving the mathematical problems behind widely used public-key systems once a large, fault-tolerant machine exists.
Hash functions face a different quantum speed-up. Grover’s algorithm reduces their effective search security rather than breaking them in the same way. Protocol impact depends on key exposure, address type, transaction timing and the exact attack model.
There is no cryptographically relevant quantum computer today
Current machines are noisy and far below the scale required to attack production blockchain signatures. Estimates of the necessary physical qubits and runtime vary with hardware assumptions, error correction and the target algorithm. Headlines that provide one definitive “Q-Day” date should be treated cautiously.
NIST states in its post-quantum cryptography overview that nobody knows when a cryptographically relevant machine will arrive. The agency nonetheless completed its first three post-quantum standards in 2024 because migration across real systems can take many years.
Why public-key exposure matters
Our Bitcoin public-key and address explainer describes these objects in more detail. Some Bitcoin outputs contain a hash of a public key until they are spent; spending reveals the public key. Other constructions expose key data earlier, and address reuse leaves more time for a future attacker. The Bitcoin transaction guide already recommends avoiding key reuse for privacy and for resilience against unforeseen key-recovery attacks.
That protection is conditional. A powerful attacker might try to derive a key during the period between transaction broadcast and confirmation, and old outputs with already exposed public keys would remain targets. Moving funds eventually requires a protocol-supported resistant destination.
Migration is a governance and engineering problem
NIST standardised ML-DSA and SLH-DSA for quantum-resistant signatures, among other post-quantum tools. A blockchain cannot adopt them merely by changing a wallet library. Developers must define new transaction rules, assess signature size and verification cost, deploy wallet support, coordinate exchanges and give holders a safe path to move assets.
Networks may use hybrid signatures during transition or select algorithms designed for their execution constraints. Every choice brings trade-offs in key size, bandwidth, hardware support and confidence accumulated through cryptanalysis.
What holders can do now
- Do not move funds in response to a viral countdown or an unverified quantum claim.
- Avoid reusing addresses where the network and wallet support fresh ones.
- Keep wallet software maintained and follow protocol developers’ published migration plans.
- Distinguish current theft risks—phishing, seed exposure and malicious approvals—from the future quantum threat.
- For institutions, inventory signature schemes and build crypto-agility before an emergency migration is required.
Quantum computing is a credible long-term cryptographic risk and an active standards problem. It is not evidence that blockchains are currently broken. The responsible position lies between dismissal and panic: measure the exposed cryptography, develop upgrade paths and avoid precise claims unsupported by demonstrated hardware.
