Stellar XLM Quantum Security: Ed25519 Keys and Multi-Signature Migration Risk

Stellar is a blockchain network designed for fast, low-cost cross-border payments and asset issuance. Founded in 2014 by Jed McCaleb and Joyce Kim following the Ripple fork, Stellar has developed into a significant payments infrastructure, used by money transfer services, financial institutions, and several central bank digital currency (CBDC) pilot programs. Its Lumens (XLM) token fuels the network, but the network's value proposition centers on its payment rails rather than its token speculation.

From a quantum security perspective, Stellar presents a uniquely concerning profile. It uses a single signature scheme, Ed25519, for all account key pairs. And its address format is designed so that the Stellar public address is literally the Ed25519 public key, encoded in a specific base-32 format. There is no intermediate hash, no address abstraction, and no protection layer between the address and the key. Every Stellar account, active or dormant, has its full public key permanently and irrevocably visible to any observer.

Is Stellar Quantum Safe?

No. Stellar uses Ed25519 exclusively, and every Stellar address is a direct StrKey encoding of the 32-byte Ed25519 public key. There is no hash-layer protection. Every Stellar account's public key is permanently visible on-chain, making 100 percent of Stellar accounts fully exposed to a quantum attacker who can run Shor's algorithm. The Stellar Development Foundation has not published a post-quantum roadmap.

The directness of Stellar's key-to-address mapping is by design. Stellar aimed for simplicity and transparency in its account model: the public key is the account identifier. This is an elegant design choice for classical computing, where the public key can be freely shared without risk. In a post-quantum world, it is a structural liability that cannot be mitigated by protocol-level address obfuscation, because there is no obfuscation layer to preserve.

How Stellar Account IDs Are Derived

Stellar account IDs use a format called StrKey, a base-32 encoding scheme with a version byte and a checksum. An Ed25519 public key (32 bytes) is taken, prefixed with a version byte (6 for accounts), and encoded in base-32 to produce a 56-character string starting with "G". This is a Stellar account address (for example: GABC...XYZ). The encoding is fully reversible: given any Stellar account address, you can extract the exact 32-byte Ed25519 public key with a simple decode.

Compare this to Bitcoin's P2PKH format, where the address is derived by hashing the public key with SHA-256 and then RIPEMD-160. A Bitcoin P2PKH address holder who has never spent from that address has not revealed the underlying public key. An attacker who sees only the address cannot retrieve the public key without the one-way hash reversals that remain computationally infeasible even with quantum computers (SHA-256 is broken by Grover's algorithm but only quadratically, not enough to reverse a hash in practice).

Stellar has no such protection layer. The address is the public key. Every Stellar address ever shared in a payment, posted on an exchange deposit page, included in a cross-border transfer, or used in a CBDC pilot is a complete disclosure of the Ed25519 public key. A quantum attacker can take any Stellar address and compute the corresponding private key using Shor's algorithm, without waiting for a transaction to reveal additional information.

Multi-Signature Accounts on Stellar

Stellar supports multi-signature accounts through a flexible threshold system. An account can add multiple Ed25519 signing keys, each with a weight. Operations on the account require signatures whose combined weight meets or exceeds the configured threshold. This enables M-of-N multi-signature setups, corporate account controls, and distributed governance of token issuers.

From a quantum security perspective, multi-signature on Stellar provides no additional protection. Each signer key is an Ed25519 public key, and each is individually exposed via the address. A quantum attacker targeting a multi-signature Stellar account would need to break enough of the participating keys to meet the signing threshold. If the threshold is 2 of 3, breaking any two of the three Ed25519 keys (each independently vulnerable) would be sufficient. With all keys already visible on-chain, the attacker has all the information needed to precompute any key in the set.

This is particularly relevant for institutional Stellar users. Financial institutions that have implemented multi-signature governance on Stellar asset issuer accounts, or on escrow accounts holding funds for payment services, face the same vulnerability as individual holders. The multi-signature setup adds classical security (protection against a single compromised key) but provides no quantum security benefit.

The CBDC Exposure Risk

Stellar has been involved in several CBDC pilot programs, including discussions with central banks exploring tokenized national currencies. The quantum exposure of Stellar's cryptographic foundation has specific relevance for CBDC applications for two reasons.

First, CBDCs involve government-issued liabilities. The integrity of the cryptographic layer is a matter of national financial security, not just individual user risk. A quantum attack that allows an attacker to steal CBDC funds, forge transactions, or take control of the government's issuer account would be a systemic financial incident with potential macroeconomic consequences. The security standards for CBDC infrastructure are, appropriately, higher than for speculative cryptocurrency applications.

Second, CBDCs have long lifespans. A CBDC built on Stellar infrastructure today could be in production in 2030, 2035, or beyond. The harvest now, decrypt later threat pattern means that transaction data and public keys collected today could be used to mount attacks years later. Central banks designing CBDC infrastructure need to either plan for post-quantum migration from the start or accept that their infrastructure will need to be replaced or substantially upgraded within the quantum threat window.

The Stellar Development Foundation's current public materials do not address these concerns with respect to quantum computing. For a broader analysis of CBDC quantum security requirements, see our CBDC quantum security analysis.

Stellar Development Foundation's Position

The Stellar Development Foundation (SDF) has not published a post-quantum cryptography roadmap. The Stellar protocol upgrade process operates through the Stellar Ecosystem Proposals (SEP) and Core Advancement Proposals (CAP) mechanism. No CAP addressing quantum-resistant signatures has entered the review process as of mid-2026.

The SDF's public focus has been on expanding Stellar's payments ecosystem, growing anchor networks, and supporting the Stellar Smart Contracts (Soroban) environment. Post-quantum security has not been a stated priority. Given Stellar's positioning as a payments infrastructure (where migration lead times and institutional coordination are more complex than in purely speculative cryptocurrency use cases), the absence of a migration roadmap represents a growing strategic risk as quantum timelines compress.

Signature Scheme Comparison

What a Post-Quantum Migration Would Require for Stellar

A post-quantum migration for Stellar would need to introduce a new account key type based on a NIST-standardized post-quantum signature scheme (ML-DSA or SLH-DSA). This would require a Stellar CAP defining the new key format, the StrKey encoding for post-quantum public keys, and the transaction signing rules for the new scheme. The CAP process requires approval from the Stellar validator community and implementation across all validator nodes.

The migration campaign itself is the hard part. Stellar's user base spans individual XLM holders, institutional users managing asset issuers and anchors, payment service providers, CBDC pilots, and exchange custody operations. Each category has different coordination requirements and different lead times for key migration. Individual wallets need software updates. Institutional users need internal key management processes updated. CBDC operators need regulatory approval for any cryptographic infrastructure change.

The fact that every Stellar address is already a public key means there is no "safe" category of accounts to protect during a migration transition period. From the moment a cryptographically relevant quantum computer becomes operational, every unrotated Stellar account is immediately vulnerable. There is no grace period from hash-layer protection, as Bitcoin P2PKH addresses have for funds that have never moved. Stellar's quantum migration is more urgent and less forgiving than many other chains precisely because of its direct key-to-address mapping.

For context on how this compares to other chains' migration challenges, see our analysis of the blockchain quantum migration problem.