Is Hedera Quantum Safe? HBAR and HCS Security in 2026

TL;DR: Hedera Hashgraph uses Ed25519 (default) and ECDSA (secp256k1 and secp256r1) for account signing — all three are elliptic-curve schemes vulnerable to Shor's algorithm. The hashgraph consensus mechanism does not confer any quantum resistance; only the signature scheme matters. The Hedera Governing Council, which includes IBM (a major quantum computing developer), has not announced a post-quantum migration timeline as of 2026.

Hedera's Cryptographic Foundation

Hedera Hashgraph is a distributed ledger that positions itself as a high-performance, enterprise-grade alternative to traditional blockchains. It uses a directed acyclic graph (DAG) structure called a hashgraph rather than a sequential chain of blocks, and its consensus algorithm — asynchronous Byzantine fault-tolerant virtual voting — is distinct from both proof-of-work and proof-of-stake. These architectural differences are real and relevant for throughput and finality. They are not relevant to quantum security.

Quantum resistance in a distributed ledger is determined entirely by the cryptographic signature schemes used to authorize transactions and establish account identities. Hedera supports three options:

Ed25519 is the default signing algorithm for Hedera accounts and is the recommended choice for new deployments. It uses the Edwards-curve Digital Signature Algorithm over the twisted Edwards curve equivalent of Curve25519. Despite being the most modern of the three options — chosen for its speed, small key and signature sizes, and resistance to implementation side-channel attacks — Ed25519 is an elliptic-curve scheme. Shor's algorithm recovers the private key from any elliptic-curve public key in polynomial time. Ed25519's classical security advantages over secp256k1 do not translate into quantum security.

ECDSA with secp256k1 is Hedera's option for interoperability with Ethereum-compatible tooling. secp256k1 is the same curve used by Bitcoin and Ethereum and is quantum-vulnerable by the same mechanism as Ed25519.

ECDSA with secp256r1 (P-256) is Hedera's third option, supporting the NIST P-256 curve used widely in enterprise and government TLS infrastructure. P-256 is quantum-vulnerable like all elliptic-curve schemes.

Hedera also supports multi-key account structures — accounts secured by combinations of keys (threshold signatures, weighted key lists). While multi-key structures complicate attack logistics somewhat, they do not change the fundamental quantum vulnerability: each individual key in a threshold structure is still an elliptic-curve key recoverable via Shor's algorithm.

Why the Hashgraph Algorithm Does Not Provide Quantum Resistance

A common misconception when evaluating Hedera is that its unique consensus mechanism — the hashgraph virtual voting algorithm invented by Dr. Leemon Baird — might provide quantum protection. This misconception is worth addressing directly.

The hashgraph consensus algorithm determines how nodes agree on transaction ordering and finality. It does so through a gossip protocol and virtual voting process that does not itself rely on public-key cryptography in the way a proof-of-stake validator signature does. The algorithm's security properties (asynchronous Byzantine fault tolerance, eventual consistency) are defined relative to a classical adversary model.

However, hashgraph consensus does not protect the transaction authorization layer. When an HBAR holder sends a transaction — transferring HBAR, calling a smart contract, logging a message to the Hedera Consensus Service — that transaction must be signed with the account's private key. The signature is verified against the account's public key, which is stored on the network. This is the quantum attack surface. A quantum adversary who recovers an account's private key from its public key can sign arbitrary transactions on behalf of that account, regardless of how sophisticated the consensus algorithm is. The consensus layer does not validate who owns a key — it only validates that a transaction carries a valid signature for the key registered to an account.

In short: hashgraph is a consensus innovation, not a cryptographic one. It does not change the quantum vulnerability profile of Hedera accounts.

Hedera Services and Their Quantum Exposure

Hedera is not just a token ledger — it provides several higher-level services built on its network, each of which inherits the quantum vulnerability of the underlying signing infrastructure.

