Hedera HBAR

Claim: Hedera's April 2026 blog post identifies ECDSA secp256k1 and Ed25519 as quantum-vulnerable, confirms SHA-384 and AES-256 as PQ-resistant, and provides a detailed threat model covering attack assumptions, affected layers, and affected assets.

Coverage basis: Official documentation and blog post identifying cryptographic primitives and quantum vulnerability

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary official source; inventory is explicit and comprehensive.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/
• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures
• https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms

Claim: Evidence record includes official documentation, source code repository (Hiero consensus node), mainnet explorer (HashScan), blog posts with algorithm comparison tables, and DevDay 2026 technical presentations.

Coverage basis: Multiple primary sources across docs, code, and presentations

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Source code and mainnet explorer provide verifiable evidence for classical cryptographic claims.

• https://github.com/hiero-ledger/hiero-consensus-node
• https://hashscan.io/
• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures
• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: All Hedera accounts use ECDSA secp256k1 (recommended) or Ed25519 for transaction signing. No PQC or hybrid-PQC signature support exists in production.

Coverage basis: Official documentation and source code confirm ECC-only production spend authorization

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production spend authorization remains entirely ECC (ECDSA secp256k1, Ed25519). All user transaction signing uses quantum-vulnerable classical signatures.

Assurance: Verified from official docs, blog, and open-source consensus node code.

Both supported algorithms are broken by Shor's algorithm. All accounts that have submitted transactions have exposed public keys on-chain.

• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures
• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/
• https://github.com/hiero-ledger/hiero-consensus-node

Claim: Hedera accounts expose ECDSA or Ed25519 public keys on-chain when transactions are submitted. Account model supports key rotation without changing account ID, but no PQ key types exist.

Coverage basis: Official documentation confirms classical key types, exposed public keys, and key rotation capability

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All transacted accounts have permanently exposed classical public keys on-chain. Long-exposure attack surface is universal.

Assurance: Account model's key-rotation capability is a positive structural feature for future migration but provides zero protection today.

Key rotation without account ID change is a genuine architectural advantage for future migration UX.

• https://docs.hedera.com/hedera/core-concepts/accounts/keys-and-signatures
• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures

Claim: Hashgraph consensus events are signed with classical Ed25519. The TSS system uses Schnorr signatures for chain-of-trust proofs and BLS for threshold signatures. No PQC in consensus authentication.

Coverage basis: Official documentation, DevDay 2026 presentations, and TSS design doc confirm classical signature use

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Consensus event signing and TSS proofs rely on quantum-vulnerable classical signatures (Ed25519, Schnorr, BLS).

Assurance: TSS documentation is comprehensive and available in the open-source repository. DevDay 2026 confirms post-quantum transition for TSS is planned but not implemented.

The TSS wraps recursive SNARK proof verifies a chain of classical Schnorr signatures. A quantum adversary could forge these, compromising light-client and bridge verification of consensus state.

• https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms
• https://github.com/hiero-ledger/hiero-consensus-node/blob/main/hedera-node/docs/exact-weight-tss.md

Claim: Hashgraph consensus uses SHA-384 for event hashing, providing 192-bit effective security against Grover's algorithm. This is PQ-resistant. However, TSS chain-of-trust proofs depend on classical Schnorr/BLS signatures for light-client-verifiable state integrity.

Coverage basis: Official documentation confirms SHA-384 usage; TSS design doc confirms classical signature dependency for proofs

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: SHA-384 hashing for event chains and Merkle trees is verifiable from documentation and provides genuine quantum-resistant state integrity for the ledger history. The TSS signature dependency affects light-client and bridge verifiability, not internal consensus state integrity.

Partial credit: core hashing layer is PQ-resistant. TSS proof system for external verifiers (bridges, light clients) remains classically dependent.

• https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms
• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/
• https://github.com/hiero-ledger/hiero-consensus-node/blob/main/hedera-node/docs/exact-weight-tss.md

Claim: Hedera is a transparent public ledger with no native shielded transactions, stealth addresses, zk-proof-based privacy, or confidential asset protocols.

Coverage basis: Protocol architecture: Hedera is a transparent DLT without privacy-specific cryptographic layers

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://docs.hedera.com/hedera/core-concepts
• https://hedera.com/learning/how-hedera-works/

Claim: Node-to-node and client-to-node communication uses TLS with classical key exchange. Node identity in the hashgraph is tied to Ed25519 event signing keys. Hedera states consensus security does not depend on TLS, but node identity authentication uses classical signatures.

