Will Quantum Computers Break Hedera?

Will quantum computers break Hedera is a question that deserves a precise, mechanism-level answer rather than vague reassurance or sensational warnings. Hedera Hashgraph uses ECDSA over the secp256k1 curve for most accounts, the same signature scheme that underpins Bitcoin and Ethereum. That single fact is the starting point for everything that follows. This article explains how Shor's algorithm threatens that scheme, what conditions would have to be met before Hedera accounts face real exposure, what the realistic timeline looks like, and what HBAR holders and developers can do right now.

How Hedera Secures Accounts Today

Hedera Hashgraph is a directed acyclic graph (DAG) based distributed ledger governed by the Hedera Council. Its native token HBAR and the accounts that hold it rely on public-key cryptography for transaction authorisation.

Supported Key Types

The Hedera SDK and the network's account model support several key types:

• ECDSA secp256k1 — the default for Ethereum-compatible tooling and most wallets that bridge Hedera with EVM ecosystems.
• Ed25519 — an Edwards-curve signature scheme that is faster and slightly more compact than ECDSA secp256k1, and the default when creating accounts through Hedera's native SDK.
• Multi-key and threshold key structures — composite arrangements where M-of-N signatures are required.

Both ECDSA secp256k1 and Ed25519 are classical elliptic-curve schemes. Both are vulnerable to a sufficiently powerful quantum computer running Shor's algorithm.

What ECDSA and Ed25519 Have in Common

The security of both schemes rests on the hardness of the elliptic-curve discrete logarithm problem (ECDLP). A classical computer needs roughly 2^128 operations to break a 256-bit elliptic-curve key, which is computationally infeasible for the foreseeable future on classical hardware. A large-scale fault-tolerant quantum computer, however, can solve ECDLP in polynomial time using Shor's algorithm, collapsing the security margin to something tractable.

---

How Shor's Algorithm Breaks Elliptic-Curve Signatures

Peter Shor's 1994 algorithm showed that a quantum computer can factor large integers and solve discrete logarithm problems in polynomial rather than exponential time. The implications for elliptic-curve cryptography are direct:

1. An attacker observes a public key (which is always visible on-chain when a transaction is broadcast or when an account has ever received funds and its key is registered).
2. They run Shor's algorithm on a fault-tolerant quantum computer to derive the corresponding private key.
3. They sign fraudulent transactions and drain the account.

The critical phrase is "fault-tolerant quantum computer." Current quantum hardware, including IBM's 1,000+ qubit processors and Google's Sycamore chips, cannot run Shor's algorithm against 256-bit elliptic curves. Breaking secp256k1 is estimated to require millions of logical (error-corrected) qubits, whereas today's machines operate with hundreds or low thousands of noisy physical qubits, with error rates that make sustained factorisation of large numbers impossible.

The Difference Between Physical and Logical Qubits

This distinction matters enormously for timeline estimates:

NISQ stands for Noisy Intermediate-Scale Quantum. The gap between NISQ and the fault-tolerant threshold is not a linear engineering problem. It requires advances in quantum error correction codes (surface codes, etc.), qubit connectivity, and coherence times simultaneously.

---

Realistic Timeline: When Could Q-Day Arrive?

"Q-day" refers to the point at which a cryptographically relevant quantum computer (CRQC) exists and could break 256-bit elliptic-curve keys in a practical timeframe. Estimates vary considerably:

• NIST's working assumption (used for PQC migration planning): Q-day is plausible within 10–20 years, though not guaranteed.
• More conservative academic estimates place it beyond 2035–2040, contingent on engineering breakthroughs that have not yet occurred.
• Optimistic private-sector forecasts from some quantum hardware companies suggest potential relevance in the 2030s.

The honest answer is that nobody knows. What is knowable is that harvest-now, decrypt-later (HNDL) attacks are already theoretically active: adversaries with the resources and motive can record encrypted traffic or on-chain data today and decrypt it once a CRQC exists. For most HBAR holders transacting publicly on a public ledger, this is less of a concern than the direct key-compromise scenario, because transaction data is already public. The real risk is private key derivation from observed public keys.

When Does an HBAR Account Become Exposed?

An account's public key is exposed to quantum attack at the moment it is published on-chain, which typically happens when:

• The account is first created and the public key is registered.
• A transaction is signed and broadcast (the public key is included in the transaction).

