Introducing the Quantum Preparedness Plan

Today we're introducing the Quantum Preparedness Plan (QPP) for the Stellar Network—the program to migrate the network to quantum-safe cryptography.

By the end of 2027, in addition to the structural advantage Stellar has with account identity being separate from signing keys, every Stellar account is expected to be able to add a quantum-safe signer through a native protocol upgrade, keeping the same address and the same history. Enterprise wallets are expected to be able to move to quantum-safe signing in 2026 through Soroban contract accounts.

Quantum computers will eventually break the elliptic curve cryptography that secures nearly every blockchain, including Stellar. This is not speculative—it is a mathematical certainty given a sufficiently powerful quantum computer. The open question is when, not if.

Importantly, this threat extends far beyond blockchains. Elliptic curve and RSA cryptography underpin TLS, SSH, code signing, and virtually all secure communications that secure the internet as we know it. Every major industry—finance, healthcare, defense, telecommunications—faces the same migration challenge. This means significant resources across the global technology ecosystem are working on post-quantum solutions, producing mature standards, tooling, and implementation experience that the Stellar ecosystem can leverage.

Recent developments have compressed the timeline. In early 2026, INRIA researchers showed that breaking 256-bit elliptic curves (the family Stellar's Ed25519 belongs to) requires only 1,193 logical qubits—a 44% reduction from prior estimates and fewer than what's needed to break RSA-3072. Separately, new quantum error correction architectures have reduced the physical qubit overhead for cryptographic attacks by an order of magnitude. National Institute of Standards and Technology (NIST) guidance, which previously placed the danger zone at 2030 and beyond, has been updated to 2029+. Google has set 2029 as its internal deadline for post-quantum readiness across its systems—and Google both builds quantum hardware and employs the researchers behind these advances.

On the standards side, NIST finalized the first post-quantum cryptographic standards in 2024 (ML-DSA for signatures, ML-KEM for key encapsulation), with additional schemes in the pipeline. The building blocks for migration now exist. Other blockchains are already moving: Ethereum has drafted an emergency hard fork plan, Bitcoin has BIP-360, and Algorand has deployed Falcon-based state proofs. Regulatory frameworks—CNSA 2.0 in the US, DORA in the EU—are recommending PQ migration timelines for financial infrastructure, signaling the direction of future compliance expectations.

The combination of an accelerating threat timeline, finalized standards, and industry momentum makes this the right time to define the strategy for Stellar. Starting now ensures a deliberate migration rather than waiting to respond to a crisis.

There are two threats to Stellar from sufficiently powerful quantum computers, and they require different solutions.

Network integrity. Stellar Consensus Protocol messages are authenticated with Ed25519 signatures by validators. An attacker who can forge enough validator signatures to control quorum intersection can compromise consensus itself. This is a serious threat but a more tractable coordination problem—there are hundreds of validators, not tens of millions of accounts. Network integrity will be addressed through a protocol upgrade to SCP.

Account takeover. Shor's algorithm can derive the private key for any Ed25519 public key. On Stellar, account addresses (G... addresses) directly encode the Ed25519 public key, which means every account address on the network is a target—including dormant accounts that have never authorized a transaction. This is a structural difference from Bitcoin and Ethereum, where addresses are hashes of public keys and only become exposed after first use.

Account takeover is the harder problem and the focus of QPP.

On most chains, the account address is the public key. Rotating keys means moving balances to a new account and updating every external system that references the old address.

On Stellar, account identity is separated from signing keys. The G... address is a stable identifier, and the keys that authorize transactions on the account can be rotated through the existing set_options operation without changing the address. A Stellar account does not need to migrate to a new account to become quantum-safe. It needs to add a quantum-safe signer to the account it already has, weight it appropriately, and then remove the legacy Ed25519 signer.

The piece missing today is the quantum-safe signer type itself, along with the protocol primitives required to verify quantum-safe signatures efficiently. QPP is, in large part, about building that signer type and the infrastructure around it.

Stage 1—Building blocks and contract accounts (2026). Add post-quantum signature verification to Soroban as native host functions, supporting ML-DSA-44 and ML-DSA-65—the enterprise-grade NIST signature standards. With those primitives in place, contract accounts can implement quantum-safe authentication through Soroban's account abstraction layer, with no protocol-level change to classic accounts required. Enterprise wallets can migrate to quantum-safe contract accounts in 2026. Additional schemes will be added over time as standards get finalized (FN-DSA aka Falcon) or as broader ecosystem support is added (HSM support for cloud deployment for example).

Stage 2—Protocol-level enshrinement and opt-in migration (2027). A Core Advancement Proposal will introduce quantum-safe signer types as first-class signers on classic accounts. Every existing G... account can add a quantum-safe signer alongside its Ed25519 signer through set_options. No new account type, no address change, no balance migration. Wallets, SDKs, anchors, and SEPs will be updated to support quantum-safe key generation, signing, and verification.

Stage 3—Deprecation (timing determined by the threat). Readiness work will be complete in 2027. Activation—the ledger at which Ed25519 is no longer accepted for new transaction authorization—will be determined by quantum computing progress and ecosystem readiness.

Activation will require community input as it's likely that it will come with some disruption to some accounts: Stellar has a large population of dormant accounts whose holders are unreachable. Any forced cutoff requires freezing these accounts and must choose between providing a recovery mechanism (Stellar, unlike many other chains supports seed-based proofs), or accepting that they become permanently locked. We will be opening this for community design discussion rather than presenting a unilateral decision.

The QPP does not yet address pairing-based zero-knowledge protocols built on Stellar. Several ZK protocols rely on SNARKs over curves such as BN254 and BLS12-381, which Shor's algorithm breaks for the same reason it breaks Ed25519. Unlike signature schemes, there is no drop-in post-quantum replacement for pairing-based SNARKs with comparable performance. STARKs and lattice-based proof systems are candidates, each with significant trade-offs.

This is a problem the broader industry will need to work through together. As part of QPP we will convene ZK protocol teams building on Stellar to develop a shared research agenda.

The QPP is not work SDF can execute alone. Validators, wallets, anchors, custodians, SDK maintainers, and Soroban contract developers all have a role. Over the coming weeks we will publish detailed technical specifications, open community discussion on the dormant account question, and begin protocol-level conversations on Soroban host function support for post-quantum signature verification.