A post-quantum key signs with an algorithm that stays secure against an attacker equipped with a quantum computer.
Keys and algorithms
Keys are the foundation of a chain’s security: funds, consensus votes, and governance are only as safe as the keys that sign for them. Every signature on a Cosmos chain comes from one of four keys, each held by a different party and signing different things:
Consensus params decide which algorithms consensus keys may use on a given chain, while users pick an account algorithm each time they create a key. To check what a chain currently allows and which algorithms its validator set is running, see Enable ML-DSA keys. For information on validator key rotation, see Key rotation.
What post-quantum means
Every algorithm in the stack exceptml_dsa_65 is based on an elliptic curve. A sufficiently powerful quantum computer running Shor’s algorithm breaks elliptic curve cryptography outright: no key size makes a curve safe. Account keys, operator keys, and consensus keys therefore share the same long-term exposure, and when practical quantum hardware arrives, curve-based signatures stop being trustworthy. To counter this, the ml_dsa_65 key algorithm is introduced.
How ML-DSA works
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is NIST’s lattice-based signature standard, published as FIPS 204 in 2024 and the finalized form of CRYSTALS-Dilithium. Instead of deriving security from elliptic curves, it builds keys and signatures on lattice problems, a class of mathematics with no known quantum attack. The Cosmos stack uses the middle FIPS 204 parameter set, ML-DSA-65 (NIST security category 3), as the algorithmml_dsa_65 to implement post-quantum security.
With the addition of this key algorithm, nothing about the signing workflow changes. The keyring generates and recovers an ML-DSA account like any other, and consensus treats an ML-DSA consensus key like any other key type. What differs is the math underneath and the size of the keys and signatures it produces.
Is hashing post-quantum secure?
Yes, the SHA-256 hash function that underpins the Cosmos SDK and CometBFT (block transaction hashes, merkle trees over application state, etc.) are considered post-quantum secure. Unlike RSA and elliptic-curve cryptography, which are broken by Shor’s algorithm, the best known quantum attack against generic hash functions is Grover’s algorithm. Grover’s algorithm provides only a quadratic speedup, reducing SHA-256’s preimage resistance from 256 bits to about 128 bits, which is still considered secure. Collision resistance, the property that matters for merkle trees and transaction hashes, was already about 128 bits classically and is essentially unaffected.Who can adopt ML-DSA?
Only account keys and consensus keys can useml_dsa_65. The node key stays ed25519 and merely identifies a node to its peers, and module accounts and smart contract accounts hold funds without any key at all, so none of them has anything to migrate.
Adoption differs by role. A user can generate a new ML-DSA account and move funds into it at any time, with no chain-level permission required; there is no in-place migration for accounts. A validator migrates its consensus key in place through key rotation, which does require the chain to allow ml_dsa_65 in consensus params first.
When is a chain considered post-quantum?
Consensus security follows voting power. A chain’s consensus becomes post-quantum secure once at least two thirds of voting power signs with post-quantum consensus keys, because two thirds is the threshold an attacker must forge to break finality. Account security is individual: each account is exactly as secure as its own key.The cost of post-quantum keys
Post-quantum security trades larger keys and signatures for quantum resistance. Signatures dominate the added cost because every block commit carries one per validator, so the totals below scale with the validator set. A single ML-DSA signature is about 3,300 bytes, over 50 times the size of an ed25519 signature. Every block stores one per validator, which drives the block-data growth shown below. The example below assumes 100 validators and six-second blocks.
Signing and verification are slightly slower than with
ed25519. This is unlikely to affect most chains.
IBC considerations
A chain migrating to ML-DSA consensus keys must be aware that this change affects IBC verification. Any counterparty chain that verifies an ML-DSA-enabled chain with an07-tendermint light client must be upgraded to CometBFT v0.40 or later. An older client fails as soon as the first ML-DSA validator joins the set, so every counterparty must upgrade to v0.40 before any validator can rotate to ML-DSA.
ML-DSA signatures also enlarge block headers, which enlarges the IBC client updates that carry them. CometBFT v0.40 raises its signature-size limits to accommodate the larger signatures.
EVM chains
Validators on EVM chains can run ML-DSA consensus keys, as on any other chain. User accounts cannot: the EVM requireseth_secp256k1 account keys, and those cannot move to a post-quantum scheme in place.
Ethereum’s path to post-quantum accounts runs through account abstraction instead. EIP-7702 already lets an account delegate to contract code, so a contract can verify a post-quantum signature inside the VM. EIP-8051 proposes a native precompile for ML-DSA verification, and EIP-8141 proposes frame transactions, which let individual accounts adopt new signature schemes. As a fully EVM-compatible ledger, Cosmos EVM conforms to that roadmap and ships user-side post-quantum support as it lands upstream.
Next steps
- Upgrade first; every flow on this page requires SDK 0.55 and CometBFT 0.40. See the release notes.
- Create a post-quantum user account and move funds into it. See Create an ML-DSA account.
- Allow
ml_dsa_65on a new or live chain. See Enable ML-DSA keys. - Learn how rotation works before touching a production validator. See Key rotation.