Blockchain signatures, validator keys and commitments rely on cryptography that a sufficiently powerful quantum computer could break. This guide explains what is exposed, why public ledgers raise the risk, and how to plan a coordinated post-quantum migration.
Understanding on-chain quantum security
On-chain quantum security means preparing blockchain signatures, accounts, and supporting infrastructure to withstand attacks from sufficiently powerful quantum computers. The practical goal is to preserve ownership and network integrity while replacing vulnerable cryptography without disrupting transactions. This requires more than choosing a new algorithm: decentralised networks need coordinated migration across wallets, validators, applications, and users. (Post-Quantum Ethereum)
For developers, investors, and security teams, the useful starting point is understanding which components are exposed, and which changes would actually reduce that exposure.
Which blockchain algorithms are vulnerable to quantum attacks?
The principal vulnerabilities lie in public-key algorithms used to authorise transactions and authenticate network participants. ECDSA, elliptic-curve Schnorr signatures, and BLS signatures depend on mathematical problems that a sufficiently capable quantum computer could solve using Shor’s algorithm. Hash functions face a different, more limited type of quantum speedup; these are not interchangeable threats. (BIP-360)
ECDSA and the risk to ownership
The Elliptic Curve Digital Signature Algorithm, or ECDSA, secures transaction authorisation in Bitcoin and standard Ethereum accounts. Its protection depends on the difficulty of deriving a private key from its public key: the elliptic-curve discrete logarithm problem. Shor’s algorithm could make that derivation feasible on a sufficiently large, fault-tolerant quantum computer, allowing an attacker to forge signatures. (BIP-360)
For investors, the concern is unauthorised movement of assets controlled by an exposed key. For chains, the problem extends to coordinating account migration and addressing users who cannot or do not upgrade. Replacing wallet signatures alone also leaves other cryptographic dependencies unresolved. (Post-Quantum Ethereum)
Signatures are not the entire attack surface
Ethereum also uses BLS signatures for validator participation and KZG commitments in its data infrastructure; both involve quantum-vulnerable elliptic-curve mathematics. Bitcoin’s Schnorr signatures likewise do not become quantum-resistant merely because they differ from ECDSA. By contrast, Grover’s algorithm offers a quadratic speedup for generic hash searching rather than Shor’s structural break of public-key systems. (ethereum.org)
A sensible assessment therefore separates transaction authorisation, consensus authentication, commitments, and hashing instead of assigning one blanket vulnerability rating.
Why does a public ledger increase quantum exposure?
A public ledger gives potential attackers persistent access to transaction data and, in some cases, public keys that remain relevant to assets or administrative authority. They can inspect that information without breaching an organisation first. Once quantum key recovery becomes practical, exposed keys could become targets for forged future transactions. (BIP-360)
The exposure depends on account and output design:
Directly exposed keys: Bitcoin pay-to-public-key and Taproot outputs reveal public-key information, creating a potentially long attack window.
Keys revealed during spending: Hash-based address constructions can conceal keys initially, but spending may disclose them. Reuse can leave continuing exposure.
Brief exposure windows: An attacker targeting a newly revealed key while a transaction awaits confirmation would need substantially faster key recovery. (BIP-360)
Transparency makes reconnaissance easy; it does not make every address equally vulnerable. Track whether a key is exposed, whether it still controls value, and how long that control is expected to last.
This is also different from “harvest now, decrypt later”. Blockchain signatures primarily protect authorisation, not secrecy. Recording a transaction does not automatically enable someone to reverse it later; the concern is using a recovered key to authorise new actions. (Post-Quantum Ethereum)
Quantum-resistant cryptography changes the security foundation
Post-quantum cryptography uses algorithms designed to resist both classical and quantum attacks while running on conventional computers. It is distinct from quantum cryptography, which relies on quantum-physical mechanisms. When someone offers a “quantum crypto” solution, establish which meaning they intend before evaluating its relevance to blockchain security protocols. (NIST)
NIST finalised three foundational standards in August 2024:
Standard | Purpose | Relevance to blockchain systems |
ML-DSA, FIPS 204 | Lattice-based digital signatures | A candidate building block for transaction or infrastructure authentication |
SLH-DSA, FIPS 205 | Stateless hash-based digital signatures | An alternative signature foundation based on hash functions |
ML-KEM, FIPS 203 | Key establishment | Protection for supporting encrypted communications, not a replacement for transaction signatures |
These standards address different cryptographic jobs. Selecting a standardised primitive does not automatically establish that an entire blockchain implementation is secure or compatible with it. (NIST CSRC)
For evaluation, ask what an implementation authenticates, how verification is performed, and which legacy authorisation paths remain. A new signature option offers little protection if an attacker can still use an old, vulnerable key to bypass it.
Quantum random number generation is a separate consideration. Better randomness does not remove the mathematical vulnerability that lets Shor’s algorithm recover a private key from a public key. Treat randomness quality and algorithm selection as distinct controls. (NIST)
Migration is a network engineering problem
Traditional cybersecurity protocols can often be upgraded under one organisation’s authority. Public blockchains require coordination across independently operated software and participants, with compatibility and governance constraints. Ethereum’s post-quantum work illustrates this through separate execution, consensus, and data-layer migration efforts rather than a single algorithm swap. (Post-Quantum Ethereum)
Teams should test proposed changes against operational requirements:
Transaction overhead: Measure signature and public-key sizes, storage growth, and propagation costs.
Verification performance: Benchmark ordinary workloads and adversarially expensive inputs.
Wallet continuity: Exercise signing devices, backups, recovery, and account migration.
Authorisation completeness: Check that bridges, administrator keys, and fallback paths receive equivalent attention.
These are acceptance criteria for a migration project, not proof that any particular scheme will meet them.
Quantum error correction belongs on the threat-monitoring side of this work. It encodes reliable logical qubits using noisy physical hardware, helping quantum computers perform longer computations. It does not directly protect a wallet; progress in fault-tolerant computation informs assessments of future attack capability. Raw physical-qubit counts alone are therefore an incomplete security indicator. (arXiv)
How can teams quantify and prioritise quantum risk?
Teams can use quantitative methods to compare exposed assets, migration lead times, and consequences under explicit quantum-capability scenarios. The purpose is to prioritise action under uncertainty, not to produce an authoritative date when blockchain cryptography will fail. Treat probability estimates as assumptions that require review rather than settled measurements.
A practical assessment can follow five steps:
Inventory cryptography. Record algorithms, libraries, key locations, signing services, contracts, and external dependencies. NIST’s migration work emphasises discovering vulnerable cryptography before planning replacements. (NIST CSRC)
Map continuing authority. Identify which exposed keys still control funds, upgrades, withdrawals, or validator participation.
Estimate consequences. Separate directly controlled value from wider operational effects, such as interrupted withdrawals or loss of administrative control.
Model migration time. Include engineering, audits, device support, governance, and user participation, not just coding.
Compare scenarios. Test earlier and later quantum-capability assumptions against the time needed to migrate.
For an internal planning model, compare migration duration plus a safety buffer with each assumed threat horizon. A shortfall identifies a scheduling problem without pretending the horizon is a prediction.
Useful dashboard measures include inventory coverage, exposed high-authority keys, migration-test completion, and unresolved legacy dependencies. Label these as readiness indicators, not probabilities of compromise. Risk management protocols should specify who updates assumptions and what evidence triggers reprioritisation.
Tools and security frameworks need clear boundaries
Cryptographic discovery tools can help identify vulnerable public-key algorithm use and dependent systems. NIST’s National Cybersecurity Center of Excellence has worked with collaborators to demonstrate these capabilities. Such discovery supports an inventory; it is not equivalent to proving a blockchain application quantum-resistant. (NIST NCCoE)
When evaluating tools or services, request documented coverage, exclusions, reproducible findings, and retesting procedures. Ask whether the assessment includes deployed contracts, signing infrastructure, wallet recovery, and third-party dependencies. Require any assurance claim to name the release and components actually assessed.
Existing security frameworks remain useful for assigning ownership, tracking remediation, and maintaining evidence. Add quantum-specific controls to those workflows rather than creating an isolated checklist.
For external planning context, the UK NCSC sets milestones for discovery and initial planning by 2028, priority migration by 2031, and completion by 2035. These are migration targets, not predictions of quantum attack capability or automatic deadlines for every blockchain. (NCSC)
Prepare deliberately, not reactively
Start with a cryptographic inventory and a map of exposed authority. Then benchmark replacement options, rehearse migration, and maintain clear decision triggers. Effective on-chain quantum security comes from connecting sound cryptography with upgradeable systems and coordinated action, not from attaching a quantum-safe label to one component.
Sources
arXiv 2207.06431, Suppressing quantum errors by scaling a surface code logical qubit
NIST NCCoE, Migration to Post-Quantum Cryptography project collaborators
Find out what a quantum computer could break on your chain
QuantSec scans your on-chain and off-chain systems, from signing keys and validator infrastructure to contracts and bridges, for cryptography a quantum computer could break, then delivers a digitally signed report with a prioritised migration plan. When you are ready to act, our team can carry out the post-quantum migration with you.