Coverage basis: Official documentation confirms TLS usage and classical event signing for node identity

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Hedera states consensus security does not depend on TLS, but node identity authentication (event signing) uses classical signatures. P2P transport security is secondary to consensus authentication, which is scored separately.

P2P TLS upgrade to PQ is planned as a configuration change when TLS libraries support ML-KEM; no implementation exists yet.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/
• https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms

Claim: All wallet, custody, and HSM integrations for Hedera use ECDSA secp256k1 or Ed25519. No PQ-compatible wallet or custody workflows exist.

Coverage basis: Key type documentation confirms only classical key types are supported; no PQ wallet tooling exists

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: AWS KMS tutorial confirms only ECDSA key support for Hedera HSM signing workflows.

Wallet/custody migration is dependent on protocol-level PQC key type support (targeted 2027).

• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures
• https://docs.hedera.com/hedera/tutorials/more-tutorials/HSM-signing/aws-kms

Claim: 0% of HBAR value-at-risk is PQ-protected. All circulating HBAR is held in accounts secured by ECDSA or Ed25519 keys. All accounts that have submitted transactions have exposed public keys on-chain.

Coverage basis: All accounts use classical signatures; no PQC key type exists; no migration has occurred

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path. 0% of value-at-risk is protected.

Assurance: No on-chain analytics measuring exact breakdown of dormant vs. active exposed accounts were located. Nominal circulating supply is treated as fully vulnerable.

Coverage is 0% (less than 25% threshold). Score of 1 applies at the experimental tier per QRI spec section 9.3.1.

• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures
• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/
• https://hashscan.io/

Claim: No evidence that any treasury, exchange, custodian, bridge, foundation, or protocol-controlled wallet has migrated to PQC. All critical wallets use classical signatures.

Coverage basis: No PQC key type exists; migration is not possible

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No exchange or custodian migration attestations exist because protocol-level PQC support does not exist.

• https://docs.hedera.com/hedera/core-concepts/keys-and-signatures
• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: Hedera has publicly acknowledged that all ECDSA and Ed25519 accounts are quantum-vulnerable. However, no measurement, deprecation mechanism, freeze policy, or burn path for vulnerable accounts exists.

Coverage basis: Public acknowledgement exists; measurement and deprecation mechanisms do not

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Public acknowledgement (roadmap/proposal level) earns partial credit. No measurement or deprecation mechanism exists.

Vulnerability is identified in official blog and docs. No on-chain measurement, deprecation deadline, freeze mechanism, or burn policy published.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/
• https://docs.hedera.com/hedera/core-concepts/accounts/keys-and-signatures

Claim: Hedera published a detailed PQC migration roadmap in April 2026 with four sequenced phases: (1) PQ TLS for nodes, (2) PQ TLS for clients, (3) hybrid event signing (Ed25519 + FN-DSA), (4) PQ user key type via HAPI targeted for 2027. Dependencies, activation criteria, and fallback options are documented.

Coverage basis: Official blog post and DevDay 2026 presentation provide explicit sequencing, algorithm selection, and timeline

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Roadmap is detailed, publicly available, and independently verifiable from multiple primary sources. This is one of the most comprehensive PQC roadmaps published by any major DLT project.

The roadmap is explicit about sequencing, algorithm choices, fallback options (ML-DSA if FN-DSA delayed), and dependencies on NIST standardization timelines.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: Hedera's account model supports in-place key rotation without changing account ID. However, no PQ account creation, wallet tooling, custody paths, migration prompts, or user-facing warnings exist today. PQ key type is targeted for 2027.

Coverage basis: Key rotation capability is documented; PQ tooling does not exist

Implementation score: 0.25 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Key rotation capability is a structural advantage. The roadmap design exists but no PQ tooling is available.

Partial credit for documented design feature (key rotation) that will facilitate migration. No PQ wallet, custody, or migration prompt infrastructure exists.

• https://docs.hedera.com/hedera/core-concepts/accounts/keys-and-signatures
• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: No enforcement mechanisms exist. No deprecation, freeze, disabled legacy signing, restricted withdrawals, or mandatory migration deadlines have been published. Existing Ed25519/ECDSA keys will continue working throughout migration per the roadmap.

Coverage basis: Roadmap explicitly states legacy keys continue working; no enforcement mechanism documented

Implementation score: 0 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: The permissive migration model (voluntary rotation, no deadline) means vulnerable accounts can persist indefinitely. Exchange, custody, and bridge coordination for migration has not been evidenced.

No enforcement mechanism means quantum-vulnerable accounts could remain active even after PQC key types become available.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: No evidence of a quantum-specific incident-response playbook, disclosure process, or governance mechanism for quantum-related vulnerabilities was identified.

