Inventory clear and reconstructible from CometBFT and Cosmos SDK specs and code plus the live Hub LCD. Upstream-only key types (ML-DSA-65, BLS12-381) are listed with explicit not-on-Hub qualifiers; the Hub's live exposure remains Ed25519 consensus plus secp256k1 accounts, since the running node reports cometbft v0.38.23 / cosmos-sdk v0.53.4, both predating those key types.

No PQ-safe primitive in active use at the chain level.

0 PQ families. Two classical families (Edwards-curve EdDSA, Weierstrass-curve ECDSA), but neither PQ-safe; the diversity rubric counts PQ families.

Ed25519 ≈ 128-bit classical / 0-bit post-Shor; secp256k1 ECDSA ≈ 128-bit classical / 0-bit post-Shor; SHA-256 ≈ 128-bit post-Grover. No NIST PQC category mapped because no NIST PQC primitive is in scope on the Hub; the upstream ML-DSA-65 key type is NIST security category 3 but is not deployed here.

CometBFT ships TLA+ specifications (light-client verification, fork accountability, proposer-based timestamps) with Apalache model-checking reports; the underlying Ed25519 and secp256k1 libraries are standard Go implementations without machine-checked PQ-relevant proofs. Go crypto/ed25519 is constant-time; secp256k1 uses the decred dcrec v4 library, known constant-time, with lower-S enforcement at verification. Tier 1 (mature classical EC + SHA-2). No PQ implementation on the Hub.

cosmos1… accounts derive from the secp256k1 pubkey hash (RIPEMD-160(SHA-256(compressed pubkey)), per ADR-028). The pubkey is published on-chain on first outbound tx, so any account that has ever signed has its pubkey publicly recorded, Shor-forgeable post-CRQC.

Accounts that have never signed retain pubkey-hash protection; accounts that signed once retain exposed pubkeys indefinitely. Cosmos Hub mainnet has been live since the cosmoshub-1 genesis of 2019-03-13, so any account that has transacted in more than seven years of history has a revealed pubkey; the fraction of cold supply with revealed pubkeys is not measured in this scan.

Every historical Ed25519 validator vote and secp256k1 account signature is forgeable after CRQC. IBC light-client checkpoints rely on Ed25519 validator-set signatures: a CRQC adversary can forge a valid-looking historical Cosmos Hub header against any Tendermint light client trusting historical validator sets.

CometBFT p2p Secret Connection uses X25519 ECDH key agreement for transport encryption between nodes (Shor-vulnerable), so validator gossip and mempool transport sit fully in classical-DH HNDL scope. Public RPC/LCD endpoints: of the 64 endpoints in the chain registry (59 distinct hosts), 31 negotiated X25519MLKEM768 (hybrid ML-KEM-768 + X25519 TLS 1.3 key agreement) with a capable client during this scan, 25 of those at a CDN edge where the CDN-to-origin hop is unobservable, and 27 negotiated classical X25519 only. That hybrid coverage is a TLS-stack default, not a chain decision, and does not reach validator transport.

Fully transparent ledger; cosmos1… addresses pseudonymous; the transaction memo field is plaintext by design; ICS-20 IBC packet data (denom, amount, sender, receiver, memo) is plaintext JSON, so cross-chain flow is trivially linkable to any passive observer.

The public chain registry lists 34 RPC and 30 LCD endpoints from 33 distinct operators (including Polkachu, Lavender.Five, Allnodes, dRPC, GetBlock, Stakewolle, kjnodes); per-operator traffic share is not publicly measured, so concentration cannot be quantified from public data. Mempool gossip is observable to any validator-grade node; no validator-metadata-retention policy is declared at protocol level.

IBC channels make flows between the Hub and its connected zones directly linkable (81 IBC paths registered in the chain registry; 1,508 IBC light clients on the Hub across 303 distinct counterparty chain IDs, including expired clients); Axelar and IBC Eureka (Hub↔Ethereum) add EVM-side correlation.

Cosmos Hub does not publish encrypted payload data, ZK-shielded transactions, or DL-based ring signatures. Confidentiality risk from Shor on its curves is limited to long-term cryptographic identity correlation rather than payload decryption.

None at protocol level.

Validator key types are a consensus parameter (validator.pub_key_types; live Hub value: ed25519 only) and the Cosmos SDK init command takes --consensus-key-algo (default ed25519; CometBFT v0.38 also supports secp256k1 consensus keys); the Cosmos SDK crypto/keys package is modular. The key-type extension mechanism has been exercised three times upstream in 2026: optional BLS12-381 behind a build flag (CometBFT v0.39.0), then mldsa65 (ML-DSA-65 per FIPS 204) and secp256k1eth (CometBFT v0.40.0, Cosmos SDK v0.55.0), with ML-DSA-65 validator migration riding the new MsgRotateConsPubKey rotation. Still no production key-type swap on Cosmos Hub mainnet within 5 years: gaia pins cometbft v0.38.23 / cosmos-sdk v0.53.4, so the demonstrated agility is upstream-library, not Hub-production.

