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 | |||
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
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
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
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
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
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
The deployment dimension is not a separate judgement. It is Tier 3 expressed as a number. See the tier mapping.
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.
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.
This is a security-readiness assessment, not investment advice.