Is Stellar Quantum Safe?
Is Stellar quantum safe? It is a question that deserves a precise technical answer, not reassurance. Stellar (XLM) secures transactions with Ed25519, a highly efficient elliptic-curve signature scheme. That cryptography is robust against today's classical computers, but a sufficiently powerful quantum computer running Shor's algorithm could break it, exposing private keys from public keys alone. This article dissects Stellar's cryptographic stack, quantifies the Q-day threat timeline as analysts currently model it, examines whether Stellar has a migration roadmap, and explains what post-quantum alternatives actually look like in practice.
How Stellar Secures Transactions Today
Stellar uses Ed25519, a specific instance of the Edwards-curve Digital Signature Algorithm (EdDSA) built on Curve25519. It was deliberately chosen over the older secp256k1 (used by Bitcoin and Ethereum) because it offers faster signing, smaller signatures, and a cleaner implementation that resists several classes of classical side-channel attack.
Every Stellar account is a key pair:
- Private key: a 256-bit scalar kept secret by the account holder.
- Public key / account address: derived deterministically from the private key via scalar multiplication on Curve25519.
When you sign a transaction, Ed25519 produces a 64-byte signature. Validators on the Stellar network verify the signature against the public key without ever seeing the private key. The security assumption is that reversing the scalar multiplication, the Elliptic Curve Discrete Logarithm Problem (ECDLP), is computationally infeasible.
That assumption holds against classical computers. It does not hold against a quantum computer of sufficient scale.
Ed25519 vs secp256k1: Does the Curve Matter for Quantum?
A common misconception is that Ed25519 is somehow more quantum-resistant than Bitcoin's secp256k1. It is not. Both rely on the hardness of ECDLP. Shor's algorithm solves ECDLP in polynomial time on a quantum computer regardless of which elliptic curve is used. The curve affects performance and classical security margins, not quantum vulnerability. Stellar's choice of Ed25519 was the right call for efficiency, but it does not provide any meaningful buffer against Q-day.
---
The Q-Day Threat: What Shor's Algorithm Actually Does
Peter Shor published his quantum factoring algorithm in 1994. Its extension to elliptic curves means that a quantum computer with enough stable, error-corrected qubits could:
- Observe a public key on-chain (all public keys are visible once a Stellar account has made a transaction).
- Run Shor's algorithm to derive the private key from the public key.
- Sign fraudulent transactions draining the account, with no brute-force required.
The critical phrase is "enough stable, error-corrected qubits." Current estimates from IBM, Google, and academic cryptographers suggest that breaking a 256-bit elliptic curve key requires roughly 2,330 logical qubits in an error-corrected architecture, which in turn demands millions of physical qubits given today's error rates.
Q-Day Timeline: Analyst Scenarios
No credible analyst pins Q-day to a specific year, but the scenario space is narrowing:
| Scenario | Estimated Timeframe | Probability (analyst consensus range) |
|---|---|---|
| Cryptographically relevant quantum computer (CRQC) | Before 2030 | Low (~5–10%) |
| CRQC operational | 2030–2035 | Moderate (~20–35%) |
| CRQC operational | 2035–2040 | Most cited central case (~40–50%) |
| No CRQC this decade | Post-2040 | Residual (~15–25%) |
The US National Institute of Standards and Technology (NIST) finalised its first post-quantum cryptography (PQC) standards in August 2024, specifically because governments and standards bodies treat the threat as an engineering planning problem, not a science-fiction scenario. The urgency is real even if the exact date is uncertain.
"Harvest Now, Decrypt Later" Amplifies the Risk
State-level adversaries and well-resourced criminal groups do not need to wait for Q-day to begin harvesting ciphertext and signed transaction data today. By recording on-chain data now and decrypting it when quantum hardware matures, they can retroactively compromise accounts. For Stellar, this means any reused address that has ever broadcast a transaction is already potentially targeted.
---
Stellar's Specific Exposure Points
Reused vs. Never-Used Addresses
The attack surface differs depending on address usage:
- Never-used addresses (no outbound transaction): the public key has never been broadcast. Deriving the public key from the address requires breaking SHA-256 / SHA-3 hashing, which is not efficiently solved by Shor's algorithm. Grover's algorithm offers a quadratic speedup, but against 256-bit hashes the effective security drops only to ~128 bits, which remains computationally impractical for the foreseeable future. These addresses are relatively safer.
- Addresses that have sent at least one transaction: the public key is exposed on-chain. These are fully vulnerable to a future CRQC running Shor's algorithm.
The practical implication: the vast majority of active Stellar accounts, any account that has ever sent XLM or interacted with a DEX, are in the higher-risk category.
Multi-Signature Accounts
Stellar supports multi-signature arrangements through its threshold signing model. Each co-signer has their own Ed25519 key pair, and each of those key pairs carries identical quantum exposure. Multi-sig adds operational security against key theft today, but it does not reduce quantum risk, because each individual public key remains derivable.
Anchors, Payment Channels, and Path Payments
Stellar's ecosystem includes anchors (financial institutions issuing on-chain representations of fiat) and complex path-payment operations. These involve repeated signing operations, which continuously expose public keys. Any downstream reliance on Stellar's cryptographic guarantees, such as asset redemption rights tied to a specific key pair, inherits the same Q-day vulnerability.
---
Does Stellar Have a Post-Quantum Migration Roadmap?
As of mid-2025, the Stellar Development Foundation (SDF) has not published a formal post-quantum migration roadmap. The SDF's public documentation focuses on scalability, interoperability through the Stellar Ecosystem Proposals (SEP) process, and smart contract expansion via Soroban. Quantum-resistance is not listed as an active workstream in public SDF GitHub repositories or recent core protocol upgrade proposals.
This is not unusual. The majority of major layer-1 blockchains, including Ethereum, Solana, and Cardano, are in similar positions: they acknowledge the long-term threat but have not yet committed to a specific PQC upgrade timeline.
What a Migration Would Actually Require
Replacing Ed25519 with a NIST-approved post-quantum algorithm is a hard protocol upgrade, not a configuration change. The considerations include:
- Algorithm selection: NIST's finalised PQC standards include CRYSTALS-Dilithium (now ML-DSA) for signatures and CRYSTALS-Kyber (ML-KEM) for key encapsulation. FALCON and SPHINCS+ are also standardised. Each has different signature size and verification speed trade-offs.
- Signature size impact: ML-DSA signatures are roughly 2.4–4.5 KB versus Ed25519's 64 bytes. At Stellar's transaction throughput, this significantly increases bandwidth and storage costs per ledger.
- Address format migration: All existing accounts would need to generate new key pairs under the new scheme and transfer balances, requiring co-ordinated action across every wallet, anchor, and exchange holding XLM.
- Consensus protocol changes: Stellar's Federated Byzantine Agreement (FBA) validators also sign messages. Every validator node's signing infrastructure would require upgrading.
A realistic migration would take years of research, testnet work, and ecosystem co-ordination. Starting late dramatically compresses the safety window.
---
Post-Quantum Wallets: How Lattice-Based Cryptography Differs
The NIST-favoured PQC signature schemes, particularly ML-DSA (Dilithium), are built on structured lattice problems: specifically the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems. These are believed to be hard for both classical and quantum computers.
Key structural differences versus Ed25519:
| Property | Ed25519 | ML-DSA (Dilithium) |
|---|---|---|
| Security basis | Elliptic Curve DLP | Module Learning With Errors |
| Quantum vulnerable (Shor) | Yes | No (current analysis) |
| Signature size | 64 bytes | ~2,420–4,595 bytes |
| Public key size | 32 bytes | ~1,312–2,592 bytes |
| Key generation speed | Very fast | Fast |
| NIST standardised | No (predates process) | Yes (FIPS 204, 2024) |
Lattice-based schemes introduce larger key and signature sizes as an inherent trade-off. Wallet infrastructure must handle this gracefully: larger transaction payloads, more storage per address record, and potentially higher fees if the underlying network charges by data size.
Projects building PQC-native wallets today are working directly with these NIST-standardised algorithms rather than waiting for base-layer blockchains to migrate. BMIC.ai, for example, is building a quantum-resistant wallet using lattice-based, NIST PQC-aligned cryptography specifically to address the gap between Q-day risk and the slow pace of layer-1 migration.
---
What XLM Holders Should Do Now
Waiting for Stellar's base protocol to adopt post-quantum cryptography before taking action is a defensible strategy only if your personal Q-day risk tolerance is very low and your time horizon is short. For holders with significant XLM exposure or long-term conviction in the asset, a more proactive posture makes sense.
Practical Steps
- Audit your address exposure. Identify which of your Stellar accounts have ever broadcast a transaction. These are the accounts with public keys on-chain.
- Minimise key reuse. Where possible, rotate to fresh addresses for receiving new funds, reducing the value sitting in exposed accounts.
- Monitor SDF protocol announcements. Subscribe to Stellar's core developer channels. Any formal PQC workstream announcement would be significant news warranting immediate wallet action.
- Consider the custody layer. Even if Stellar's base layer migrates eventually, exchanges and custodians holding XLM on your behalf introduce their own key-management risk. Evaluate whether custodians have articulated any PQC strategy.
- Evaluate PQC-native custody options. As lattice-based wallet products reach production readiness, they offer a way to hold cross-chain assets under post-quantum key management independently of whether any specific layer-1 has yet migrated.
- Follow NIST and NSA guidance. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates PQC adoption for national security systems by 2030. Institutions holding digital assets face regulatory pressure that may accelerate custody-layer changes ahead of protocol-layer changes.
---
Summary: Where Stellar Stands on Quantum Safety
Stellar is not quantum safe. Its Ed25519 signature scheme, like every elliptic-curve scheme, is theoretically breakable by a sufficiently powerful quantum computer running Shor's algorithm. The threat is not imminent, but it is directional and increasingly quantified by standards bodies that have moved from academic warning to published standards.
The network has no published migration roadmap as of mid-2025. A migration, when it comes, will be technically complex and time-consuming. The "harvest now, decrypt later" dynamic means that accounts broadcasting public keys today are accumulating latent risk even before a CRQC exists.
For long-term XLM holders, the honest position is: Stellar's quantum exposure is real, the timeline is uncertain but compressing, and the base-layer response has not started. Custody-layer post-quantum solutions represent the most immediately available mitigation while the ecosystem catches up.
Frequently Asked Questions
Is Stellar (XLM) quantum safe?
No. Stellar uses Ed25519, an elliptic-curve signature scheme that is vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. A cryptographically relevant quantum computer could derive private keys from exposed public keys, compromising any account that has ever broadcast a transaction.
Does Ed25519 offer better quantum protection than Bitcoin's secp256k1?
No. Both Ed25519 and secp256k1 rely on the Elliptic Curve Discrete Logarithm Problem, which Shor's algorithm solves efficiently on a quantum computer. Stellar's use of Ed25519 is better for performance and classical security, but it provides no meaningful advantage against quantum attack.
Has the Stellar Development Foundation announced a post-quantum upgrade?
As of mid-2025, the SDF has not published a formal post-quantum cryptography migration roadmap. Active development focus is on Soroban smart contracts and ecosystem interoperability. XLM holders should monitor SDF core developer channels for any future announcement.
What does 'harvest now, decrypt later' mean for Stellar users?
It means adversaries can record signed Stellar transactions and public keys today, then decrypt them once quantum hardware matures. Any account that has ever sent a transaction already has its public key on-chain and is potentially a harvest target, even though quantum computers capable of exploiting this do not yet exist.
Which post-quantum signature algorithms would Stellar need to adopt?
The most likely candidates are NIST-standardised lattice-based schemes, primarily ML-DSA (CRYSTALS-Dilithium, FIPS 204) for digital signatures. FALCON and SPHINCS+ are also standardised alternatives. Each carries much larger signature and key sizes than Ed25519, which would require significant protocol and infrastructure changes across the Stellar network.
What can XLM holders do to reduce quantum risk before Stellar migrates?
Key steps include auditing which addresses have exposed public keys, minimising value held in previously used addresses, monitoring SDF announcements, and evaluating post-quantum-native custody solutions that use lattice-based cryptography independently of whether Stellar's base layer has yet migrated.