ADR-016 (2019) specified validator consensus-key rotation (MsgRotateConsPubKey, operator-key-signed, fee-limited). The shipped implementation first appears in Cosmos SDK v0.55.0 (2026-07-28): in-place rotation through x/staking with a key_rotation_fee parameter, a once-per-unbonding-period limit, and a two-height application delay; the Hub's pinned v0.53.4 has no MsgRotateConsPubKey, so Hub validators cannot rotate consensus keys in place today. x/authz (delegated authorization) and x/feegrant (fee delegation) are live on the Hub. The official Cosmos SDK post-quantum-keys documentation describes an ML-DSA-65 (FIPS 204) migration path at the account layer (create a new ML-DSA-65 account and move funds; no in-place account migration; no chain-level governance required) and at the validator layer (governance-gated enablement of ml_dsa_65 in consensus params, then per-validator rotation); both require SDK v0.55 / CometBFT v0.40, which the Hub does not run. No native account abstraction comparable to ERC-4337 / EIP-7702 / Starknet AA.

23 governance-passed Gaia software-upgrade proposals between Proposal 924 (v17, May 2024) and Proposal 1049 (v27.6.0, July 2026), a roughly monthly cadence through 2026 (v27.0.0 through v27.6.0 between February and July 2026), each via on-chain governance with a 7-day voting period (expedited: 3 days). v19.2.0 (2024-09-04) was a mandatory height-coordinated point release fixing an Interchain Security bug without a separate governance vote. Strong execution cadence. Contested ATOM 2.0 proposal (Proposal 82, November 2022) was rejected on-chain, a successful adversarial-coordination data point in itself.

Released upstream code (CometBFT v0.40.0 / v0.38.26, Cosmos SDK v0.55.0) supports Ed25519 and ML-DSA-65 (FIPS 204) validator keys coexisting in one validator set behind governance-gated consensus params (pub_key_types may list both), so network-level classical/PQ coexistence is shipped machinery, no longer merely architecturally constructible. The official documentation describes ML-DSA-65 as a single-algorithm key type adopted per key, not a classical+PQ hybrid composition on a single signature; no hybrid combiner spec or ADR exists anywhere in the stack, and none of this code is in the Hub's pinned build. DoraFactory's external tendermint-pqc research fork (Dilithium replacing Ed25519 outright, not hybrid) is superseded by the canonical upstream support.

N/A by default, no stateful hash scheme in scope; stateless schemes score full per v3.1 rubric.

