Cosmos Hub ATOM

Claim: Cosmos Hub has a community forum post (May 2026) discussing quantum risk to validator keys, user accounts, and IBC light-client verification, proposing a gradual migration path.

Coverage basis: Community research proposal; not an official project assessment

Implementation score: 0.25 · Evidence confidence: Medium

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

Quantum blocker: No official cryptographic inventory or quantum threat model has been published by the Cosmos Hub project team.

Assurance: The forum post is a community contribution, not an official project deliverable. Primary source code and specifications confirm the cryptographic primitives but no formal quantum assessment exists.

The forum post identifies secp256k1 accounts, Ed25519 validators, and IBC light-client verification as quantum-vulnerable surfaces. It proposes adding optional PQC in the SDK, hybrid signatures, IBC evolution, and eventual deprecation of legacy paths.

• https://forum.cosmos.network/t/post-quantum-security/16975

Claim: Cosmos SDK and CometBFT source code, encoding specifications, and account documentation are publicly available and confirm classical ECC use.

Coverage basis: Public code and specifications

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: Primary source evidence is strong for the classical cryptographic primitives. No formal quantum-specific evidence record has been compiled by the project.

The public code and specs serve as a de-facto cryptographic inventory for the classical system, but no quantum-specific evidence compilation (e.g., transaction examples showing vulnerable signatures, key-exposure analysis, or reproducible quantum-risk analytics) has been published.

• https://docs.cometbft.com/main/spec/core/encoding
• https://github.com/cosmos/cosmos-sdk
• https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts

Claim: Cosmos Hub uses secp256k1 for all user transaction signatures on mainnet.

Coverage basis: Classical ECC-only; no PQC or hybrid

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All user transaction signatures are secp256k1-only; a quantum attacker can recover private keys from exposed public keys and steal all associated funds.

Assurance: Confirmed by Cosmos SDK source code, package documentation, and account specification. No PQC or hybrid signature support exists on mainnet.

Cosmos SDK supports secp256k1 and secp256r1 for transaction authentication. Neither is quantum-safe.

• https://github.com/cosmos/cosmos-sdk
• https://pkg.go.dev/github.com/cosmos/cosmos-sdk/crypto/keys/secp256k1

Claim: Cosmos Hub accounts expose secp256k1 public keys on-chain when transactions are broadcast. Addresses are derived from public key hashes. No PQ controls exist.

Coverage basis: Long-exposure vulnerability for all transacted accounts

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All accounts that have sent transactions have exposed public keys; quantum key recovery enables theft with no time constraint.

Assurance: ADR-028 specifies address derivation from public keys. The account model is well-documented. No PQ-safe address derivation or key-rotation mechanism exists.

Public keys are included in transactions and exposed on-chain for all accounts that have sent transactions. This creates a long-exposure attack surface for the entire active account base.

• https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts
• https://cosmos-docs.mintlify.app/sdk/latest/reference/architecture/adr-028-public-key-addresses

Claim: CometBFT validator votes and precommits use Ed25519 signatures exclusively.

Coverage basis: Ed25519-only consensus authentication

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Validator consensus signatures are Ed25519-only; quantum forgery could compromise finality and IBC security across all connected chains.

Assurance: Confirmed by CometBFT encoding specification and Tendermint documentation. zip215 verification is specified. No PQC support exists.

Validator keys are long-lived and publicly known. IBC light-client verification depends on validator signatures for trust. Quantum forgery of validator votes would enable cross-chain double-spending and asset theft.

• https://docs.cometbft.com/main/spec/core/encoding
• https://docs.tendermint.com/v0.34/tendermint-core/validators.html

Claim: CometBFT uses SHA-256 Merkle trees (RFC 6962) for block hashes, transaction hashes, validator set hashes, and state commitments. No pairings or KZG commitments are used in the base protocol.

Coverage basis: SHA-256 symmetric hash; quantum-safe against Grover's algorithm

Implementation score: 0.5 · Evidence confidence: High

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

Quantum blocker: IBC light client verification relies on Ed25519 validator signatures — quantum adversary could forge cross-chain trust

Assurance: IAVL tree SHA-256 commitments provide 128-bit quantum security. IBC light client verification spec confirms Ed25519 dependency.

State tree integrity is quantum-safe via SHA-256, but the authorization layer binding state to owners (secp256k1) and IBC trust (Ed25519) are quantum-vulnerable. Partial credit for hash-based state commitments.

• https://docs.cometbft.com/main/spec/core/encoding
• https://github.com/cometbft/cometbft/blob/main/spec/core/data_structures.md