Coverage basis: No public documentation of quantum-specific IR processes found

Implementation score: 0 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Absence of a public quantum-specific IR process is an assurance gap. Hedera may have internal processes not publicly documented. General security contact and council governance exist but are not quantum-specific.

The Hedera Council governance model provides a structured decision-making framework, but no quantum-specific emergency procedures have been published.

Claim: Roadmap selects NIST-track algorithms: FN-DSA (FIPS 206, pending finalization) as primary, ML-DSA (FIPS 204, finalized) as fallback, and ML-KEM (FIPS 203, finalized) for TLS. SHA-384 and AES-256 are already in production and are PQ-resistant per NIST and CNSA guidance.

Coverage basis: Roadmap documents algorithm selection aligned with NIST PQC standardization

Implementation score: 0.25 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Algorithm selection is well-aligned with NIST standards. SHA-384 and AES-256 are already in production. However, no PQC signature algorithms are implemented—roadmap/proposal level only.

FN-DSA (Falcon) is not yet a finalized NIST standard. The fallback to ML-DSA (finalized FIPS 204) is documented. SHA-384 usage is genuinely PQ-resistant and in production.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: No PQC audit exists. Historical audits (FP Complete 2021, CMU Coq proof 2018, NCC Group 2024) are classical-scope only and do not cover PQC implementations or migration design.

Coverage basis: All existing audits are classical-scope; no PQC implementation to audit

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: FP Complete (2021) covered code quality and HTS; CMU (2018) formally verified ABFT consensus; NCC Group (2024) audited only the Transaction Tool demo app. None are PQC-scoped. The absence of PQC audits is expected given no PQC implementation exists.

Score reflects current state: no PQC implementation exists to audit.

• https://hedera.com/blog/fp-complete-publishes-results-of-independent-3rd-party-audits-of-hedera-platform-and-new-hedera-token-service/
• https://hedera.com/blog/coq-proof-completed-by-carnegie-mellon-professor-confirms-hashgraph-consensus-algorithm-is-asynchronous-byzantine-fault-tolerant/
• https://hedera.com/wp-content/uploads/2025/12/NCC_Group_HederaHashgraph_E017270_Report_2024-11-20_v1.0.pdf

Claim: The Hiero consensus node is open-source (Apache 2.0) under LF Decentralized Trust. However, no PQC implementation exists in the codebase to be open-source or reproducible.

Coverage basis: Classical codebase is open-source; no PQC code exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Current (non-PQC) implementation is open-source and buildable. The subfactor scores the quantum-critical implementation, which does not exist.

• https://github.com/hiero-ledger/hiero-consensus-node

Claim: Roadmap documents fallback from FN-DSA to ML-DSA if FIPS 206 is delayed, and from hybrid to pure PQC signing after standardization. TLS upgrade path via library support is documented as a configuration change.

Coverage basis: Roadmap documents algorithm agility and fallback options

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Parameter agility and fallback strategy are documented in the roadmap but not yet implemented or tested.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: No PQC signature implementation exists to evaluate for stateful-signature safety or side-channel risks. The roadmap acknowledges FN-DSA's floating-point implementation complexity and side-channel risk.

Coverage basis: Roadmap acknowledges implementation risks; no PQC implementation to evaluate

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: FN-DSA's floating-point dependency is a known implementation risk acknowledged in the roadmap. Not applicable to current production since no PQC signatures are deployed. Neither FN-DSA nor ML-DSA are stateful schemes (unlike XMSS/LMS), so stateful-signature safety is less critical for Hedera's planned algorithm choices.

FN-DSA and ML-DSA are stateless schemes; stateful-signature risks are minimal for Hedera's planned algorithms. Side-channel risk for FN-DSA floating-point operations is a genuine concern noted in the roadmap.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/

Claim: Roadmap includes signature size comparison table (FN-DSA: 1,280 bytes, 20x Ed25519; ML-DSA-87: 4,627 bytes, 72x Ed25519) and acknowledges impacts on transaction size, cost, bandwidth, storage, and maximum transaction size limits.

Coverage basis: Blog post provides quantitative size comparison and qualitative impact assessment

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: not applicable

Assurance: Qualitative analysis exists but no formal benchmarks with Hedera-scale transaction volumes, block validation timing, or fee-model impact have been published.

Partial credit for documented awareness and sizing analysis. Formal performance benchmarks at production scale are not yet available.

• https://hedera.com/blog/post-quantum-cryptography-and-blockchain/