---
title: Is Celestia quantum-safe?
chain: Celestia
ticker: TIA
hardy_score: 8.5
rank: 56 of 80
tier: "5: Exposed"
url: "https://hardyindex.com/chains/celestia"
updated: 2026-10-22
reviewed: 2026-11-13
methodology_version: 1.8
---

# Is Celestia quantum-safe?

**Hardy Score 8.5 / 100. Rank 56 of 80. Tier 5: Exposed. Last editorial review 22 October 2026; sources checked 13 November 2026.**

No. TIA accounts sign transactions with ECDSA on the secp256k1 curve and Celestia's validators sign consensus votes with Ed25519, and a sufficiently large quantum computer running Shor's algorithm would break both. Mainnet's consensus parameters, read from public nodes on 22 October 2026, allow Ed25519 as the single validator key type. celestia-app v10.4.0 runs on Celestia's own fork of the Cosmos SDK, at v0.52.12, whose key types are secp256k1, secp256r1, Ed25519 and multisig. The ML-DSA-65 key types that upstream Cosmos SDK v0.55 added in July 2026 are not in it. No Celestia Improvement Proposal addresses post-quantum signatures. The one post-quantum item in Celestia's repositories was a September 2026 celestia-core pull request that would have let Celestia verify other chains' ML-DSA-65 validator keys over IBC; it said Celestia's own validators are Ed25519 only, and it was closed unmerged on 14 October 2026.

> This is a security-readiness assessment, not investment advice.

## Summary

Signs accounts with ECDSA on secp256k1 and validator votes with Ed25519 through its own Cosmos SDK fork, which carries no post-quantum key type, and has no improvement proposal or plan for post-quantum signatures.

## Where we are making a judgement call

Two judgement calls carry this profile. The first is the tier and NIST alignment. In September 2026 celestia-core pull request 3340, which closes triage issue 3229 and says in its own description that it is intended for celestia-app v11, added the ML-DSA-65 key type from upstream CometBFT. A reader who counted that as post-quantum work by people with authority over Celestia would place it in Tier 4, with a deployment score of 2, and could read it as naming a NIST scheme, a NIST score of 3; together those give a Hardy Score of 15.5 rather than 8.5. We do not, because the change existed so that Celestia could verify other chains' ML-DSA-65 validator commits over IBC, the pull request itself says Celestia validators are Ed25519 only, so it is not work on Celestia's own fund-protecting signatures, and it was closed unmerged on 14 October 2026. Nor does the upstream Cosmos SDK's ML-DSA code earn NIST or verification credit here, although the Cosmos Hub profile credits it: the Hub builds on the upstream SDK line maintained by Cosmos Labs, which that profile reads as having authority over the Hub, while Celestia builds on its own fork, at v0.52.12, whose crypto/keys package has no ML-DSA key type, so there is no ML-DSA component in Celestia's stack to align or verify. The second is migration. The score of 2 credits a mechanism that lives upstream, in Cosmos SDK v0.55, rather than in Celestia's own SDK fork. A reader who scores Celestia's own code alone would give a 1 and a Hardy Score of 7.0. We credit it because Celestia already maintains its fork against upstream and ships upgrades through CIP-10, so adoption would be a port rather than new design.

## Score breakdown

| # | Dimension | Score | Weight | Contribution |
|---:|---|---:|---:|---:|
| 1 | Signature scheme | 0/10 | 30% | 0.0 |
| 2 | Deployment stage | 1/10 | 25% | 2.5 |
| 3 | NIST alignment | 0/10 | 15% | 0.0 |
| 4 | Migration path | 2/10 | 15% | 3.0 |
| 5 | Exposure | 2/10 | 10% | 2.0 |
| 6 | Verification | 2/10 | 5% | 1.0 |
| | **Hardy Score** | | | **8.5** |

### 1. Signature scheme: 0/10

Anchor band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.

Celestia accounts sign with ECDSA on secp256k1 and validators sign consensus votes with Ed25519, the single validator key type mainnet's consensus parameters allow. Both are broken by Shor's algorithm, and nothing post-quantum protects TIA on mainnet.

Source: https://celestia-rest.publicnode.com/cosmos/consensus/v1/params

### 2. Deployment stage: 1/10

Anchor band 1: Tier 5: Exposed.