Claim: Cosmos Hub is a transparent Layer 1 blockchain with no shielded transactions, ZK proof systems, note encryption, or privacy layers in its base protocol.

Coverage basis: N/A - no privacy layer exists

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Verified from protocol documentation and account model specification.

• https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts

Claim: CometBFT P2P uses X25519 for key exchange (Station-to-Station protocol), Ed25519 for peer identity, and ChaCha20Poly1305 for transport encryption.

Coverage basis: Classical ECC for key exchange and peer identity

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: P2P key exchange (X25519) and peer identity (Ed25519) are quantum-vulnerable; a quantum attacker could decrypt P2P traffic or impersonate peers.

Assurance: P2P vulnerability does not directly enable asset theft but could facilitate node isolation, eclipse attacks, or mempool manipulation when combined with consensus-layer attacks.

The experimental lib-p2p transport uses go-libp2p with its own identity and secure handshake mechanisms, but the production default remains comet-p2p with X25519/Ed25519. Neither provides quantum-resistant P2P security.

• https://docs.cometbft.com/v0.38/spec/p2p/legacy-docs/peer
• https://docs.rs/cometbft-p2p
• https://docs.cosmos.network/cometbft/latest/docs/experimental/lib-p2p

Claim: Cosmos Hub wallets (Keplr, CLI, Ledger) support only secp256k1 and Ed25519 keys. No PQ or hybrid signing paths exist.

Coverage basis: No PQ wallet/custody path exists

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No wallets, HSMs, or custody solutions support PQC key generation, signing, or verification for Cosmos Hub.

Assurance: The DoraFactory/pqc-cosmos roadmap includes a task for Keplr PQC support but it is not implemented.

Ledger supports Tendermint validator app for Ed25519 signing. No PQC hardware signing path is available.

• https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts
• https://docs.cosmos.network/hub/latest/validators/kms/kms_ledger

Claim: Cosmos Hub has ~$1.0B+ market cap with ~62-63% staked. All value uses secp256k1/Ed25519. No value is quantum-protected.

Coverage basis: 0% coverage; all value quantum-vulnerable

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 100% of value-at-risk is quantum-vulnerable; no migration, freeze, or protection exists.

Assurance: Market cap data is consistent across CoinGecko, CoinMarketCap, Kraken, and Messari (range $1.0-1.15B). Staking data from Coinbase and StakingRewards confirms ~62-63% staked. All accounts use quantum-vulnerable ECC.

All ATOM value, whether liquid, staked, or in treasuries/exchanges, is controlled by secp256k1 or Ed25519 keys. Any account that has ever sent a transaction has an exposed public key. Score per 9.3.1: <25% coverage = 1 point.

• https://www.coingecko.com/en/coins/cosmos-hub
• https://coinmarketcap.com/currencies/cosmos/
• https://www.coinbase.com/earn/staking/cosmos
• https://messari.io/project/cosmos-hub

Claim: No treasuries, exchanges, custodians, bridges, foundations, or major protocols have migrated to PQC keys.

Coverage basis: No critical wallet migration

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No critical wallets, exchanges, or custodians have migrated to PQC.

Assurance: No evidence of any migration activity for any critical wallet category.

• https://forum.cosmos.network/t/post-quantum-security/16975

Claim: No identification, measurement, deprecation, or freeze mechanism exists for quantum-vulnerable accounts.

Coverage basis: No legacy vulnerability management

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No mechanism exists to identify, deprecate, freeze, or migrate quantum-vulnerable accounts.

Assurance: Cosmos Hub has no native concept of UTXOs, but all accounts with exposed public keys are effectively legacy-vulnerable pools.

Cosmos Hub's account model means that any account that has ever sent a transaction has a long-exposure vulnerability. There is no mechanism to force migration, freeze, or deprecate these accounts.

Claim: A community forum post (May 2026) proposes a gradual migration path: optional PQC in SDK → hybrid signatures → IBC client support → decommission legacy paths.

Coverage basis: Community proposal; not official roadmap

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The roadmap is a community research post, not an official project deliverable. No governance proposal, activation criteria, sequencing timeline, or resource allocation has been approved.

The proposed path identifies key milestones: (1) add optional PQC support to Cosmos SDK, (2) run hybrid accounts/transactions, (3) upgrade chain governance and validator ops, (4) update IBC verification logic, (5) decommission legacy-only paths. This is a design-level artifact.

