Chain profile
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.
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.
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.
ECDSA on secp256k1 for accounts; Ed25519 for validator consensus keys
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.
None adopted
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.
A role not listed is not evidenced either way. Every scheme, and which other chains share it, is in the cryptography registry.
| No. | Dimension | Score | Weight | Contribution |
|---|---|---|---|---|
| 1 | Signature scheme | 0 | 30% | 0.0 |
| 2 | Deployment stage | 1 | 25% | 2.5 |
| 3 | NIST alignment | 0 | 15% | 0.0 |
| 4 | Migration path | 2 | 15% | 3.0 |
| 5 | Exposure | 2 | 10% | 2.0 |
| 6 | Verification | 2 | 5% | 1.0 |
| Hardy Score | 8.5 | |||
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
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
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. source
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.
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. source
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.
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. source
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.
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. source
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.
The deployment dimension is not a separate judgement. It is Tier 5 expressed as a number. See the tier mapping.
The 9 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 | 5: Exposed | 8.5 | level |
| 53 | Arweave | 5: Exposed | 8.5 | level |
| 54 | Avalanche | 5: Exposed | 8.5 | level |
| 55 | Bitcoin SV | 5: Exposed | 8.5 | level |
| 56 | Celestia this chain | 5: Exposed | 8.5 | |
| 57 | Chiliz Chain | 5: Exposed | 8.5 | level |
| 58 | Conflux | 5: Exposed | 8.5 | level |
| 59 | dYdX Chain | 5: Exposed | 8.5 | level |
| 60 | eCash | 5: Exposed | 8.5 | level |
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
The ML-DSA-65 pull request is closed without merging. source
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
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 Published beside the score, not in it. Every chain's stance is compared on the commitments page.
Exposure measures how much of the chain's value already sits behind a public key that an attacker can record today and break later. This is the part of the threat that a future upgrade cannot undo.
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.
What this rating means for you
Celestia runs quantum-vulnerable signatures with no published post-quantum plan that we could find. Nothing here is urgent today, and there is also nothing scheduled to change it.
Editorial guidance from the Hardy Index.
We will email you the day this rating moves, with the changelog note that explains why. Nothing else, and nothing in between.
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.
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.
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.
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.
A rating is only true as of the day an editor last reviewed it, so both forms below carry that date and the methodology version, with the date its cited sources were last checked. 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
@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}
} The whole dataset is reusable under the terms on the about page. A machine-readable version of this page is at /chains/celestia.md.
This is a security-readiness assessment, not investment advice.