Stellar publishes Quantum Preparedness Plan, ML-DSA to Soroban 2026

The Stellar Development Foundation publishes the Quantum Preparedness Plan (QPP), a three-stage program to migrate the Stellar network off Ed25519 and onto NIST-standard post-quantum signatures. The primary source is the foundation blog post Introducing the Quantum Preparedness Plan.

What the plan ships

Three stages, dated. Stage 1 lands this year; Stage 2 ships through a Core Advancement Proposal in 2027; Stage 3 — the deprecation of Ed25519 for new transaction authorization — is left unscheduled and explicitly tied to community discussion rather than a unilateral foundation call.

Stellar Quantum Preparedness Plan
- Stage 1 — 2026
  Add post-quantum signature verification to Soroban as native
  host functions, supporting ML-DSA-44 and ML-DSA-65 (NIST FIPS 204).
  Contract accounts can implement quantum-safe authentication via
  Soroban's account abstraction layer. No protocol-level change to
  classic accounts required.

- Stage 2 — 2027
  Core Advancement Proposal introduces quantum-safe signer types
  as first-class signers on classic accounts. Every Stellar account
  can add a quantum-safe signer alongside its Ed25519 key, keeping
  the same address and the same history.

- Stage 3 — Deprecation
  Ledger at which Ed25519 is no longer accepted for new
  transaction authorization. Timing determined by quantum-compute
  progress and ecosystem readiness; opened to community design
  discussion.

Source: stellar.org/blog/foundation-news/introducing-the-quantum-preparedness-plan

Mechanism — why account abstraction first

Stellar's structural argument for going Soroban-first is that account identity is separated from signing keys. A Stellar account is an address; the signers attached to it are mutable state. That decoupling — uncommon among major L1s — means an account can swap in a quantum-safe signer without changing its address or moving its balance. Bitcoin's UTXO model and Ethereum's address-equals-pubkey-hash design don't have that lever.

In Stage 1, that lever is pulled at the contract account layer rather than the classic account layer. ML-DSA-44 and ML-DSA-65 — the two NIST-standardized variants of the Dilithium lattice signature scheme published as FIPS 204 — land as Soroban host functions. Contract accounts can call them via Soroban's account abstraction layer to authenticate transactions, with no change to the underlying ledger format and no impact on Ed25519 signers that remain in place.

In Stage 2, a Core Advancement Proposal moves quantum-safe signer types onto the classic account path as native first-class signers. The same account can list an Ed25519 signer and an ML-DSA signer side by side. Migration is opt-in.

Stage 3 is the only one without a date. Activation requires "community input as it's likely that it will come with some disruption to some accounts" — the standard formulation for a forced cryptographic cutover.

Why now

The QPP cites two specific 2026 developments as drivers.

INRIA research showing that breaking the 256-bit elliptic curves used by Ed25519 requires only 1,193 logical qubits — a 44% reduction from prior estimates and fewer than what's needed to break RSA-3072. That paper, alongside two other early-2026 results, has compressed the public estimate of when cryptographically relevant quantum computers (CRQCs) become a near-term threat.

NIST guidance — formerly placing the danger zone at 2030 and beyond — updated to 2029+. Combined with NIST's August 2024 finalization of FIPS 203, 204 and 205 (ML-KEM, ML-DSA, SLH-DSA), the practical effect is that post-quantum schemes are now standardized and the threat horizon is a five-to-ten-year window rather than a fifteen-year one.

Impact

• Stellar custody and wallet vendors. Enterprise wallets can begin migrating to quantum-safe contract accounts in 2026 once Soroban ships ML-DSA host functions — earlier than the classic account path. Vendors integrating institutional treasuries (Anchorage, Fireblocks, BitGo, Copper) get a deployable path before Stage 2.
• Soroban contract authors. Account-abstraction patterns built since Soroban mainnet (2024) get a new authentication primitive. Existing contracts don't need to migrate; new contracts can opt into ML-DSA from day one.
• Anchor operators and bridges. No protocol change in Stage 1 — wire format and ledger semantics are unchanged. Tooling that signs operations on behalf of accounts gets the option, not the requirement, of post-quantum signatures.
• Issuers of tokenized assets on Stellar (MoneyGram USDC anchors, Franklin Templeton's BENJI, the DTCC pilot pipeline) inherit Stage 2's same-address migration mechanic. The token contract address doesn't change when an issuer moves to quantum-safe signers.

What to watch

1. Stage 1 CAP / proposal text. The Soroban host-function additions land via the SDF protocol process — the canonical place for ML-DSA-44 and ML-DSA-65 host-function specs to surface is stellar/stellar-protocol on GitHub. The CAP number and exact host-function signatures aren't published in the announcement.
2. soroban-sdk release. Once host functions are in Soroban, the Rust SDK exposes them. The first soroban-sdk crate version with ML-DSA verification bindings is the developer-side signal that Stage 1 has shipped, not the blog post.
3. Reference contract account implementations. SDF's pattern repository typically publishes an example contract account using each new authentication primitive. That code becomes the de-facto template the ecosystem forks from.
4. Stage 2 CAP draft. A Core Advancement Proposal for native quantum-safe signers needs to surface well before 2027 to allow validator review and a Stage 2 protocol upgrade vote.

Context — Stellar is early, not first

Post-quantum migration on production chains is no longer hypothetical. The QPP is the first explicit, dated multi-stage plan from a top-30 chain. Zcash's NU6.2 hard fork on May 27 patched an Orchard circuit soundness flaw — a different layer of the stack but the same pattern of treating cryptographic robustness as live infrastructure rather than long-term R&D (prior coverage). Ethereum's account-abstraction roadmap (EIP-7702 in Pectra) provides a comparable lever for swapping signing keys without changing the address, though no equivalent post-quantum signer type has been EIP-drafted yet. Bitcoin Core has open discussion of post-quantum migration but no shipping code path.

The structural asymmetry — Stellar can route through Soroban before touching classic accounts — gives it a faster Stage-1 deployment than chains where signing keys are baked into the address derivation. Whether the rest of the industry follows the same two-stage pattern (contract-layer first, protocol-layer second) is the open question for the next twelve months.

Sources:

• Stellar Development Foundation — Introducing the Quantum Preparedness Plan (primary).
• Decrypt — A Quantum Clock Is Ticking for Bitcoin and Crypto: How Stellar Is Preparing.
• NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA).
• The Quantum Insider — Q-Day Just Got Closer: Three Papers Rewriting the Quantum Threat Timeline.