• https://forum.cosmos.network/t/post-quantum-security/16975

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: No migration accessibility

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No PQ account creation or migration path exists for users.

Claim: No deprecation, freeze, disabled legacy signing, restricted withdrawals, or mandatory migration mechanisms exist.

Coverage basis: No enforcement or coordination

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No enforcement mechanism can prevent users from continuing to use quantum-vulnerable keys.

Coordination across 100+ sovereign Cosmos SDK chains and IBC clients would require substantial governance and technical coordination that has not begun.

Claim: Cosmos Hub has general security incident response capabilities (demonstrated in the Galaxy IBC incident, April 2025) but no quantum-specific vulnerability disclosure or response process.

Coverage basis: General incident response exists; quantum-specific adaptation absent

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: The Galaxy incident demonstrates Cosmos Hub's ability to execute emergency upgrades and coordinate with security researchers and ecosystem partners. However, no quantum-specific incident response playbook, quantum-vulnerability disclosure policy, or security council with quantum expertise has been established.

The Galaxy postmortem identifies the need for a dedicated security council on the Hub, which would be relevant for quantum incident response.

• https://github.com/cosmos/incidents/blob/main/ibc/2025/0409_galaxy.md

Claim: The community hackathon prototype (DoraFactory/pqc-cosmos) integrates CRYSTALS-Dilithium (NIST ML-DSA). No PQC is used in production.

Coverage basis: Prototype uses NIST PQC; production uses only classical ECC

Implementation score: 0.5 · Evidence confidence: Medium

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

Quantum blocker: No NIST PQC algorithm is deployed in production on Cosmos Hub mainnet.

Assurance: Dilithium (ML-DSA) is a NIST-standardized post-quantum signature algorithm. The prototype demonstrates feasibility but is not production-ready. No hybrid construction has been prototyped.

The forum post also discusses ML-KEM, ML-DSA, and SLH-DSA as NIST PQC standards relevant to Cosmos.

• https://github.com/DoraFactory/pqc-cosmos

Claim: No PQC implementation exists in production to audit. The hackathon prototype has not been independently audited.

Coverage basis: No PQC audit exists

Implementation score: 0 · Evidence confidence: High

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

Assurance: General security audits exist for Cosmos SDK and CometBFT but do not cover PQC or quantum readiness.

Claim: Cosmos SDK, CometBFT, and the DoraFactory/pqc-cosmos prototype are open source. No production PQC implementation exists.

Coverage basis: Open-source codebase; prototype PQC code exists

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The core protocol is fully open source. The PQC prototype is also open source but incomplete and unreviewed.

• https://github.com/cosmos/cosmos-sdk
• https://github.com/cometbft/cometbft
• https://github.com/DoraFactory/pqc-cosmos

Claim: The forum post outlines a gradual upgrade path. The hackathon repo identifies tasks for PQC integration. No formal parameter agility specification exists.

Coverage basis: Design-level parameter agility discussion

Implementation score: 0.25 · Evidence confidence: Medium

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

Assurance: No formal specification for parameter negotiation, algorithm downgrade protection, or key migration/rotation exists.

The Cosmos SDK already supports multiple key types (secp256k1, secp256r1, ed25519), demonstrating architectural support for algorithm diversity, but no PQC key type has been integrated into mainline SDK.

• https://forum.cosmos.network/t/post-quantum-security/16975
• https://github.com/DoraFactory/pqc-cosmos

Claim: No PQC implementation exists to evaluate for stateful-signature safety, side-channel resistance, or hardware integration risks.

Coverage basis: Not applicable - no PQC in production

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: Dilithium is a non-stateful signature scheme so state-management concerns are lower than for XMSS/LMS. Side-channel and hardware integration have not been evaluated for Cosmos.

Claim: The DoraFactory/pqc-cosmos repo has defined benchmarking tasks but they have not been completed. No performance analysis exists for PQC in Cosmos Hub context.

Coverage basis: Benchmarking proposed but not executed

Implementation score: 0.25 · Evidence confidence: Low

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

Assurance: The DoraFactory repo lists detailed benchmarking dimensions (key generation time, signature size, TPS impact, CPU/memory/bandwidth, node stability) but none have been executed. PQC signatures (Dilithium-3 is ~3.2KB) would significantly exceed current Ed25519 signatures (64B), potentially impacting block size, mempool, and IBC relay costs.

A forum commenter (Josmar, May 2026) noted that larger PQC signatures and heavier verification costs could noticeably impact fast-finality chains and high-throughput IBC activity.

• https://github.com/DoraFactory/pqc-cosmos