HBAR transfers and the token ledger: HBAR is Hedera's native currency with a market cap exceeding $4 billion as of 2026. Every HBAR transfer is authorized by an account signature using Ed25519 or ECDSA. A quantum adversary with the ability to recover private keys from public keys can steal any HBAR held in accounts whose public keys have been broadcast on-chain.

Hedera Token Service (HTS): HTS enables the creation and transfer of fungible and non-fungible tokens natively on Hedera, without requiring smart contracts. HTS token transfers use the same account-level signature infrastructure as HBAR transfers. All HTS tokens are vulnerable to the same quantum key recovery attack.

Hedera Consensus Service (HCS): HCS is a general-purpose message ordering and timestamping service used extensively for enterprise audit trails, supply chain logging, and data provenance. Applications submit messages to HCS topics, and Hedera nodes order and log them with tamper-evident timestamps. HCS messages are signed by the submitting account using classical key infrastructure. A quantum adversary who recovers a submitting account's private key could inject fraudulent messages into HCS topic logs, silently corrupting audit trails that downstream applications treat as authoritative records. For enterprise use cases where HCS serves as a legal or regulatory audit mechanism, this is a significant integrity risk.

Hedera Smart Contract Service: Hedera's EVM-compatible smart contract layer allows deployment of Ethereum-compatible contracts on Hedera. Smart contracts are invoked via account transactions, inheriting account-level quantum vulnerability. Smart contracts that implement their own signature verification logic using secp256k1 (common in Ethereum-ported code) add an additional quantum-vulnerable layer.

Hedera Service	Signing Scheme	Quantum Vulnerable?
HBAR transfers	Ed25519 / secp256k1 / secp256r1	Yes
Hedera Token Service (HTS)	Ed25519 / secp256k1 / secp256r1	Yes
Hedera Consensus Service (HCS)	Ed25519 / secp256k1 / secp256r1	Yes
Smart Contract Service	Ed25519 / secp256k1 / secp256r1	Yes
Governing Council node keys	Ed25519 (primary)	Yes

The Governing Council Structure: Upgrade Pathway and Its Complications

Hedera's governance model differs fundamentally from both open public blockchains and traditional corporate software. The Hedera Governing Council consists of up to 39 term-limited enterprise and institutional members who collectively oversee protocol development, network operations, and strategic direction. Current council members include Google, IBM, Boeing, Deutsche Telekom, LG Electronics, Ubisoft, Standard Bank, and others spanning technology, telecommunications, aerospace, and financial services.

Unlike community-governed blockchains where protocol upgrades require miner or validator consensus from a decentralized set of participants, Hedera protocol changes are decided by the Council. This permissioned governance structure has implications for post-quantum migration:

Coordination advantage: The Council's relatively small, institutional membership means a post-quantum migration decision involves a defined, manageable set of stakeholders rather than a diffuse global validator community. Council members are organizations with security and compliance teams capable of evaluating cryptographic risk — a different decision-making environment than a decentralized protocol forum.

The IBM tension: One of the most notable facts about Hedera's governing council is that IBM is a member — and IBM is simultaneously one of the world's leading developers of quantum computing hardware and software. IBM's quantum computing roadmap includes multi-thousand qubit systems and active progress on fault-tolerant quantum computation. IBM is uniquely positioned to understand, from the inside, what the quantum threat to elliptic-curve cryptography actually looks like and when it might materialize. The presence of IBM on the Hedera Governing Council is therefore an unusual configuration: the same institution that is building the machines that could eventually break Hedera's cryptography is helping govern the network those machines could attack.

This creates an interesting dynamic. IBM's participation could be a driver of earlier-than-average quantum awareness and migration planning within Hedera's governance process. Alternatively, IBM may maintain strict organizational separation between its quantum computing division and its blockchain activities, with no cross-pollination of threat modeling. As of 2026, there is no public evidence of IBM leveraging its quantum expertise to accelerate Hedera's post-quantum preparedness.