Tier 5: Exposed. The signatures securing TIA are quantum-vulnerable, no CIP addresses post-quantum signatures, and the one post-quantum pull request in Celestia's repositories concerned verifying other chains' validator keys, not Celestia's own, and was closed unmerged. See the caveat below on why this is a judgement call.

Source: https://github.com/celestiaorg/CIPs

### 3. NIST alignment: 0/10

Anchor band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis.

No post-quantum scheme has been named for Celestia's account or validator signatures. ML-DSA-65 appears in Celestia's repositories in a single closed pull request for verifying counterparty chains' validator keys over IBC, which states that Celestia validators are Ed25519 only.

Placement in the band: The floor of the band rather than a 1 or a 2: no scheme has been named for Celestia's own fund-protecting signatures at all. The ML-DSA-65 pull request named a final NIST standard for other chains' keys, which v1.8 does not count, and it was closed without merging.

Source: https://github.com/celestiaorg/celestia-core/pull/3340

### 4. Migration path: 2/10

Anchor band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.

No migration plan exists. A mechanism exists upstream: Cosmos SDK v0.55 adds ML-DSA-65 account and validator keys, and Celestia ships protocol changes through coordinated network upgrades under CIP-10. Celestia's own SDK fork does not carry the ML-DSA code, and nobody with authority over Celestia has proposed adopting it.

Placement in the band: The top of the band rather than a 0 or a 1: working ML-DSA account and validator keys exist in the framework Celestia forks, and Celestia has a defined process for coordinated major upgrades under CIP-10. Not a 3, because no one with authority over Celestia has acknowledged migration as its problem to solve.

Source: https://github.com/celestiaorg/CIPs/blob/main/cips/cip-010.md

### 5. Exposure: 2/10

Anchor band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.

Celestia uses the Cosmos SDK account model, in which an address is a hash of the secp256k1 public key, so an address that has never signed keeps its key hidden. The key is revealed with the account's first transaction, and staking TIA needs a signed delegation, so nearly all TIA in active use sits behind a revealed key. Validator consensus keys are public by design.

Placement in the band: The top of the band rather than a 3: this is the key-hash model in which staking or any send reveals the key, so effectively all TIA in use is exposed. It is not a 0 or a 1 because never-used addresses keep their keys hidden and no measured share of exposed TIA has been published.

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

### 6. Verification: 2/10

Anchor band 0 to 2: No post-quantum component exists, or the claims rest on marketing.

No post-quantum component exists for Celestia's signatures: no code, specification or testnet implementation was found, and the one ML-DSA pull request was closed unmerged and concerned other chains' keys. celestia-app is open source, but under v1.8 the openness of the classical code earns nothing here.

Placement in the band: The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but Celestia does not market itself as quantum-safe, so its position does not rest on marketing.

Source: https://github.com/celestiaorg/cosmos-sdk/tree/v0.52.12/crypto/keys

## Nearest chains in the ranking

The chains Celestia sits among, out of 80 rated. The last column is the gap in Hardy points from Celestia.

