Hedera Post-Quantum Migration: Roadmap, Risks, and Options for Holders

Hedera post-quantum migration is one of the more technically substantive questions facing HBAR holders as quantum computing steadily advances from laboratory curiosity to credible threat. Hedera's hashgraph consensus and account model differ enough from EVM chains that a migration carries its own unique challenges, and the timeline matters: NIST finalized its first post-quantum cryptography (PQC) standards in 2024, giving every distributed ledger a clear benchmark to measure against. This article examines what Hedera has publicly committed to, what a real migration would involve at the protocol level, and what individual holders can do in the interim.

Hedera's Current Cryptographic Foundation

Hedera uses the Ed25519 signature scheme as its primary cryptographic primitive for account key pairs, alongside ECDSA (secp256k1) support added later for EVM-compatibility on Hedera Smart Contract Service. Both schemes rely on elliptic-curve discrete logarithm problems, which are vulnerable to Shor's algorithm running on a sufficiently powerful fault-tolerant quantum computer.

Key facts about the current stack:

• Consensus layer: Hashgraph Byzantine Fault Tolerant (aBFT) consensus is not itself cryptographically broken by quantum attacks. The *consensus mechanism* is not the threat surface.
• Signature scheme: Ed25519 and ECDSA keys are the threat surface. A cryptographically relevant quantum computer (CRQC) could derive a private key from a public key, allowing theft of any funds held in an address whose public key has been exposed on-chain.
• Account model: Hedera uses named accounts (0.0.XXXXX) rather than raw public-key-derived addresses. This abstraction actually offers a small structural advantage: account keys can be rotated without changing the account identifier, a property most UTXO chains lack.
• Multi-sig and threshold keys: Hedera natively supports complex key structures, including key lists and threshold signatures, which can assist a staged migration.

Why Ed25519 Is Not Quantum-Safe

Ed25519 is considered highly secure against classical computers and is preferred over older ECDSA variants for its performance and resistance to implementation errors. However, "classical security" and "quantum security" are categorically different properties. Shor's algorithm, running on a CRQC with sufficient logical qubits, reduces the discrete-log problem underlying Ed25519 to polynomial time. NIST's own guidance explicitly excludes Ed25519 from its post-quantum approved algorithm list.

The "Harvest Now, Decrypt Later" Risk

The practical risk timeline is not simply "wait until someone builds a CRQC." State-level and well-funded adversaries are already harvesting encrypted and signed data today, intending to decrypt or forge when quantum capability matures. For signed blockchain transactions, the attack vector is simpler: any address that has ever broadcast a transaction has exposed its public key. Dormant accounts holding significant HBAR are therefore at risk even before a CRQC is deployed at scale.

---

Hedera's Public Stance on Post-Quantum: What Is (and Is Not) Confirmed

As of mid-2025, Hedera has no publicly announced, scheduled migration plan to post-quantum cryptography. The Hedera Improvement Proposal (HIP) repository and official blog do not contain a ratified HIP or governance council resolution specifically committing to a PQC migration timeline.

What *has* been acknowledged:

• Hedera engineers have discussed PQC awareness in community calls and technical forums, acknowledging it as a long-term consideration.
• The HBAR Foundation and Hedera council have referenced cryptographic agility as a design goal without specifying delivery dates or target algorithms.
• The Hedera SDK roadmap references continued alignment with evolving standards, but this is boilerplate language shared with most enterprise DLT vendors.

What is not confirmed:

• No specific NIST PQC algorithm (ML-KEM, ML-DSA, SLH-DSA) has been designated for Hedera accounts.
• No HIP draft proposing a concrete migration mechanism has reached public comment stage as of this writing.
• No hard deprecation date for Ed25519 or ECDSA has been set.

This is not unusual relative to other layer-1 networks: Ethereum, Solana, and most other major chains are also in early-stage PQC discussion rather than active implementation. The difference is that some chains have published explicit roadmap items; Hedera has not yet done so publicly.

---

What a Post-Quantum Migration Would Actually Involve

Understanding *what* a migration requires helps holders assess the seriousness and complexity of the task.

Step 1: Algorithm Selection

NIST finalized three primary PQC standards in August 2024:

For account signing, ML-DSA is the most likely candidate for a network like Hedera: it offers the best balance of performance, signature size, and security assumptions. SLH-DSA is more conservative (relies only on hash-function security) but produces larger signatures that would increase state size significantly. ML-KEM is relevant for encrypted communication channels, less so for on-chain signing.

Step 2: Protocol and SDK Changes

A migration would require:

1. New HIP(s) defining the PQC key type, encoding format, and transaction fee adjustments (PQC signatures are larger, so gas/fee models must adapt).
2. Hedera SDK updates across Java, JavaScript, Go, Swift, and other supported languages to generate and handle PQC key pairs.
3. Mirror node and explorer updates to index and display new key types correctly.
4. Consensus node software updates to validate PQC signatures natively.

Step 3: Account Key Rotation

This is where Hedera's architecture offers a genuine advantage. Because accounts have persistent identifiers independent of their keys, rotating a key does not change the account number or disrupt connected applications. The process for an individual holder would look roughly like:

