Chain profile
A published Quantum Preparedness Plan whose first stage adds ML-DSA verification to Soroban as native host functions, letting contract accounts authenticate with quantum-safe keys.
No, not today. Stellar accounts are secured by Ed25519, which a sufficiently large quantum computer would break. Stellar has published a Quantum Preparedness Plan, and its first stage during 2026 is to add post-quantum signature verification to Soroban, Stellar's smart contract environment, as native host functions supporting ML-DSA-44 and ML-DSA-65. The route to holder safety runs through Soroban's account abstraction layer: contract accounts can implement quantum-safe authentication without the protocol having to replace Ed25519 for everyone at once. That is a sound design, and it is also an opt-in one, so the pace of real protection will depend on adoption rather than on the upgrade alone.
Ed25519 for all classic accounts
ML-DSA-44 and ML-DSA-65 verification as native Soroban host functions, with quantum-safe authentication through contract accounts
FIPS 204 (ML-DSA), finalised August 2024
Tier 3: Committed. A funded roadmap with public dates and active research exists, but no post-quantum signature is live on mainnet.
| No. | Dimension | Score | Weight | Contribution |
|---|---|---|---|---|
| 1 | Signature scheme | 0 | 30% | 0.0 |
| 2 | Deployment stage | 5 | 25% | 12.5 |
| 3 | NIST alignment | 8 | 15% | 12.0 |
| 4 | Migration path | 7 | 15% | 10.5 |
| 5 | Exposure | 2 | 10% | 2.0 |
| 6 | Verification | 8 | 5% | 4.0 |
| Hardy Score | 41.0 | |||
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.
Stellar accounts sign with Ed25519 and no post-quantum signature protects live XLM on mainnet. The planned ML-DSA support is verification inside Soroban rather than a deployed account signature scheme. source
Band 5: Tier 3: Committed.
Tier 3: Committed. A published, staged preparedness plan with named schemes and a 2026 first stage, and nothing post-quantum live on mainnet at the time of writing. source
Band 6 to 8: The scheme is NIST-selected but the standard is not yet final, or a NIST-approved scheme is named but not yet deployed.
The plan names ML-DSA-44 and ML-DSA-65, both parameter sets of the finalised FIPS 204 standard, rather than referring to post-quantum cryptography in the abstract. Committing to specific parameter sets of a final standard is a strong signal. source
Placement in the band The top of the band rather than a 6 or a 7: ML-DSA-44 and ML-DSA-65 are specific parameter sets of a final standard, not post-quantum cryptography in the abstract. It cannot reach 9 because nothing is deployed, so the standard is committed to rather than in use.
Band 6 to 8: A credible published plan exists with a mechanism identified, but key parts are unbuilt or undated.
Soroban's account abstraction gives Stellar a credible route: contract accounts can adopt quantum-safe authentication without a protocol-wide signature replacement or a contentious fork. The deduction is that this makes protection opt-in, so classic Ed25519 accounts are not carried across by the upgrade itself. source
Placement in the band A 7 rather than an 8: Soroban's account abstraction is a credible mechanism that avoids a contentious fork, but it makes protection opt-in, so classic Ed25519 accounts are not carried across by the upgrade itself.
Band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.
A Stellar account ID is a direct encoding of the Ed25519 public key, so the key is readable from the address whether or not the account has ever transacted. Effectively all classical XLM is harvestable today. source
Placement in the band At the top of the band rather than a 0 or a 1: Stellar meets this band on its structural limb, the account ID being a direct encoding of the key, but no measured share of at-risk supply has been published.
Band 6 to 8: Open source with public review or a named third-party audit of the relevant component.
The plan is published by the Stellar Development Foundation under its own name with named algorithms and staged scope, and the protocol and Soroban are open source, so the first stage can be checked against the code as it lands. source
Placement in the band The top of the band: the plan is published under the foundation's own name with named algorithms and staged scope, against open source, so the first stage is checkable as it lands. It stops short of 9 because nothing post-quantum has landed yet.
The deployment dimension is not a separate judgement. It is Tier 3 expressed as a number. See the tier mapping.
The 9 chains Stellar sits among, out of 31 rated. The last column is the gap in Hardy points from Stellar.
| Rank | Chain | Tier | Hardy | vs XLM |
|---|---|---|---|---|
| 8 | Solana | 2: Shipping | 54.5 | +13.5 |
| 9 | XRP Ledger | 3: Committed | 46.5 | +5.5 |
| 10 | Sui | 3: Committed | 45.5 | +4.5 |
| 11 | Hedera | 3: Committed | 42.0 | +1.0 |
| 12 | Stellar this chain | 3: Committed | 41.0 | |
| 13 | Zcash | 3: Committed | 41.0 | level |
| 14 | Aptos | 3: Committed | 40.5 | -0.5 |
| 15 | Polkadot | 3: Committed | 40.5 | -0.5 |
| 16 | Ethereum | 3: Committed | 40.0 | -1.0 |
Add post-quantum signature verification to Soroban as native host functions supporting ML-DSA-44 and ML-DSA-65, with contract accounts able to implement quantum-safe authentication through account abstraction. source
Broader protocol-level quantum preparedness beyond Soroban contract accounts. No dated schedule was found at the time of writing. source
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 Stellar account ID, the string beginning with G that users share, is a direct encoding of the account's Ed25519 public key. There is no hashing step, so the key is known to anyone who knows the address, whether or not the account has ever signed a transaction. This puts Stellar in the same structural position as Algorand, Solana and Polkadot: every classical balance is available for harvest-now-decrypt-later collection today, and never transacting does not help. Contract accounts on Soroban are where the planned quantum-safe authentication will live.
What this rating means for you
Stellar has a funded roadmap but no post-quantum signature protecting funds on mainnet yet. Until it ships, your exposure is the ordinary one, and the steps that reduce it cost nothing.
Editorial guidance from the Hardy Index. Nothing on this profile is sponsored and nothing on it is an affiliate link. The guides carry disclosed affiliate links, which never affect a rating. How we make money.
We will email you the day this rating moves, with the changelog note that explains why. Nothing else, and nothing in between.
No. Stellar accounts use Ed25519, which a sufficiently large quantum computer would break. Stellar has published a Quantum Preparedness Plan whose first stage adds ML-DSA verification to Soroban during 2026, but no post-quantum signature protects XLM on mainnet today.
Stage 1 adds post-quantum signature verification to Soroban, Stellar's smart contract environment, as native host functions supporting ML-DSA-44 and ML-DSA-65. Contract accounts can then implement quantum-safe authentication through Soroban's account abstraction layer, without the protocol replacing Ed25519 for every classic account at once.
Not automatically. Building quantum-safe authentication into contract accounts means holders have to move to one to benefit. It avoids a contentious protocol-wide change, which is a real advantage, but it makes protection opt-in rather than universal, and adoption is what determines how much value is actually covered.
Because a Stellar account ID encodes the public key directly rather than a hash of it. On chains where the address is a key hash, a funded account that has never spent keeps its key private. On Stellar the key is readable from the address, so all classical XLM is exposed to collection today.
A rating is only true as of the day it was reviewed, so both forms below carry the review date and the methodology version. If you are quoting the score, quote those too.
The Hardy Index (2026). Stellar: quantum readiness assessment. Hardy Score 41.0 of 100, Tier 3: Committed. Methodology v1.4. Reviewed 2 October 2026. https://hardyindex.com/chains/stellar
@misc{hardyindex_stellar_2026,
author = {{The Hardy Index}},
title = {Stellar: quantum readiness assessment},
year = {2026},
howpublished = {\url{https://hardyindex.com/chains/stellar}},
note = {Hardy Score 41.0 of 100, Tier 3: Committed. Methodology v1.4},
urldate = {2026-10-02}
} The whole dataset is reusable under the terms on the about page. A machine-readable version of this page is at /chains/stellar.md.
This is a security-readiness assessment, not investment advice.