| Rank | Chain | Tier | Hardy | vs TIA |
|---:|---|---|---:|---:|
| 52 | [Akash Network](https://hardyindex.com/chains/akash) | 5: Exposed | 8.5 | level |
| 53 | [Arweave](https://hardyindex.com/chains/arweave) | 5: Exposed | 8.5 | level |
| 54 | [Avalanche](https://hardyindex.com/chains/avalanche) | 5: Exposed | 8.5 | level |
| 55 | [Bitcoin SV](https://hardyindex.com/chains/bitcoin-sv) | 5: Exposed | 8.5 | level |
| 56 | **Celestia** | 5: Exposed | 8.5 | this chain |
| 57 | [Chiliz Chain](https://hardyindex.com/chains/chiliz) | 5: Exposed | 8.5 | level |
| 58 | [Conflux](https://hardyindex.com/chains/conflux) | 5: Exposed | 8.5 | level |
| 59 | [dYdX Chain](https://hardyindex.com/chains/dydx) | 5: Exposed | 8.5 | level |
| 60 | [eCash](https://hardyindex.com/chains/ecash) | 5: Exposed | 8.5 | level |

## Signature scheme

- **On mainnet today:** ECDSA on secp256k1 for accounts; Ed25519 for validator consensus keys
- **Post-quantum scheme:** None selected or proposed for Celestia's own signatures. Upstream Cosmos SDK v0.55 offers ML-DSA-65, which Celestia's SDK fork does not carry.
- **NIST standard:** None adopted
- **Readiness tier:** Tier 5: Exposed. The signatures securing funds on mainnet today are quantum-vulnerable, and no public post-quantum plan, proposal or research programme addressing them could be found.

## Cryptography in use

- **Account signatures:** [ECDSA on secp256k1](https://hardyindex.com/algorithms/ecdsa-secp256k1.md). Mainnet, default. Celestia's Cosmos SDK fork also defines secp256r1 keys; whether mainnet accepts them for transactions was not confirmed.
  Source (source code or release): https://github.com/celestiaorg/cosmos-sdk/tree/v0.52.12/crypto/keys
- **Validator consensus:** [Ed25519](https://hardyindex.com/algorithms/ed25519.md). Mainnet, mandatory. Mainnet consensus parameters list ed25519 as the single allowed validator key type, as read on 22 October 2026.
  Source (read on-chain): https://celestia-rest.publicnode.com/cosmos/consensus/v1/params

A role not listed here is not evidenced either way. See https://hardyindex.com/algorithms.md.

## Roadmap

- **21 September 2026** (proposed): A celestia-core pull request ports the ML-DSA-65 key type from upstream CometBFT so that Celestia's IBC light client can verify other chains' ML-DSA-65 validator commits. It states that Celestia's own validators are Ed25519 only.
  Source: https://github.com/celestiaorg/celestia-core/pull/3340
- **14 October 2026** (shipped): The ML-DSA-65 pull request is closed without merging.
  Source: https://github.com/celestiaorg/celestia-core/pull/3340
- **No date published** (proposed): No CIP, implementation, testnet or timeline for post-quantum account or validator signatures on Celestia was found. celestia-app v10.4.0 pins Celestia's Cosmos SDK fork at v0.52.12, which has no ML-DSA key type.
  Source: https://github.com/celestiaorg/celestia-app/blob/v10.4.0/go.mod

## If holders never migrate

**No stated policy.** No CIP or statement from Celestia's maintainers addresses TIA in accounts that never move to post-quantum keys, since no post-quantum account type has been proposed for Celestia. As of 22 October 2026. Source: https://github.com/celestiaorg/CIPs

## Exposure

A Celestia account address is a hash of its secp256k1 public key, encoded in Bech32 with the celestia prefix, so an account that has never signed has not published its key. That protection ends with the account's first transaction, and because staking TIA needs a signed delegation, almost every holder who stakes has revealed a key that can be collected now and attacked later. Validator consensus keys are Ed25519 keys published by design. Celestia is not a fork of another chain, so the exposure inheritance rule does not apply. No measurement of exposed TIA has been published.

## Frequently asked questions

### Is Celestia quantum-safe?

No. TIA accounts sign transactions with ECDSA on the secp256k1 curve and Celestia's validators sign consensus votes with Ed25519, and a sufficiently large quantum computer running Shor's algorithm would break both. Mainnet's consensus parameters, read from public nodes on 22 October 2026, allow Ed25519 as the single validator key type. celestia-app v10.4.0 runs on Celestia's own fork of the Cosmos SDK, at v0.52.12, whose key types are secp256k1, secp256r1, Ed25519 and multisig. The ML-DSA-65 key types that upstream Cosmos SDK v0.55 added in July 2026 are not in it. No Celestia Improvement Proposal addresses post-quantum signatures. The one post-quantum item in Celestia's repositories was a September 2026 celestia-core pull request that would have let Celestia verify other chains' ML-DSA-65 validator keys over IBC; it said Celestia's own validators are Ed25519 only, and it was closed unmerged on 14 October 2026.

### Is Celestia quantum-safe?

No. TIA accounts sign with ECDSA on secp256k1 and validators sign with Ed25519, and a large enough quantum computer would break both. No Celestia Improvement Proposal or published plan addresses post-quantum signatures.

### Does the Cosmos SDK's ML-DSA release protect TIA?

No. ML-DSA-65 keys arrived in upstream Cosmos SDK v0.55 in July 2026. Celestia runs its own fork of the SDK, at v0.52.12 in celestia-app v10.4.0, and that fork has no ML-DSA key type, so no TIA holder or Celestia validator can use one.

### Did Celestia add ML-DSA-65 to celestia-core?

It was proposed and then dropped. A September 2026 pull request would have added the ML-DSA-65 key type so Celestia could verify other chains' post-quantum validator commits over IBC, while keeping Celestia's own validators on Ed25519. It was closed without merging on 14 October 2026.

### Are TIA public keys already exposed?

For nearly all TIA in active use, yes. An address is a hash of the key and hides it until the account signs, but staking needs a signed delegation, so active holders have revealed their keys. Those keys could be recorded now and attacked later by a quantum computer.

## What this rating means if you hold Celestia

Plain-language guidance from the same publication, with no product recommendation attached.

- [Is my crypto safe from quantum computers?](https://hardyindex.com/guides/is-my-crypto-safe-from-quantum-computers.md)
- [How to protect your crypto from quantum computers](https://hardyindex.com/guides/how-to-protect-crypto-from-quantum-computers.md)
- [All guides](https://hardyindex.com/guides.md)


## Sources

1. [Celestia mainnet consensus parameters (public REST endpoint)](https://celestia-rest.publicnode.com/cosmos/consensus/v1/params): PublicNode (primary, checked 22 October 2026)
2. [celestia-app v10.4.0 go.mod](https://github.com/celestiaorg/celestia-app/blob/v10.4.0/go.mod): Celestia (GitHub) (primary, checked 22 October 2026)
3. [celestia-app v10.4.0 default consensus parameters (app/default_overrides.go)](https://github.com/celestiaorg/celestia-app/blob/v10.4.0/app/default_overrides.go): Celestia (GitHub) (primary, checked 22 October 2026)
4. [celestia-core v0.42.3 validator parameters (types/params.go)](https://github.com/celestiaorg/celestia-core/blob/v0.42.3/types/params.go): Celestia (GitHub) (primary, checked 22 October 2026)
5. [Celestia Cosmos SDK fork v0.52.12 key types (crypto/keys)](https://github.com/celestiaorg/cosmos-sdk/tree/v0.52.12/crypto/keys): Celestia (GitHub) (primary, checked 22 October 2026)
6. [Create a wallet with celestia-node](https://docs.celestia.org/operate/keys-wallets/celestia-node-key/): Celestia documentation (primary, checked 22 October 2026)
7. [Accounts (Cosmos SDK v0.50)](https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts): Cosmos SDK documentation (Cosmos Labs) (primary, checked 22 October 2026)
8. [Celestia Improvement Proposals](https://github.com/celestiaorg/CIPs): Celestia (GitHub) (primary, checked 22 October 2026)
9. [CIP-10: Coordinated network upgrades](https://github.com/celestiaorg/CIPs/blob/main/cips/cip-010.md): Celestia (GitHub) (primary, checked 22 October 2026)
10. [feat(crypto): add ML-DSA-65 pubkey type for verifying counterparty commits (pull request 3340)](https://github.com/celestiaorg/celestia-core/pull/3340): Celestia (GitHub) (primary, checked 22 October 2026)
11. [Upstream CometBFT release: v0.38.26 (issue 3229)](https://github.com/celestiaorg/celestia-core/issues/3229): Celestia (GitHub) (primary, checked 22 October 2026)
12. [Cosmos SDK v0.55.0 release](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.55.0): Cosmos SDK (GitHub) (primary, checked 22 October 2026)

## How to cite this rating

A rating is only true as of the day it was reviewed, so both forms carry the review date and the methodology version. If you are quoting the score, quote those too.

The Hardy Index (2026). Celestia: quantum readiness assessment. Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8. Last reviewed 22 October 2026; sources checked 13 November 2026. https://hardyindex.com/chains/celestia

```bibtex
@misc{hardyindex_celestia_2026,
  author       = {{The Hardy Index}},
  title        = {Celestia: quantum readiness assessment},
  year         = {2026},
  howpublished = {\url{https://hardyindex.com/chains/celestia}},
  note         = {Hardy Score 8.5 of 100, Tier 5: Exposed. Methodology v1.8},
  urldate      = {2026-11-13}
}
```

---

Methodology: https://hardyindex.com/methodology (v1.8).
Cite as: The Hardy Index, "Celestia", https://hardyindex.com/chains/celestia, as of 13 November 2026.