Enterprise compliance pressure: Many Governing Council members operate in regulated industries with formal cybersecurity and cryptographic standards requirements. Government agencies in multiple jurisdictions — including NIST in the United States and ENISA in the European Union — have issued post-quantum migration guidance for regulated entities, with implementation deadlines beginning to appear in sector-specific frameworks. If enterprise council members face regulatory requirements to migrate to post-quantum cryptography across their IT infrastructure, Hedera's cryptographic substrate becomes part of that compliance scope. This creates an external pressure toward post-quantum migration that community-governed chains do not face in the same way.

The Harvest-Now-Decrypt-Later Threat for Enterprise HCS Users

For enterprise users of Hedera Consensus Service — which is precisely Hedera's most differentiated and enterprise-focused offering — the harvest-now-decrypt-later (HNDL) threat is particularly acute.

HCS is used for long-lived audit records: supply chain events, pharmaceutical batch logs, financial transaction histories, healthcare data provenance. These records are designed to be authoritative for years or decades. An adversary who collects HCS topic transaction signatures today — alongside the submitting account public keys, which are on-chain — and stores them for future quantum decryption can eventually determine whether any given HCS record was tampered with after the fact, or manufacture fraudulent historical records that appear cryptographically legitimate.

For audit applications where the integrity guarantee is the entire value proposition, this is not a theoretical future concern. It is a present-day data collection problem. The signatures being broadcast to the network today will remain in adversary storage until a quantum computer capable of attacking them exists. For regulated industries with 10-20 year data retention requirements, the window of exposure overlaps substantially with the projected quantum threat timeline.

Hedera's Post-Quantum Roadmap: Current Status

As of October 2026, Hedera has not published a post-quantum cryptography migration roadmap. No Governing Council announcements, Hedera Improvement Proposals (HIPs), or developer blog posts have addressed a planned timeline for introducing NIST PQC algorithm support (ML-DSA, SLH-DSA, ML-KEM). The Hedera documentation does not reference post-quantum considerations for account key management or service security.

Hedera's SDK documentation notes that Ed25519 is the recommended key type for its performance characteristics. No comparison to post-quantum alternatives appears in the documentation.

This absence of public roadmap does not necessarily mean no internal planning is underway — IBM's council membership, in particular, makes it plausible that quantum risk has been discussed internally. But for organizations evaluating Hedera for long-term enterprise deployments, the absence of a public commitment is a material gap in due diligence.

Why Quantum-Safe-by-Default Is the Architecturally Sound Choice

Hedera's situation crystallizes the fundamental challenge facing all pre-quantum distributed ledgers. The enterprise positioning that makes Hedera attractive — long-lived audit records, institutional governance, regulated industry deployments — is also exactly the context where quantum risk is most consequential. Enterprise audit records are meant to survive for decades. Institutional participants have regulatory obligations that extend far into the future. Precisely because Hedera targets the highest-stakes use cases, its cryptographic vulnerability is most material.

The alternative is a ledger that was quantum-safe from its first transaction. QuanChain uses ML-DSA-87 and SLH-DSA in a composite signature scheme — both NIST-standardized post-quantum algorithms — for every account, every transaction, and every block signature from genesis. There is no migration period, no key rotation coordination problem, and no window during which an adversary can collect classical signatures for future quantum decryption. Enterprise audit records written to QuanChain today carry cryptographic guarantees that hold against both classical and quantum adversaries, for the full lifetime of the record.

For organizations in regulated industries evaluating blockchain infrastructure for use cases with 10-20 year horizons — precisely the use cases Hedera targets — the question of whether the underlying cryptography will remain secure for the life of the deployment is not a theoretical edge case. It is a core requirement. Quantum-safe-by-default architecture, rather than a planned-but-unexecuted migration, is the only way to satisfy that requirement with confidence.

See our guide to evaluating quantum-resistant blockchains for a framework applicable to any distributed ledger, and our quantum computing blockchain timeline guide for current estimates of when cryptographically relevant quantum computers may arrive.