What it is. Hedera is a public network run by a council of 34 organizations, mostly large companies plus a few universities, and about 43.8 billion of the 50 billion coins it will ever have are already released.
What we found. Five separate quantum-safety announcements and proposals over the past year have produced nothing running on the live network or on any practice network, the one detailed engineering proposal has not moved since May 2026 and was never adopted, and the network's own public roadmap page still does not list the work.
Why it matters. A Hedera account keeps its number when its key changes, so holders could be moved onto safer keys without ever moving a coin, but no safer key exists to move to and the earliest date the foundation has named for one is 2027.
Nothing post-quantum runs on Hedera mainnet or on any Hedera test network: accounts sign with ECDSA secp256k1 or Ed25519, a standard account's public key sits in ledger state and reads back from the public Mirror Node from creation, so the signature shelf-life clock starts at account creation rather than at first spend, and gossip transport is TLS 1.2 authenticated by a long-lived RSA-3072 sigCert plus an ephemeral EC-384 agrCert over x25519 key exchange. The April 2026 foundation post selects FN-DSA-1024 as the primary user signature with ML-DSA per FIPS 204 as the fallback and targets a new post-quantum key type for 2027, yet FIPS 206 has no published draft, the sole engineering artifact is a documentation-only RFC proposing hybrid X25519MLKEM768 with ML-DSA certificate authentication that has carried no commit since 2026-05-11, and a code search of the official consensus client on 2026-08-19 returned zero hits for X25519MLKEM768, MLKEM768 and mldsa65, so both hybrid gates FAIL, 5a at 0% voids 5d and Migration Stage holds at 2.
Summary
Hedera scores QRI 34, Band 4 Architected, Migration Stage 2. Mainnet signs with ECDSA secp256k1 or Ed25519, links hashgraph history with SHA-384 and encrypts transport with AES-256-GCM. Gossip runs TLS 1.2 with an RSA-3072 sigCert (SHA384withRSA), an ephemeral EC-384 agrCert and x25519 key exchange; the client has also carried an optional Ed25519 node signing schema since November 2025, and no foundation document states which mainnet runs. Every public-key primitive above is Shor-breakable; SHA-384 and AES-256 hold at 192-bit and 128-bit residual under Grover. Account IDs are protocol-assigned numeric tuples, but the account key is queryable from creation; only hollow accounts (EVM-address alias) withhold it until first signature. The April 2026 post declares a transitional AND-composed Ed25519 + FN-DSA event signature and sizes the user key on FN-DSA-1024 (1,280-byte signatures, 20x Ed25519); it selects no KEM, and the ML-KEM-768 choice comes from the May 2026 RFC, which leaves hybrid-versus-pure key exchange and the ML-DSA parameter set open across five phases. Zero post-quantum code is merged, so family diversity scores 0 and both hybrid gates FAIL; the mainnet-traffic cap sets a QRI ceiling of 60 that a raw 34 never reaches, while the Milestone-Discipline cap voids 5d. Architecture-Execution Gap 49.
Forge. Forge-dominant: this chain secures value and operations with signatures, so the principal quantum risk is forgery of spends/attestations once Shor breaks the curve. There is no harvest-now component for forgery; the public key alone enables it, and for standard Hedera accounts that key is public from creation. Decrypt/HNDL applies only to transport/RPC confidentiality.
5 announced → 0 shipped on mainnet under a named primitive. >1.5 deduction.
What the gates say
- Gate 1a, Hybrid signature: FAIL , the April 2026 plan declares a hybrid AND-composition (classical Ed25519 + FN-DSA) for consensus event signing, but states it is transitional and will become pure FN-DSA once the standard is final; it is not deployed, not specified beyond a paragraph, no testnet is live, and the May 2026 transport RFC scopes event/state-signature migration out
- Gate 1a, Hybrid KEM: FAIL , a May 2026 RFC inside the official open-source consensus client proposes hybrid X25519MLKEM768 (X25519 + ML-KEM-768) key exchange with ML-DSA certificate authentication for node-to-node TLS and lays out a five-phase rollout, but it lists hybrid-versus-pure ML-KEM as a pending decision, the PR remains open and unmerged with no commits since 2026-05-11, and no hybrid KEM code is merged or deployed on any Hedera network
- Gate 1b, Commit-to-hash: COND , declared composition is AND, not OR
- Gate 2, Evidence reconstruction: PASS , every sub-score has at least one public artifact, re-fetched in a second independent verification pass on 2026-08-19; Dim 1 and Dim 4 primitive claims were re-derived from the consensus client's own crypto constants, signing-schema enum and TSS design documents at a pinned commit, Dim 5 from pull-request and code-search results against that repository, Dim 2 from live Mirror Node account and supply queries, and Dim 7 from the council site's own member listing; Dim 3 rests on 4 carried-forward artifacts and is the thinnest dimension
- Gate 3, Primitive naming: PASS , every primitive named with mechanism: Ed25519, ECDSA secp256k1, SHA-384, AES-256-GCM, RSA-3072 SHA384withRSA, EC-384, x25519, X25519MLKEM768 (X25519 + ML-KEM-768), ML-KEM-768, FN-DSA/Falcon (FN-DSA-1024 sizing), ML-DSA-44/65/87, and for the TSS design hinTS with Schnorr roster keys plus Groth21 threshold BLS over ALT_BN_128 (BN254)
Burn-vs-rescue policy on file
Declared option f, Undeclared. Council governance structure makes coordinated rescue feasible (option b/c analogues), but no formal policy is published. The migration plan addresses prospective protection (new PQ key type, hybrid event signing) but does not address legacy-key dormant-fund disposition.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 58 / 100
Foundation post (April 2026) names current account-layer primitives explicitly; the May 2026 consensus-client RFC names the gossip-transport stack precisely (RSA-3072 sigCert, EC-384 agrCert, x25519 key exchange, TLS 1.2 with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384), detail the April post did not carry. The TSS path is named across two client design documents: the exact-weight TSS doc specifies the hinTS scheme with Schnorr node keys and a recursive SNARK over the roster history, and the TSS library and ledger-id proposals specify Groth21 threshold BLS requiring bilinear pairings, with ALT_BN_128 (BN254) as the first implementation curve and BLS12-381 named as a possible later switch if EVM precompiles appear. Three points withheld: the stateful/stateless distinction is not declared at protocol level, and no foundation document states which node signing schema (RSA-3072 or Ed25519) mainnet nodes use for events today.
Ed25519 (account/transaction signing; supported key type) · ECDSA secp256k1 (account/transaction signing; recommended key type for new accounts) · SHA-384 (hashgraph history linking, CNSA-aligned) · AES-256-GCM within TLS (encrypted transport; current gossip cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 on TLS 1.2) · RSA-3072 SHA384withRSA (consensus-client node signing key; long-lived gossip sigCert published in the roster as gossip_ca_certificate; the RFC states it is used for event/state signing) · Ed25519 node signing schema (optional in the consensus client since November 2025; mainnet use not stated) · EC-384 (ephemeral gossip TLS agrCert, signed by the RSA-3072 sigCert) · x25519 (classical TLS key-exchange named group, gossip transport) · Threshold keys and key lists (native multi-key per account) · Planned TSS: hinTS threshold signatures plus Schnorr-signed roster history and a recursive SNARK (exact-weight TSS design doc); Groth21 threshold BLS over bilinear pairings in the TSS library design, with ALT_BN_128 (BN254) named as the first curve The foundation post states that an attacker with a CRQC could derive a private key from a public key and forge signatures, and the May 2026 consensus-client RFC states in its motivation that the current gossip TLS stack (RSA-3072, EC-384, x25519) is not quantum resistant. SHA-384 and AES-256 are CNSA-tier choices that retain at least 128-bit security under known quantum attacks.
Ed25519→ Shor-break-via-DL-without-pairingsECDSA secp256k1→ Shor-break-via-DL-without-pairingsRSA-3072 (node signing key / gossip sigCert)→ Shor-break-via-integer-factorizationEC-384 (TLS agrCert)→ Shor-break-via-DL-without-pairingsx25519 (TLS key exchange)→ Shor-break-via-DL-without-pairingshinTS / Groth21 threshold BLS over BN254 and Schnorr roster keys (planned TSS)→ Shor-break-via-pairing / Shor-break-via-DLSHA-384→ Grover-weaken (192-bit preimage residual; the foundation cites the 128-bit figure for quantum collision search)AES-256→ Grover-weaken (128-bit residual)
PQ algorithm families deployed on any Hedera network: 0. Scored 0 per the v3.1 rule that zero deployed families scores zero; the 5-point lattice-only tier requires a lattice family actually in production, and a published intention does not earn family credit. Planned families are lattice-only: the foundation post names FN-DSA (referred to there as FIPS 206; no draft published by NIST) as primary and ML-DSA per FIPS 204 as fallback if FN-DSA standardization is delayed, and the May 2026 consensus-client RFC names ML-KEM-768; NTRU-lattice FN-DSA and module-lattice ML-DSA/ML-KEM are one family at the mathematical-foundation level. SLH-DSA per FIPS 205 is mentioned in the foundation post only as NIST's conservative backup, not as a Hedera fallback; no hash-based (SLH-DSA, XMSS per RFC 8391, LMS per RFC 8554) or code-based (Classic McEliece, BIKE, HQC) fallback is declared for Hedera. The Cryptographic-Diversity Cap (v3.1 lattice-monoculture → QRI ≤ 60) is conditional and does not bind at this score; it fires once a lattice family ships without a second-family fallback.
SHA-384 (FIPS 180-4, CNSA-aligned, 192-bit preimage residual under Grover); AES-256 (CNSA-aligned, 128-bit residual under Grover). The foundation post sizes the planned user key on FN-DSA-1024 (1,793-byte public key, 1,280-byte signature, NIST category 5) without an explicit parameter-set selection statement. The May 2026 consensus-client RFC names ML-KEM-768 (NIST category 3, inside the hybrid X25519MLKEM768 group) for transport key exchange, benchmarked ML-DSA-65 (category 3) for TLS certificate authentication, and lists ML-DSA-44/65/87 (categories 2/3/5) as candidates with the choice pending. Nothing is deployed.
The hashgraph consensus algorithm and its correctness argument have a published academic formalization in the Coq proof assistant; that result covers asynchronous-BFT consensus correctness, not the implementation of any cryptographic primitive, and it is not an audit of the deployed client. Standard Ed25519/ECDSA implementations expected. Hedera SDKs (Java/JS/Go/Rust/Python/C++/Swift). Planned FN-DSA/ML-DSA are stateless. Tier 1 (ECDSA/Ed25519/SHA-2 classical) shipped; tier 3 (NIST PQC) targeted, not shipped; FN-DSA is tier 3b (selected, not final). No public third-party cryptographic audit of a PQ implementation exists because no PQ implementation exists.
2 Quantum Recovery Exposure weight 10% 28 / 100
Hedera account IDs are protocol-assigned shard.realm.num identifiers (for example 0.0.123), not derived from the public key. However, every standard account carries a key property set at creation, and that public key is stored in ledger state and returned by the public Mirror Node accounts API from the moment the account exists. The network documentation states this directly: a public key is visible to other network users through a network explorer or the REST APIs. Two independent live queries of the 100 most recently created mainnet accounts on 2026-08-19 each returned a readable key for 100 of 100 and a null key for none; the key-type mix (ECDSA secp256k1, Ed25519 and threshold/key-list structures) shifts between queries because the newest-account window moves, so only the zero-null-keys result is treated as load-bearing. Under the address-type rule this is exposed-from-creation. The only mitigated-until-spend class is the hollow account (auto-created through an EVM-address alias, the rightmost 20 bytes of Keccak-256 of an ECDSA public key; no key until the owner first signs as fee payer). Native key rotation exists but cannot move an account to a PQ key until a PQ key type ships.
Dormant standard accounts are as exposed as active ones because the key is stored at creation: system and treasury accounts such as 0.0.2 and 0.0.98 expose nested threshold keys whose constituent Ed25519 public keys are readable from the Mirror Node (0.0.98 is a 3-of-5 Ed25519 threshold key). Released supply is about 43.8 billion of 50 billion HBAR (Mirror Node network supply, 2026-08-19). Only never-completed hollow accounts hold value behind a hashed key.
Every historical Ed25519 / ECDSA secp256k1 transaction signature on the ledger remains forgeable post-Shor with respect to its public key, and node event/state signatures (RSA-3072 SHA384withRSA per the consensus client, Ed25519 optional) are forgeable as well. Hashgraph history is hashed with SHA-384 (Grover-resistant chaining) but signature non-forgeability collapses with Shor.
Node-to-node gossip TLS today is TLS 1.2, authenticated by a long-lived RSA-3072 sigCert plus an ephemeral EC-384 agrCert, keyed with classical x25519 (cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384); all Shor-breakable, so gossip traffic recorded today is decryptable once a CRQC exists. Client-to-node connections also use TLS per the foundation post, with no PQ hybrid documented. The May 2026 consensus-client RFC proposes hybrid X25519MLKEM768 as the target key exchange (pure ML-KEM-768 kept as an open alternative) and motivates the change by stating the current stack is not quantum resistant; the harvest-now-decrypt-later reading is ours. The RFC is an open, unmerged proposal, so transport remains exposed. The foundation notes the network's integrity does not depend on TLS; the exposure here is confidentiality. SHA-384 and AES-256-GCM limit symmetric-side Grover exposure.
3 Metadata, Anonymity & Confidentiality weight 13% 37 / 100
Pseudonymous transparent ledger; account IDs, balances, keys and transactions are queryable through the public Mirror Node REST API. The numeric account ID does not hide the transaction graph or the account key.
Read access runs through the public Mirror Node endpoint, third-party mirror/RPC providers (for example Arkhia), and the Hashio JSON-RPC relay; gRPC submission endpoints are the Council-run consensus nodes. We found no published node-metadata retention policy.
HashPort bridge live; Chainlink CCIP lists Hedera mainnet in its directory; LayerZero lists Hedera mainnet in its deployments. A passive observer can correlate source-to-destination flows across these surfaces.
Hedera deploys no ElGamal ring signatures and no EC-curve-based zk privacy primitives at protocol level, so there is no shielded content for Shor to retroactively unmask. Historical Ed25519/ECDSA public keys remain Shor-vulnerable but disclosure was already pseudonymous, not anonymity-protected. SHA-384 hashing limits chain-state hash inversion.
No protocol-level mixnet, shuffle, or commit-reveal mixing.
4 Migration Architecture weight 10% 62 / 100
The account model decouples address from key, so new key types can be added at the HAPI level without breaking existing accounts. The foundation post states that once FN-DSA is finalized a new post-quantum key type can be added to the Hedera API. ECDSA secp256k1 support was added alongside Ed25519 in December 2021, one prior algorithm-addition precedent.
Native key rotation via account-update transactions (keys are mutable; the account ID does not change). Threshold keys and key lists are native, so an account could in principle require both a classical key and a future PQ key (a LayerQu observation, not a stated Hedera plan). No client-layer PQ signing path is documented; the PQ-TLS-for-clients step in the April 2026 post is transport protection, not a user-key migration path. AA-equivalent capability comes from native multi-key, not ERC-4337-style smart accounts.
Council-coordinated network upgrades ship at a steady cadence (mainnet upgrades on 2026-04-28, 2026-05-20, 2026-06-10 and 2026-07-22 per the official release notes). No contested chain split on public record. Coordination authority is centralized in the Council, which is both an asset and a single point of coordination.
The May 2026 RFC in the official consensus client documents a five-phase gossip-transport migration: new TLS 1.3 stack with classical authentication, an optional pq_gossip_ca_certificate roster field, mixed authentication, PQ-required transport, then event/state signing (out of its scope). Phases 1 to 4 carry rollback classifications. It proposes hybrid X25519MLKEM768 key exchange with ML-DSA certificate authentication (ML-DSA-65 benchmarked on BouncyCastle BCJSSE with ACCP) and notes the roster field can help the later event/state-signature migration. Points withheld: hybrid-versus-pure key exchange and the ML-DSA parameter set are listed as pending decisions; the April 2026 event-signing hybrid (Ed25519 + FN-DSA) is described as transitional, with pure FN-DSA as the end state; nothing is merged or deployed and the RFC PR has had no commits since 2026-05-11.
Planned PQ schemes (FN-DSA, ML-DSA) are stateless. Stateful hash-based signature schemes (XMSS per RFC 8391, LMS per RFC 8554) are not in the announced migration. Default full credit per v3.1 rule.
Hashgraph consensus uses virtual voting with gossip-about-gossip; votes are computed locally rather than transmitted, so consensus does not aggregate per-node signatures over a per-block message today. Node event signatures are RSA-3072 SHA384withRSA in the consensus client (Ed25519 optional since November 2025). The TSS path named in the client's design documents is hinTS, a pairing-based BLS threshold signature with silent setup, plus Schnorr-signed roster history proofs and a recursive SNARK; the 2024 design names BN254 as the first curve. The foundation roadmap lists TSS infrastructure improvements as completed in release 0.71 and TSS signatures as in progress; the v0.76.1 release notes record TSS functionality being disabled. No PQ aggregation path exists; the planned path is pairing-based and Shor-breakable.
5 Deployment Execution weight 22% 13 / 100
No PQC primitive shipped on mainnet as of 2026-08-19. Official release notes for v0.72 (mainnet 2026-04-28) through v0.75 (mainnet 2026-07-22) and v0.76 (testnet 2026-08-06, mainnet not yet dated) contain no PQC item; all account/transaction signing remains Ed25519 / ECDSA secp256k1 and gossip TLS key exchange remains classical x25519. The April 2026 migration sequence remains future tense.
Zero PQC code merged into the open-source consensus client as of 2026-08-19: a merged-PR search for PQ/quantum/ML-DSA/ML-KEM/Falcon/Dilithium/Kyber terms returns no PQC feature. The one substantive engineering artifact is an open, unmerged documentation PR (opened 2026-05-07, three commits, last 2026-05-11) carrying a PQ-TLS transition RFC and a benchmark report of hybrid X25519MLKEM768 key exchange with ML-DSA-65 certificate authentication on BouncyCastle BCJSSE + ACCP, tracked by an investigation issue opened 2026-04-08 that remains open. The consensus-side signature-scheme experiment it references exists in the public tree but tests RSA versus Ed25519 node signing; the TLS loopback harnesses and any BCJSSE/ML-KEM code are not in the searchable public tree. Three PRs titled 'Falcon' merged in August 2026 are an internal test-framework codename unrelated to FN-DSA and count as zero PQC. A December 2025 grant to WECAN (post-quantum KYC tooling) and a December 2024 SEALSQ partnership fund off-chain work; chain-client PQC remains at proposal stage.
Council-run consensus nodes sign with classical keys (RSA-3072 SHA384withRSA per the consensus client; Ed25519 optional). No validator-side PQC key adoption.
VOIDED to 0 per v3.1 rule (5a = 0). The April 2026 post publishes a sequenced plan (PQ-TLS nodes, PQ-TLS clients, hybrid event signing, new PQ key type targeted for 2027), but only the last step is dated, and 5d is voided when 5a = 0. As of 2026-08-19 the foundation's public roadmap page lists no PQC item; the only cryptography-adjacent roadmap entry is TSS signatures.
Announced PQC items in the trailing 12 months: WECAN grant (December 2025), consensus-client investigation issue (April 2026), developer-conference cryptography fireside published April 2026, foundation post April 2026, consensus-client PQ-TLS RFC May 2026: 5 announced-side artifacts. Shipped PQ on mainnet: 0. The April post and the May RFC are substantive technical artifacts (specific primitives, migration sequence, handshake benchmarks), so this is announcement overhang, not narrative-only. 9 points deducted.
The foundation post sizes the planned user signature on FN-DSA-1024: 1,280 bytes against 64 bytes for Ed25519, a 20x raw multiplier, and states the maximum transaction size limit will be raised. The planned event-signing hybrid (Ed25519 + FN-DSA) adds both signatures. 20x falls in the 10-38x band. No PQ signature aggregation or weight de-penalization is documented; the planned TSS aggregation is pairing-based.
6 Supply Chain Vendor Readiness weight 22% 20 / 100
Top-3: HashPack, Blade Wallet, Ledger hardware. PQC-roadmap count: 0. The HashPack blog index carries no post-quantum content at the index level; Ledger maintains a Hedera app and carries only its general, chain-agnostic PQC posture, with no Hedera-specific PQ key support. No wallet in the tile documents a plan to support a post-quantum Hedera account key, which is consistent with the fact that no such key type exists to support.
Top-3: HashPort, Chainlink CCIP (Hedera mainnet listed in the CCIP directory), LayerZero (Hedera mainnet listed in its deployments). PQC-roadmap count: 0 Hedera-specific; none has deployed PQC.
Top-3: Fireblocks, BitGo (also a Governing Council member), Anchorage Digital. Hedera-specific PQC roadmaps: 0. The December 2024 SEALSQ partnership runs through The Hashgraph Group and names no custodian and no primitive; SEALSQ's news releases dated 2026-07-06 through 2026-08-18 do not name Hedera. The most recent Fireblocks blog posts (July to August 2026) carry no Hedera- or PQC-specific custody content.
Top-3 RPC: Hedera public Mirror Node, Hashio JSON-RPC relay, Arkhia. HSM: the SEALSQ QS7001 secure element is a SEALSQ product announced in a December 2024 partnership release that mentions Hedera via The Hashgraph Group; that release names no post-quantum signature or KEM primitive for the device (it references CNSA-tier AES-256 and SHA-384 only in general framing) and records no HSM deployment at Hedera consensus nodes, and no Hedera-side confirmation of PQ HSMs at consensus nodes is public. SEALSQ's news-release index for July to August 2026 names Hedera in none of its listed releases.
7 Governance & Coordination weight 8% 51 / 100
Permissioned Governing Council; 34 member organizations listed on the council site as of 2026-08-19 (Aberdeen, Accenture, Arrow, Australian Payments Plus, Avery Dennison, BitGo, Blockchain For Energy, Chainlink Labs, Dell, Dentons, Deutsche Telekom, DLA Piper, EDF, FedEx, Google, Hitachi, IBM, IIT Madras, LG, LSE, Magalu, McLaren Racing, Mondelez, NSE, Nomura, Repsol, ServiceNow, Shinhan Bank, Standard Bank, Swirlds, Tata Communications, Ubisoft, Wipro, Zain). Equal voting rights and term limits per the council site. Low Nakamoto coefficient by design; institutional permissioned governance.
Consistent cadence through the window per the official release notes: mainnet upgrades v0.72 (2026-04-28), v0.73 (2026-05-20), v0.74 (2026-06-10), v0.75 (2026-07-22), roughly monthly, each preceded by a testnet deployment; v0.76 reached testnet on 2026-08-06 with the mainnet date not yet published. All Council-coordinated. No coordinated upgrade under live attack on record.
The April 2026 PQC post is co-authored by three named individuals: the Head of Developer Relations, co-founder Leemon Baird, and Rohit Sinha, Head of Cryptography; Baird and Sinha also headlined a Hedera DevDay 2026 fireside on hashgraph cryptography and post-quantum topics (published on the Hedera channel 2026-04-01), so a named cryptography lead publicly owns the PQC roadmap. The hashgraph algorithm has a named author; the Council provides a published mandate. Five points withheld: no standalone PQ working group with a public charter, and no ratified PQC improvement proposal exists (two third-party PQC proposals were closed without merge, in December 2025 and June 2026).
Council structure designed for coordinated decision-making; multiple Council additions and Council-driven HIP enactments document coordination capability. No precedent of coordinated cryptographic change under active attacker.
No published canary, honeypot, or rate-limited tripwire embedded in consensus; the transport RFC's per-phase rollback classes are rollback, not tripwires.
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
The consensus client's crypto constants define the node signing key as RSA-3072 with SHA384withRSA, and the May 2026 transport RFC describes the RSA sigKey as used for event and state signing; an Ed25519 node signing schema was added to the client as an option in November 2025. The April 2026 foundation post describes the classical leg of the planned hybrid event signature as Ed25519. Which schema mainnet nodes run today is not stated in any foundation document we found. We list both and score both as Shor-breakable.
Foundation post (April 2026) presents FN-DSA as primary PQ signature; CNSA 2.0 specifies ML-DSA. Hedera's stated fallback (ML-DSA if FN-DSA standardization is delayed) reduces this divergence.
The April 2026 post says the FIPS 206 initial public draft is expected soon with a final standard around early 2027. As of 2026-08-19 the NIST post-quantum standardization page lists FIPS 206 as in development and the NIST PQC news feed carries no FIPS 206 draft item. We treat FN-DSA as selected, not drafted, not final.
Architecture is documented at Stage 3 (Architected) quality; caps from Milestone-Discipline (5d voided) and Supply-Chain pull operational stage to 2. The chain card surfaces Stage 2 as the cap-binding output.
The April 2026 foundation post commits to no key-encapsulation mechanism. It lists ML-KEM per FIPS 203 in a general table of NIST standards and cites X25519 plus ML-KEM-768 only as an example of browser deployment, saying Hedera will enable post-quantum key exchange once its TLS libraries support it. The specific choice of hybrid X25519MLKEM768 appears only in the May 2026 consensus-client RFC, which is an unmerged engineering proposal that also leaves hybrid-versus-pure ML-KEM as an open decision. We attribute the KEM choice to the RFC and treat the foundation post as naming no KEM, which is the conservative reading; a reader who credited the post's standards table as a selection would see a more settled plan than the artifacts support.
The foundation post sequences post-quantum TLS for client connections as the second step of the migration, after node-to-node TLS. The only engineering artifact scopes gossip transport between consensus nodes and is silent on client-facing endpoints, and we found no proposal, issue or code covering client-to-node TLS. We cannot confirm whether client-facing gRPC endpoints run the same RSA-3072 / EC-384 / x25519 stack as gossip, so 2d scores the documented gossip stack and flags client transport as undetermined rather than assuming it matches.
The April 2026 foundation post frames the PQC migration as an active, sequenced roadmap; the foundation's public roadmap page lists no PQC item as of 2026-08-19 (the only cryptography-adjacent entry is TSS signatures). Both surfaces are foundation-owned, so this is a within-source inconsistency; it supports keeping the announced-vs-shipped framing conservative.
Delta-QRI under alternative weighting
If a reader credits the numeric account ID as if it hid public keys for typical accounts (the hollow-account behaviour applied to all accounts), 2a/2b would return to about 16/14 and QRI would read about 36; our live Mirror Node queries show keys stored from creation, so we do not. If a reader credited a published lattice-only intention as an algorithm family, 1c would score 5 instead of 0 and QRI would read about 35; we score deployed families only, so a plan earns no diversity credit. Weighting US-federal-aligned families higher would move 1d by about 2 points, shifting QRI by well under 1 point.
Announcement-to-shipped ratio
Announced: 5. Shipped: 0. Ratio: 5.
Tag: >1.5 deduction
Peers in the L1 profile
9 chains closest to Hedera by Stage then QRI.