The Stellar Development Foundation released its Quantum Preparedness Plan on June 9. The plan maps a three-stage migration of the Stellar network away from elliptic curve cryptography before quantum computers gain enough power to break it. Nicolas Barry, who authored the announcement, set a hard deadline: every Stellar account should support a quantum-safe signer by end of 2027.
The timing is not arbitrary. INRIA researchers published findings in early 2026 showing that breaking 256-bit elliptic curves — the family that includes Stellar’s Ed25519 signing scheme — now requires only 1,193 logical qubits. That figure is 44% lower than prior estimates. It is also fewer qubits than are needed to crack RSA-3072, which flips an assumption the industry had held for years. The National Institute of Standards and Technology revised its danger zone from 2030-plus down to 2029-plus. Google set 2029 as its own internal deadline for post-quantum readiness across its systems.
One Structural Difference That Changes the Math
On most blockchains, the account address and the public key are the same thing. Migrating to quantum-safe cryptography means moving balances to a new account and updating every system that points to the old address. Stellar does not work that way.
Stellar separates account identity from signing keys. The G… address stays fixed. What authorizes transactions on that account can be rotated through the existing set_options operation without touching the address itself. A Stellar account moving to quantum-safe signing does not need a new account. It needs to add a quantum-safe signer, weight it correctly, and remove the legacy Ed25519 signer. That distinction matters for custodians and enterprise wallets that have built integrations around stable identifiers.
The missing piece, as Barry’s announcement put it, is the quantum-safe signer type itself and the protocol infrastructure required to verify those signatures efficiently. The Quantum Preparedness Plan is largely about building that.
Stage one targets 2026. Post-quantum signature verification will be added to Soroban as native host functions, initially supporting ML-DSA-44 and ML-DSA-65, the signature standards NIST finalized in 2024 under FIPS 204. Contract accounts can use these to enforce quantum-safe authentication through Soroban’s account abstraction layer without any protocol-level change to classic accounts.
The Scheme Debate Inside the GitHub
The technical conversation about which post-quantum signature schemes to add is already happening in public. A Core Advancement Proposal thread opened in April by Stellar maintainer jayz22 laid out the candidates: ML-DSA, SLH-DSA, and Falcon (FN-DSA).
Soundness Labs, which shipped a Soroban smart account using Falcon earlier this year, put numbers to the tradeoff. On Stellar today, an Ed25519 authenticator is 96 bytes total, 32 for the public key and 64 for the signature. Falcon-512 lands at roughly 16 times that. ML-DSA-44 runs about 39 times the Ed25519 size. SLH-DSA-128f comes in at around 178 times. Those figures matter because every authorization carries the public key and signature into the transaction. Every node propagates, validates, and stores those bytes.
Falcon is the most compact of the three and the fastest to verify. ML-DSA is slower on the wire but carries stronger institutional backing. It has hardware security module support from AWS and Google Cloud KMS, it is in Apple’s CryptoKit for iOS 26, and it sits inside CNSA 2.0, the US government’s post-quantum migration framework for national security systems. SLH-DSA is the conservative choice, relying only on hash function security rather than lattice assumptions, but its signing cost is too high for daily transaction use.
Stellar maintainer MonsieurNicolas weighed in on the thread, favoring ML-DSA-44 and ML-DSA-65 as the first host functions to ship, citing their approved standard status and HSM support. Falcon, he wrote, should wait until FIPS 206 is finalized and production implementations stabilize, partly because floating-point operations in Falcon’s signing path carry architecture-dependent behavior that could introduce determinism issues in a host function context.
The regulatory angle is one most coverage has skipped. Institutional Stellar users operating under different national frameworks face different requirements. BSI, Germany’s federal cybersecurity authority, recommends SLH-DSA for long-term and high-value signatures. ANSSI in France includes Falcon explicitly in its guidance. The US CNSA 2.0 suite mandates ML-DSA. A custodian operating across those jurisdictions may need support for more than one scheme. The plan addresses that by building for all three over time.
Dormant Accounts and a Community Decision
Stage two moves to the protocol level in 2027. A Core Advancement Proposal will introduce quantum-safe signer types as native signers on classic accounts. No new account type, no address change, no balance migration. Stage three — deprecation of Ed25519 — has no fixed date. Its timing will depend on quantum computing progress and how ready the broader ecosystem is.
The deprecation question carries a specific problem that Barry flagged directly: Stellar holds a large population of dormant accounts whose holders are unreachable. A forced cutoff would freeze those accounts. The network would then have to choose between providing a recovery mechanism using seed-based proofs, which Stellar’s architecture supports, or accepting that those accounts become permanently locked. Barry said the foundation would open this to community design discussion rather than decide unilaterally.
Ethereum drafted an emergency hard fork plan. Bitcoin has BIP-360 in discussion. Algorand deployed Falcon-based state proofs and remains the only known mainnet use of Falcon. Stellar’s plan is the most granular public roadmap any major blockchain has published, with scheme-level decisions, jurisdictional notes, and a named technical rationale for the order in which schemes will ship.
Zero-knowledge protocols built on pairing-based curves remain outside the plan’s scope for now. SLH-DSA, ML-DSA, and Falcon address signatures. The ZK problem, where Shor’s algorithm breaks BN254 and BLS12-381 in the same way it breaks Ed25519, has no drop-in post-quantum replacement with comparable performance yet. Barry wrote that Stellar would convene ZK teams building on the network to develop a shared research agenda.