N/A. Cosmos Hub uses Ed25519 non-aggregating signatures at consensus per CometBFT default. The historical Tendermint BLS-aggregation feature request (tendermint/tendermint#1319, opened 2018-03-16) was closed as not planned in October 2023; CometBFT v0.39.0 later added an optional BLS12-381 key type behind a bls12381 build flag (48-byte signatures, 192-byte public keys, requires cgo), so BLS is now optionally available upstream, but it is not enabled in the Hub's build and no aggregation path spanning BLS12-381 or ML-DSA-65 is declared. BLS is not in the Cosmos Hub consensus path. Not scored, so it is left out of the dimension total rather than counted as a zero.

0% of validator votes or account signatures on Cosmos Hub mainnet under a PQC primitive; all 200 bonded validators report Ed25519 consensus keys and the chain's consensus params allow no other type.

ML-DSA-65 (FIPS 204) verification is merged and released in the canonical consensus client: CometBFT v0.40.0 (2026-07-27) adds the mldsa65 validator key type, CometBFT v0.38.26 (2026-08-13) backports ML-DSA-65 public-key decoding and signature verification into the v0.38 line the Hub runs, and Cosmos SDK v0.55.0 (2026-07-28) ships crypto/keys/mldsa65 (confirmed absent at v0.54.4). None of it is in the Hub's deployed build: gaia v27.6.0 and v28.0.0-rc0 pin cometbft v0.38.23 / cosmos-sdk v0.53.4, and the gaia repository has zero ML-DSA or post-quantum issues, pull requests, or changelog entries. DoraFactory's external tendermint-pqc research fork is superseded as the only PQC code in the ecosystem.

All 200 bonded Cosmos Hub validators (the set is saturated at the max_validators = 200 staking parameter) use Ed25519 consensus keys. No validator has registered a PQC consensus key, the live consensus params would reject one, and the Hub's pinned CometBFT v0.38.23 cannot verify one.

VOIDED to 0 per v3.1 rule (5a = 0). No dated, enforcement-mechanism-backed PQC milestones for Cosmos Hub mainnet.

Announced-vs-shipped runs in the honest direction upstream: CometBFT v0.40.0 / v0.38.26 and Cosmos SDK v0.55.0 shipped ML-DSA-65 (FIPS 204) code accompanied by release notes and documentation that describe it as a stack capability, and we found no Cosmos Hub, Interchain Foundation, Cosmos Labs, or Hypha communication in the trailing 12 months claiming Hub quantum-safety on the back of it. Shipped PQC on Hub mainnet: 0. Ratio low, no washing detected. Small deduction retained because third-party conflation of upstream stack support with Hub adoption is a live risk that the Hub's own communications do nothing to correct.

Disclosure exists upstream: the official post-quantum-keys documentation puts ML-DSA-65 (FIPS 204) at 3,309-byte signatures vs 64-byte Ed25519 (~52x raw bytes) with 1,952-byte public keys vs 32 bytes, and per-block validator signature data for a 100-validator set rising from ~6 KB to ~331 KB; CometBFT v0.40.0 raises the default max block bytes and max tx bytes to fit mldsa65 signatures. The multiplier exceeds the 38x scoring threshold, no aggregation, batching, or footprint-mitigation plan is published, and nothing is deployed on the Hub, so the score stays 0.

Top-3 in-ecosystem wallets: Keplr, Leap, Ledger hardware. We found no published PQC roadmap from any of the three. The reference client library (cosmjs, latest release v0.39.0 of 2026-05-04, before the upstream ML-DSA-65 releases) and the Ledger Cosmos app repository each carry zero ML-DSA code as of this scan, the Ledger app despite active maintenance (last pushed 2026-08-05) after the upstream ML-DSA-65 releases; a cosmjs update is a precondition for any wallet built on it to sign under ML-DSA-65.

Top-3 bridge paths for Cosmos Hub flow: classic IBC (07-tendermint light clients, Ed25519 validator-set verification; 1,499 of the Hub's 1,508 IBC clients), IBC Eureka (Hub↔Ethereum over IBC v2: an Ethereum-side Tendermint light client proven in SP1 with a Groth16/PLONK on-chain verifier, a Hub-side 08-wasm Ethereum light client; succinctness, not PQ, the Ed25519 trust root stays), and Axelar (Ed25519 CometBFT consensus; weighted ECDSA secp256k1 multisig at its EVM gateways; classical). None publish a PQC roadmap. The Gravity Bridge IBC client on the Hub expired after an exploit halted that network, and two 2026 recovery proposals (1048, 1050) were rejected, so it is not counted as an active path.

The custodian and exchange surfaces holding the most ATOM bonded stake through exchange-operated validators, per the live validator set: the single largest validator (20.3% of bonded stake), run by a US exchange-custodian; Upbit (Upbit Staking, 7.3%); Kraken (Kraken01, 4.8%); BitGo maintains an ATOM coin module in its public SDK. We found no Cosmos-specific PQC roadmap and no MPC-PQ in production for ATOM signing from any of them.

RPC: 33 operators list public endpoints in the chain registry (including Polkachu, Lavender.Five, Allnodes, dRPC, GetBlock, Stakewolle); none publish a PQC roadmap, but 31 of 64 registry endpoints negotiated X25519MLKEM768 hybrid TLS 1.3 key agreement with a capable client in this scan, 25 of them at a CDN edge, a stack default rather than a provider commitment. HSM/KMS for validator consensus keys: the incumbent remote signer tmkms (YubiHSM2, Ledger, Fortanix DSM and software backends) carries zero ML-DSA code, its latest tag v0.15.0 (2025-11-07) predates the upstream ML-DSA-65 work, its repository was last pushed 2026-04-06, and the Cosmos SDK v0.55 release notes open a six-month deprecation window for it. Its designated successor cosmos-kms (v0.1.0, 2026-07-27) signs ML-DSA-65 consensus keys over privval, with a file backend and merged PKCS#11 and AWS KMS paths, and AWS KMS itself offers ML_DSA_44/65/87 key specs with the ML_DSA_SHAKE_256 signing algorithm. That is one named HSM/KMS vendor with shipped ML-DSA-65 signing, but no Hub validator can use it against the Hub's current build, and no Hub validator is known to run it. TEE attestation: not in the Hub's block-building path.

200 bonded validators, saturated at the max_validators = 200 staking parameter, so a new validator enters only by displacing an incumbent by stake. Live bonded-stake distribution at this scan: the three largest validators by stake (20.3%, 7.3%, 6.4%; the largest is run by a US exchange-custodian, the second by the Korean exchange Upbit, the third by the staking provider Kiln) together hold 34.0% of bonded stake, above the one-third threshold, so the Nakamoto coefficient at the consensus-halt threshold is 3. Client diversity weak: nearly universal CometBFT (no second consensus client).

v19.2.0 (2024-09-04), a mandatory height-coordinated point release fixing an Interchain Security bug, was executed under time pressure without a separate governance vote. Standard cadence: 23 governance-passed Gaia upgrade proposals from Proposal 924 (v17, May 2024) to Proposal 1049 (v27.6.0, July 2026).

Interchain Foundation (foundation); Cosmos Labs (its wholly-owned subsidiary, which maintains the Cosmos SDK, CometBFT and IBC and published the 2026 Cosmos Stack roadmap, which does not mention post-quantum work); Hypha Worker Co-op (testnet and mainnet operations, funded by Proposal 985 for 2025 and Proposal 1043 for the 2026/2027 testnet program). Clear named ownership. No named PQC migration lead for Cosmos Hub.

ATOM 2.0 (Proposal 82, November 2022) rejected on-chain demonstrates governance functions under contested high-stakes proposals. No precedent of a coordinated cryptographic-primitive change while under attacker pressure.

No canary, honeypot, rate-limited spending rule, or cryptographic tripwire on Cosmos Hub.