Accounts that have never sent a transaction are marginally safer in theory, because some wallet implementations only publish the public key on spend. However, on Hedera, account creation itself registers the public key, so all Hedera accounts that have been used should be treated as having exposed public keys.

---

What Hedera Itself Is Doing About Quantum Risk

Hedera's engineering team and the Hedera Council have acknowledged the long-term quantum threat. The relevant actions and positions include:

• NIST PQC monitoring: Hedera's cryptography roadmap references NIST's Post-Quantum Cryptography standardisation project, which finalised its first algorithms in 2024 (ML-KEM, ML-DSA, SLH-DSA).
• Key type flexibility: The account model already supports multiple key schemes, which means adding post-quantum key types at the protocol level is architecturally feasible without a full redesign.
• No deployed PQC yet: As of mid-2025, Hedera does not natively support lattice-based or hash-based signature schemes for standard account keys on mainnet.

The absence of a deployed solution is not negligence. The NIST standards only finalised in 2024, and migration of a live network with billions in value requires extensive testing, governance approval across the Hedera Council's 39 member organisations, and ecosystem-wide SDK updates.

---

What HBAR Holders and Developers Can Do Now

Waiting for a protocol-level solution is not the only option. There are practical steps available at varying levels of effort:

For Individual Holders

1. Monitor Hedera's official roadmap for announcements on PQC key support. When it ships, migrate accounts proactively rather than waiting.
2. Use hardware wallets with strong physical security. This does not solve the quantum problem, but it eliminates a much larger and more immediate attack surface: malware, phishing, and supply-chain compromise.
3. Avoid reusing keys across chains. If a single private key controls Hedera and Ethereum accounts, a compromise on either chain propagates.
4. Diversify custody. Multi-signature and threshold-key setups on Hedera reduce single-point-of-failure risk today, and the same logic will apply to quantum-resistant multi-key setups when they arrive.

For Developers and Enterprise Integrators

• Build key-agnostic abstractions now. Applications that hardcode ECDSA assumptions will be more expensive to migrate. SDKs that treat key types as a parameter are more future-proof.
• Follow NIST SP 800-208 and NIST IR 8413 for guidance on hybrid classical/post-quantum key usage during transition periods.
• Engage the Hedera Improvement Proposal (HIP) process. Community-driven HIPs for PQC support accelerate governance consideration.

---

How Natively Post-Quantum Designs Differ

Understanding the gap between "will eventually migrate" and "built post-quantum from day one" is useful context for evaluating the broader crypto landscape.

Classical networks like Hedera, Bitcoin, and Ethereum were designed when ECDSA was the state of the art. Retrofitting PQC involves:

• Protocol-level changes to transaction formats (PQC signatures are significantly larger than ECDSA signatures, raising bandwidth and storage costs).
• Wallet ecosystem migration across millions of applications.
• Key migration campaigns that can never be 100% complete, leaving some legacy ECDSA accounts permanently exposed.

Projects designed from the ground up with post-quantum cryptography, such as BMIC.ai, which uses lattice-based cryptography aligned with the NIST PQC standards, avoid this migration debt entirely. Signature verification, key generation, and wallet infrastructure are built for the post-quantum threat model rather than patched toward it. This architectural difference does not make established networks like Hedera obsolete, but it does represent a distinct risk profile for users thinking across a multi-decade horizon.

---

Summary: Should Hedera Holders Be Worried?

The honest answer is calibrated concern rather than panic or dismissal.

• Immediate risk: Very low. No CRQC capable of breaking secp256k1 or Ed25519 at scale exists. The hardware requirements remain orders of magnitude beyond current capability.
• Medium-term risk (2025–2033): Low to moderate. Dependent on quantum hardware progress that has not yet occurred but that well-funded programmes are actively pursuing.
• Long-term risk (2034+): Meaningful without migration. If Q-day arrives and Hedera has not deployed PQC key support, or if users have not migrated, exposed accounts could be at risk.

The structural mitigant is that Hedera's account model is flexible enough to support PQC keys at the protocol level. The realistic path is a NIST-aligned upgrade, similar to what NIST has already completed for classical PKI and TLS. The risk is not whether migration will happen, but whether it will be completed in time and whether individual users will act on it.

Holding HBAR without thinking about key security is the same posture most Bitcoin and Ethereum holders take. For most users, the quantum threat sits well behind phishing, exchange insolvency, and smart contract bugs in the hierarchy of near-term risks. The time to start paying attention, however, is before Q-day is announced, not after.