1. Generate a new PQC key pair using an updated wallet or SDK.
2. Submit a `CryptoUpdate` transaction signed by the *current* Ed25519 key, adding or replacing the key with the new PQC key.
3. The old key is removed or demoted; the account continues operating under the PQC key.

This is materially simpler than Bitcoin's model, where PQC migration requires sending funds to a new address type and every on-chain application referencing the old address must be updated.

Step 4: Ecosystem Coordination

Smart contracts on Hedera Smart Contract Service that use ECDSA operations (e.g., `ecrecover`-style patterns) would need separate treatment. DeFi protocols, bridges, and custodial integrations would each require their own migration sprints. Governance council sign-off would be needed for any consensus-breaking change.

---

Challenges Specific to Hedera's Architecture

Council Governance Model

Hedera's governing council (39 global enterprises) introduces a different decision velocity than fully decentralized chains. Changes require council approval and technical consensus, which adds procedural overhead but also provides clear accountability. A PQC migration, being a consensus-breaking change, would require a supermajority council vote and coordinated node software upgrades across all permissioned nodes.

Fee Model Sensitivity

Hedera's fee structure is denominated in USD-equivalent HBAR at fixed, predictable rates, one of its selling points for enterprise users. PQC signatures (especially ML-DSA at ~2.4 KB versus Ed25519's 64 bytes) increase transaction payload sizes by roughly 37x for the signature alone. This would require a re-calibration of fee tables to avoid dramatically increasing costs for routine transactions.

Hashgraph State Size

A full network state migration, where every account's stored key is updated to a PQC key, would materially increase state size. Hedera's gossip-about-gossip protocol is optimized for speed and low overhead. Engineering teams would need to benchmark PQC signature verification latency at Hedera's target throughput (10,000+ TPS) before committing to a specific algorithm.

---

Interim Options for HBAR Holders

Until a formal migration path is announced and implemented, holders can take practical steps to reduce quantum exposure:

Reduce Public-Key Exposure

• Avoid reusing addresses unnecessarily. Accounts that have never broadcast a signed transaction have not yet exposed their public key on-chain. Keeping holdings in "cold" accounts that have never transacted is the closest analogue to Bitcoin's P2PKH protection.
• Use Hedera's key rotation proactively. If a migration is announced, rotating your key before the deadline is straightforward. Holding keys in threshold or key-list structures now means rotation can be done with partial authorization, reducing single-key risk.

Use Hardware Wallets With Strong Classical Security

No consumer hardware wallet currently supports PQC key generation for Hedera. However, maintaining keys on hardware devices (Ledger support for HBAR exists via the Hedera Ledger app) reduces the classical attack surface and keeps private keys offline until quantum-capable hardware wallets emerge.

Monitor the HIP Repository

The most reliable early-warning signal is the Hedera Improvement Proposals GitHub repository. Any formal PQC migration proposal will appear there before it reaches mainnet. Watching this repository for new drafts tagged with cryptography or security is a direct line to official plans.

Consider PQC-Native Custody Solutions

For holders with significant positions, exploring wallets and custody platforms that are already building post-quantum infrastructure is a prudent hedge. Projects like BMIC.ai are building quantum-resistant wallet infrastructure using lattice-based cryptography aligned with NIST PQC standards, providing an example of what purpose-built PQC custody looks like at the product level.

---

Comparing Hedera's PQC Readiness to Peer Networks

The table illustrates that Hedera is not uniquely behind on PQC, but it is also not ahead. Its architectural advantage on key rotation is a genuine differentiator that could make the eventual migration smoother than on UTXO chains.

---

What Would Accelerate Hedera's Migration Timeline?

Several external factors could push Hedera's governing council to prioritize and publish a PQC roadmap sooner:

• Quantum computing milestones: Announcements of logical qubit counts approaching the 4,000-logical-qubit threshold (a rough estimate for cracking 256-bit elliptic curve keys) would create urgency across the entire industry.
• Regulatory pressure: The U.S. Office of Management and Budget (OMB) has mandated federal agencies migrate to PQC by 2035. Enterprise Hedera council members subject to U.S. regulation may advocate for earlier action to protect their own compliance posture.
• Competitor signaling: If Ethereum finalizes an account-abstraction-based PQC path, it creates competitive pressure for Hedera to accelerate its own timeline to retain enterprise clients who benchmark against multiple platforms.
• Insurance and custody requirements: Institutional custodians and DeFi insurance underwriters may begin requiring PQC-compatible key management as a condition of coverage, creating bottom-up demand from the Hedera ecosystem.

---

Summary

Hedera's hashgraph architecture gives it structural tools, particularly persistent account identifiers and native key rotation, that would make a post-quantum migration less disruptive than on many peer chains. The threat from quantum computing is real and specifically targets Ed25519 and ECDSA, the exact algorithms Hedera relies on. However, Hedera has not published a formal PQC migration roadmap or named a target algorithm as of mid-2025.

For holders, the practical response is: keep exposure low on accounts with published public keys, monitor the HIP repository for draft proposals, and understand that when a migration does come, Hedera's key-rotation mechanism means the transition should be relatively smooth compared to UTXO-based chains. The absence of a plan today is not grounds for alarm, but it is grounds for staying informed.