Post Quantum Security

Conversation Security
1

Research results for a possible path to post quantum security for Cosmos:

A realistic post-quantum upgrade path for Cosmos would probably be gradual: first add support for quantum-safe signatures in the SDK, then make chains opt in, then let IBC/light clients evolve to trust those new signatures without breaking old chains. NIST already says organizations should begin migrating now, and its core PQC standards are ML-KEM, ML-DSA, and SLH-DSA.

What has to change

The main risk for Cosmos is not “encryption” in the abstract; it is the signature layer that secures validator keys, user accounts, and light-client verification. Quantum computers would threaten classic signature schemes such as those based on elliptic curves, so the ecosystem would need new signature algorithms that remain secure against Shor-style attacks.
For Cosmos, that means the SDK would need new cryptographic primitives, wallet software would need to generate and store new key types, and node software would need to verify both legacy and post-quantum signatures during a transition.

Likely migration stages

  1. Add optional PQC support in the Cosmos SDK.
    A community project already proposed integrating CRYSTALS-Dilithium into Cosmos SDK with backward-compatible hybrid support, which is a plausible model for an early transition.

  2. Run hybrid accounts and hybrid transactions.
    In this phase, a transaction or account could require both a classic signature and a PQC signature, which reduces risk while old tooling catches up. That is the same general migration pattern many security teams are discussing elsewhere.

  3. Upgrade chain governance and validator ops.
    Validator sets would need new key-generation, rotation, and recovery procedures, plus audit rules for which signature schemes are acceptable at different heights or on different chains.

  4. Update IBC verification logic.
    IBC relies on light-client verification and signatures for trust, so the protocol would need a way to verify PQC-secured validator sets or proofs, or to support a hybrid trust model during migration.

  5. Decommission legacy-only paths.
    Once quantum-safe adoption is broad enough, chains would phase out old signature-only modes to reduce attack surface. NIST’s guidance is that migration should start well before a cryptographically relevant quantum computer exists.

What IBC specifically needs

IBC is especially sensitive because it is not just “a chain feature”; it is a trust relay between chains. If a quantum attacker can forge validator signatures or compromise light-client assumptions, cross-chain packets and client updates become the weak point.
So for IBC, the practical work is less about changing packet formats and more about changing the cryptographic assumptions behind client verification, validator identity, and upgrade authorization.
That likely means a staged approach where existing IBC stays live while new chains or clients can opt into PQC-compatible verification.

What makes this hard

The hardest part is compatibility. Cosmos has many chains, many wallets, many validators, and many apps, so a clean “flag day” migration would be disruptive.
PQC signatures are also often larger and slower than today’s common schemes, which matters for blockchain fees, block size, and latency. That performance tradeoff is why hybrid and phased deployments are usually discussed first.
A second challenge is governance: Cosmos must coordinate upgrades across sovereign chains rather than one centralized network.

Best-case path for Cosmos

The most practical path is probably: optional PQC in Cosmos SDK, hybrid signatures for a while, IBC client support for the new schemes, and then a slow network-by-network migration.
That would let Cosmos preserve interoperability while moving toward quantum resistance without breaking the current ecosystem.

2 Likes
2

One thing I think will become a major issue during a PQC transition is validator performance overhead.
Larger signatures and heavier verification costs could have a noticeable impact on fast-finality chains and high-throughput IBC activity, especially in ecosystems like Cosmos where efficiency and low latency are critical.

It will be interesting to see how much optimization is possible before hybrid modes become too expensive at scale.

4

Thank you for contributing to this conversation!

1 Like
5

I want to be mindful of the fact that blockchain ecosystems like Cosmos are heavily consensus-driven, so most post-quantum discussions naturally focus on upgrading signatures, wallets, validators, and encryption methods.

Those things matter, but the bigger picture continues to be overlooked.

For effective protection against quantum computing, you don’t just need better locks — you need fewer doors.

That means reducing attack surfaces, minimizing unnecessary complexity, reducing dependency on mutable databases, and collapsing invalid states earlier before they become exploitable later.

The larger and more complicated a system becomes, the more opportunities exist for weaknesses to emerge under more advanced computational models. Post-quantum security can’t be resolved as a cryptography problem alone since it is fundamentally an architectural issue.

Future resilient systems in Cosmos will need to move toward:

  • smaller attack surfaces,

  • more deterministic execution,

  • reduced state complexity,

  • less unnecessary persistence,

  • and more efficient validation models.

This is one of the reasons I created FENS (Flow Efficiency Natural State), a programming language built around deterministic convergence, minimizing unnecessary complexity, and reducing wasted computational traversal wherever possible.

At the end of the day, stronger locks matter. But building systems with fewer doors in the first place matters even more.

1 Like