Stellar Post-Quantum Migration: Roadmap, Risks, and Options for Holders
Stellar post-quantum migration is a topic gaining traction as cryptographers and blockchain developers reckon with the looming threat of quantum computing. Stellar's network, like virtually every major public blockchain, currently relies on elliptic-curve cryptography (specifically Ed25519) to secure accounts and sign transactions. When sufficiently powerful quantum computers arrive, those signatures become breakable, exposing every wallet whose public key is on-chain. This article examines what Stellar has said publicly, what a real migration would technically require, how long such a transition realistically takes, and what XLM holders can do in the interim to reduce exposure.
Stellar's Current Cryptographic Foundation
Stellar uses Ed25519, a variant of elliptic-curve cryptography (ECC) built on Curve25519. Ed25519 was chosen for its speed, compact key sizes, and strong classical security properties. Every Stellar account is derived from an Ed25519 key pair: the public key becomes the account address (encoded as a Stellar "G..." address), and the private key signs each transaction.
Ed25519 offers roughly 128 bits of classical security. Against a classical computer, that is adequate. Against a cryptographically relevant quantum computer (CRQC) running Shor's algorithm, the picture changes sharply. Shor's algorithm can solve the discrete logarithm problem, the mathematical hard problem underlying all ECC, in polynomial time. A sufficiently large quantum computer could therefore derive a private key from any public key exposed on-chain.
Why Public Key Exposure Matters
On most blockchains, including Stellar, your public key is broadcast to the network every time you sign a transaction. This means:
- Any account that has ever sent a transaction has its public key permanently recorded on-chain.
- Accounts that have received funds but never sent a transaction have only a *hash* of their public key exposed, offering a temporary additional layer, as breaking a hash still requires a pre-image attack.
- Multi-signature accounts and smart contract interactions frequently expose public keys as well.
The practical implication is that the majority of active Stellar accounts are already quantum-vulnerable once a CRQC exists.
---
Does Stellar Have a Post-Quantum Roadmap? The Honest Answer
As of the date of this article's publication, Stellar has no publicly announced post-quantum migration plan or formal roadmap item dedicated to PQC (post-quantum cryptography).
The Stellar Development Foundation (SDF) has published extensive technical roadmaps covering Protocol upgrades, smart contract capabilities (Soroban), and fee market improvements. Post-quantum signature schemes do not appear in any published SDF roadmap, CAP (Core Advancement Proposal), or ecosystem grant priority list.
This is not unique to Stellar. As of 2024-2025, the overwhelming majority of Layer-1 public blockchains, including Ethereum, Bitcoin, Solana, and Avalanche, also lack finalized PQC migration roadmaps, though several have published research-level discussions.
What the ecosystem *does* have:
- NIST's PQC standardization, finalized in 2024, which ratified CRYSTALS-Kyber (key encapsulation), CRYSTALS-Dilithium, FALCON, and SPHINCS+ as approved algorithms. These give any blockchain a concrete algorithmic target.
- Academic proposals for ECC-to-PQC migration on UTXO and account-based chains, which Stellar's engineering team could draw on.
- Ethereum's EIP-7560 and Vitalik Buterin's "quantum emergency" post, which offer the most detailed public thinking from a major blockchain ecosystem on what a practical migration path could look like.
Stellar's silence on PQC is not necessarily negligence. The realistic threat window for a CRQC large enough to attack 256-bit ECC is still widely estimated at 10-20 years, though estimates vary significantly and some national-security frameworks plan for shorter timelines.
---
What a Stellar Post-Quantum Migration Would Actually Involve
If Stellar were to undertake a full PQC migration, the engineering scope would be substantial. Breaking it down by layer helps clarify the challenge.
1. Signature Scheme Replacement
The core change would be replacing Ed25519 signatures with a NIST-approved PQC algorithm. The leading candidates for a blockchain context are:
| Algorithm | Type | Signature Size | Public Key Size | Speed | Notes |
|---|---|---|---|---|---|
| CRYSTALS-Dilithium (ML-DSA) | Lattice-based | ~2.4 KB | ~1.3 KB | Fast | NIST primary recommendation |
| FALCON | Lattice-based | ~0.7 KB | ~0.9 KB | Moderate | Compact, but complex implementation |
| SPHINCS+ (SLH-DSA) | Hash-based | ~8–50 KB | 32–64 bytes | Slow | Most conservative; no lattice assumptions |
| Ed25519 (current) | ECC | 64 bytes | 32 bytes | Very fast | Quantum-vulnerable |
The size increases are significant. Dilithium signatures are roughly 37x larger than Ed25519 signatures. On a high-throughput network like Stellar (designed for 1,000+ TPS), larger signatures inflate transaction sizes, increase network bandwidth requirements, and raise fees unless fee structures are adjusted.
2. Address Format Migration
Stellar account addresses are derived from Ed25519 public keys. A PQC migration would require a new address format derived from a post-quantum key. This means:
- Existing "G..." addresses cannot be natively migrated to PQC; new addresses would be generated.
- Users would need to move funds from old (quantum-vulnerable) addresses to new (quantum-safe) addresses.
- Exchanges, custodians, and payment processors would need to update deposit/withdrawal infrastructure.
3. Protocol-Level Consensus Changes
Stellar uses the Stellar Consensus Protocol (SCP), a federated Byzantine agreement mechanism. SCP itself uses cryptographic signatures for validator messages. Migrating SCP to PQC signatures would require a coordinated protocol upgrade affecting all validators simultaneously, a hard-fork equivalent in Stellar's upgrade model.
4. Smart Contract and Soroban Compatibility
Stellar's Soroban smart contract platform (launched 2023) introduces additional cryptographic surface area. Any on-chain contracts that rely on signature verification logic would need separate auditing and upgrading.
5. Wallet and SDK Ecosystem Updates
Every wallet, SDK, and third-party integration would need to support new key generation, new address formats, and new transaction signing. This is typically the longest tail of any protocol migration, often taking years after the core protocol change ships.
---
Migration Approaches: Lessons from Other Ecosystems
Ethereum's research community has proposed several migration strategies that are instructive for any EVM or non-EVM chain:
- Hard cutoff migration: Set a block height after which only PQC-signed transactions are valid. Risky because users who lose access to their current private keys cannot migrate funds.
- Dual-signature transition period: Require both an Ed25519 signature and a PQC signature during a grace period, then drop Ed25519. More complex but safer for users.
- Hash-based address locking: Immediately lock any address that has exposed its public key (i.e., has sent transactions), requiring a PQC key registration before further transactions are permitted.
- Account abstraction migration: Use account abstraction (similar to ERC-4337 on Ethereum) to allow accounts to specify their own signature verification logic, enabling a gradual key-scheme migration without a hard fork.
Of these, the dual-signature + account-abstraction approach is generally considered the most practical for live networks with large existing user bases.
---
Interim Options for Stellar Holders Today
Since no imminent Stellar PQC migration exists, holders face a gap between current exposure and a hypothetical future-safe state. Several practical steps reduce risk at the margins:
Minimize On-Chain Public Key Exposure
- Use fresh addresses for receiving funds and delay sending transactions from those addresses as long as possible. Addresses that have never signed a transaction only expose a hash of the public key, which is harder (though not impossible) to attack.
- This is a partial mitigation, not a solution. Once you spend or send XLM, the public key is exposed.
Use Hardware Wallets with Strong Key Storage
Hardware wallets (Ledger, Trezor) do not make your keys quantum-safe, but they significantly reduce the risk of classical compromise, which remains a far more immediate threat than quantum attacks for most users.
Diversify Into Quantum-Resistant Assets
Some projects are building from the ground up with post-quantum cryptography as a core design principle rather than a future upgrade. For example, BMIC.ai is a quantum-resistant crypto wallet and token built on NIST PQC-aligned, lattice-based cryptography, designed specifically to remain secure against Q-day threats. Allocating a portion of a digital-asset portfolio to assets with native PQC protection is a reasonable hedge for long-horizon holders.
Monitor SDF and CAP Channels
The Stellar Development Foundation publishes all protocol proposals at stellar.org/developers. Watching the CAP (Core Advancement Proposal) repository on GitHub and the SDF blog is the most reliable way to get early notice if a PQC roadmap item is introduced. Community forums on Discord and the Stellar Stack Exchange are secondary signal sources.
---
Timeline Scenarios: When Does This Become Urgent?
Estimating the urgency of post-quantum migration requires threading several uncertain variables.
Optimistic quantum-skeptic scenario: Large-scale fault-tolerant quantum computers remain 20+ years away. Current NISQ-era machines lack the qubit count and error-correction to run Shor's algorithm at cryptographically meaningful scale. In this scenario, Stellar and other networks have ample time to migrate before any real threat materializes.
Moderate scenario: A cryptographically relevant quantum computer emerges within 10-15 years, likely from a well-resourced nation-state program before commercial availability. Blockchain networks that begin PQC planning by 2026-2027 would have realistic runway to complete migration before this window.
Accelerated scenario: Unexpected algorithmic breakthroughs or hardware improvements compress the timeline to 5-8 years. Chains without active PQC roadmaps by 2025-2026 could face genuine pressure. This is the scenario driving urgency in the national-security community, including CISA and NSA guidance recommending organizations begin PQC migration planning now.
The honest analyst position: the moderate scenario is the consensus view among cryptographers, but the asymmetry between "started early and wasn't needed yet" versus "waited too long" strongly favors early action.
---
Summary: Key Takeaways
- Stellar currently relies on Ed25519, which is quantum-vulnerable to Shor's algorithm on a CRQC.
- As of now, Stellar has no public post-quantum migration roadmap or CAP in progress.
- A real migration would require new signature algorithms (Dilithium or FALCON are the most likely candidates), new address formats, validator protocol upgrades, and ecosystem-wide tooling changes, a multi-year effort.
- The threat timeline is uncertain but the preparation lead time is long, making early ecosystem attention worthwhile.
- Holders can reduce marginal exposure by minimizing public key exposure, using hardware wallets, monitoring SDF channels for any roadmap announcements, and considering PQC-native assets as a long-horizon portfolio hedge.
Frequently Asked Questions
Does Stellar currently have a post-quantum migration plan?
No. As of the time of writing, Stellar has no publicly announced post-quantum migration roadmap, dedicated Core Advancement Proposal (CAP), or SDF blog commitment to PQC cryptography. Holders and developers should monitor the SDF GitHub and blog for future announcements.
What cryptographic algorithm does Stellar use and why is it quantum-vulnerable?
Stellar uses Ed25519, an elliptic-curve digital signature scheme. Its security depends on the hardness of the discrete logarithm problem. Shor's algorithm, when run on a sufficiently large fault-tolerant quantum computer, can solve this problem efficiently, meaning a quantum adversary could derive private keys from public keys exposed on-chain.
Which post-quantum signature algorithms would be most suitable for Stellar?
CRYSTALS-Dilithium (now standardized as ML-DSA by NIST) is the leading candidate due to its strong security proof and relatively balanced performance characteristics. FALCON offers more compact signatures but is harder to implement securely. SPHINCS+ is the most conservative option but produces very large signatures that could strain a high-throughput network like Stellar.
Can XLM holders do anything right now to protect against quantum attacks?
Fully quantum-safe storage is not possible within the current Stellar protocol. Partial mitigations include using fresh addresses that have never signed transactions (exposing only a key hash rather than the full public key), storing keys in hardware wallets to reduce classical attack risk, and monitoring for any future SDF migration announcements. Some holders also allocate to PQC-native assets as a portfolio hedge.
How long would a full Stellar post-quantum migration realistically take?
Based on the complexity involved — new signature schemes, new address formats, validator coordination, Soroban compatibility, and wallet/SDK ecosystem updates — a realistic estimate for a well-resourced migration effort is 3-5 years from the point a formal proposal is adopted. This underscores why early planning matters even if the quantum threat is still years away.
Is the quantum computing threat to Stellar imminent?
The consensus among cryptographers is that a quantum computer large enough to break Ed25519 is likely 10-20 years away, though some national-security frameworks plan for shorter timelines. The threat is not immediate, but the long lead time required for a safe blockchain migration means the planning phase should begin well before the hardware threat is confirmed.