STELLAR · L1 · STAGE 0 UNAWARE · QRI 22 v3.1.0 methodology

In plain terms

What it is. Stellar is a payments network where the account address you share is also the lock that guards it, and the team has done nothing to prepare those locks for quantum computers.

What we found. Because each address openly shows its own lock from the day the account is opened, a future quantum computer could copy the key for any account, including balances that have sat untouched since 2015, and recent upgrades only added more of the breakable old math.

Why it matters. Anyone holding or storing value here is exposed the moment such a machine exists, and the team that runs smooth upgrades every year still has no plan to fix it.

Stellar's classical-only stack is going deeper into pairing-based cryptography, not toward PQ. Protocol 22 (2024-12) added BLS12-381 host functions to Soroban; Protocol 25 X-Ray (2026-01-22) added BN254 plus research-grade Poseidon. Account IDs ARE Ed25519 public keys (no hash wrapper), so every account is pubkey-revealed from creation. Zero PQ statement, zero PQ code, zero PQ traffic.

inLinkedIn ↷Audit access ⇆Compare Verified 2026-05-01

Summary

Stellar runs entirely on classical-only cryptography across consensus, account signing, and the Soroban smart-contract host. SCP federated voting authenticates messages with Ed25519 over SHA-256 envelopes. Account IDs are Ed25519 public keys directly (G... strkey is the pubkey, not a hash), so every account is in the pubkey-revealed Forge category from creation. The Soroban host expanded its Shor-vulnerable surface in late 2024 (BLS12-381 G1/G2 + multi-pairing-check via CAP-0059) and again in January 2026 (BN254 via CAP-0074, Poseidon/Poseidon2 via CAP-0075). Mainnet PQC traffic 0%. SDF has shipped 25 numbered protocol upgrades since 2015 with smooth coordination, and just executed Protocol 25 X-Ray cleanly on 2026-01-22; the coordination machinery for a PQ migration exists but no PQ program does. Gate 1a-Sig FAIL, Gate 1a-KEM FAIL. No Stellar Improvement Proposal, no working group, no roadmap entry mentions post-quantum. Honest silence rather than announcement-to-shipped. QRI 22, Band 1 Unaware.

What the gates say

Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition for Stellar accounts or SCP
Gate 1a, Hybrid KEM: FAIL , Horizon TLS, Stellar RPC TLS, stellar-core peer transport all classical X25519 / RSA / ECDH
Gate 1b, Commit-to-hash: COND , no OR-composition declared
Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from public artifacts in 48 hours; ≥ 5 URLs per sub-score
Gate 3, Primitive naming: PASS , Ed25519, secp256k1, secp256r1, BLS12-381, BN254, Poseidon, SHA-256, SCP all named with mechanism

Burn-vs-rescue policy on file

Declared option f, Undeclared. SDF has not published a position on dormant-balance handling, freeze, burn, rescue, hybrid client-layer, rate-limit canary, or optional migration for quantum-vulnerable XLM accounts.

Seven dimensions

Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.

1 Cryptographic Exposure weight 15% 26 / 100

1a · primitive inventory 13 / 20

Inventory fully public and reconstructible. The 2026-01-22 X-Ray upgrade adds further Shor-vulnerable pairing-curve and research-grade hash exposure; the surface expands, it does not contract.

Primitives: Ed25519 (account signatures, default signer type per Stellar XDR) · Ed25519 Signed Payload Signer (CAP-0040) · Hash(x) signer (SHA-256 preimage-reveal) · Pre-authorized-transaction signer (SHA-256 hash of future tx) · SHA-256 (block hashing, quorum-set hashing, transaction-hash domain) · SCP federated voting (Ed25519 over SHA-256 envelopes; not aggregation) · ECDSA secp256k1 verify (Soroban host, Protocol 22) · ECDSA secp256r1 verify (CAP-0051, Soroban host) · BLS12-381 G1/G2 + multi-pairing-check (CAP-0059, 16 host functions) · BN254 G1 + multi-pairing-check (CAP-0074, Protocol 25 X-Ray) · Poseidon / Poseidon2 (CAP-0075, Protocol 25 X-Ray)

1b · shor grover pq tag 5 / 20

Tags:

Ed25519 → Shor-break-via-DL-without-pairings
ECDSA secp256k1 → Shor-break-via-DL-without-pairings
ECDSA secp256r1 → Shor-break-via-DL-without-pairings
BLS12-381 (G1/G2 + multi-pairing-check) → Shor-break-via-pairings
BN254 → Shor-break-via-pairings
SHA-256 → Grover-weaken (256→128-bit)
Poseidon / Poseidon2 → research-grade arithmetic-circuit-friendly hash, Grover-weaken (cryptanalytic tier 4)

1c · family diversity 0 / 20

Zero PQ-safe families deployed. Classical-only across Edwards-curve EdDSA, Weierstrass-curve ECDSA, pairing-friendly curves, SHA-2, and arithmetic-friendly hashes.

1d · nist security category 2 / 20

Ed25519 / secp256k1 / secp256r1 ≈ 128-bit classical / 0-bit post-Shor. BLS12-381 ≈ 120–128-bit classical / 0-bit post-Shor. BN254 ≈ ~100-bit classical (post-2017 ex-TNFS) / 0-bit post-Shor. SHA-256 ≈ 128-bit post-Grover. No NIST PQC FIPS 203/204/205/206 category mapped.

1e · implementation quality 6 / 20

SCP has machine-checked safety proofs (Mazières et al. SCP whitepaper + IETF draft). Ed25519 / secp256k1/r1 in stellar-core are standard well-tested libraries. soroban-env-host (Rust) for host-function crypto using bls12_381, k256, p256, ark-bn254 crates. Stateless across all primitives. Cryptanalytic tier 1 for Ed25519 / SHA-2 / ECDSA-secp256r1; tier 1–2 for BLS12-381; tier 4 for Poseidon.

2 Quantum Recovery Exposure weight 10% 18 / 100

Forge subtotal: 12/75 Decrypt subtotal: 6/25

2a · active key exposure 5 / 25

Stellar accounts ARE Ed25519 public keys directly: G... strkey-encoded addresses are the public key, not a hash. The pubkey is exposed at account-creation time. Every active account is in the pubkey-revealed category from genesis. CRQC-Shor-forgery applies to 100% of active accounts.

2b · cold key exposure 3 / 25

Because the strkey address IS the Ed25519 public key, there is no cold-key hash-protection regime on Stellar. Mainnet live since 2015-07-31, so a decade of dormant XLM is fully pubkey-exposed. The cold-key forgeability surface is structurally larger than for hash-address chains.

2c · sig long term validity 4 / 25

Every historical Ed25519 transaction signature is Shor-forgeable post-CRQC. Light-client schemes verify SCP messages via Tier-1 quorum, relying on Ed25519 validator signatures over SHA-256 message hashes, a CRQC adversary can forge historical SCP nominate/prepare/commit messages. Seven Tier-1 organizations operate 21 Tier-1 validators.

2d · encryption confidentiality hndl 6 / 25

Stellar peer-to-peer transport (stellar-core overlay) uses standard TLS for inbound RPC (Horizon, Stellar RPC) and a stellar-core specific peer auth protocol over TCP. No documented hybrid PQ KEM at any layer. Validator gossip transport for SCP messages between Tier-1 nodes likewise classical.

3 Metadata, Anonymity & Confidentiality weight 13% 23 / 100

3a · tx graph visibility 4 / 20

Fully transparent ledger; payment memos commonly carry user-identifiers, customer-IDs, or external-account references (MEMO_TEXT/MEMO_ID/MEMO_HASH plus muxed-account scheme in CAP-0027/SEP-0023). USDC issuance via Circle and the anchor network add 60+ named regulated counterparties with on-chain Ed25519 issuing accounts.

3b · rpc mempool concentration 6 / 20

Public Horizon and Stellar RPC endpoints concentrated among SDF-hosted Horizon, Blockdaemon, QuickNode, Validation Cloud, plus Tier-1 validator-operated endpoints. Fee-pool / surge-pricing model means transaction-queue ordering is observable to participating nodes. No protocol-level validator-metadata-retention policy declared.

3c · cross chain bridge correlation 5 / 20

Allbridge Core, Squid via Axelar, and Wormhole-class bridges connect Stellar to EVM and Solana. USDC on Stellar is multi-chain by Circle's design, so passive observers can correlate Stellar source-of-funds against Ethereum / Solana / Avalanche destinations. Anchor flows tie Stellar addresses to off-chain KYC by design.

3d · retroactive de anonymization 8 / 20

Stellar does not deploy ZK-shielded transactions or DL-based ring signatures at protocol level today. X-Ray (Protocol 25, 2026-01-22) adds primitives for ZK applications (BN254, Poseidon) but no shielded-pool feature has shipped. Once ZK applications are built on top of new BN254/Poseidon primitives, any pairing-based application-layer privacy will be retroactively breakable under Shor.

3e · mixnet shuffle 0 / 20

None at protocol level.

4 Migration Architecture weight 10% 55 / 100

4a · crypto agility 6 / 15

Stellar XDR signer-type union is documented as extensible (PUBLIC_KEY_TYPE_ED25519 today), and signature size is variable per scheme. The signer-type extensibility (Hash(x), pre-auth-tx, Ed25519, Ed25519 Signed Payload via CAP-0040) is the agility surface. CAP-0051 (secp256r1) shows Soroban host can add new signature primitives via a finite CAP path. However, no in-protocol signature-scheme switch primitive at the account level.

4b · aa key rotation 9 / 20

Native multisig (weighted thresholds 0–255 across low/medium/high operation thresholds), pre-authorized transactions, Hash(x) signers, and Ed25519 Signed Payload Signers (CAP-0040). Soroban contracts can implement custom-account-contract authorization (__check_auth host pattern). Closer to AA than EOA-only chains, though not a per-account abstraction layer comparable to ERC-4337 / EIP-7702.

4c · hard fork track record 11 / 15

SDF has shipped 25 numbered protocol upgrades (Protocol 1 → Protocol 25 X-Ray, mainnet 2026-01-22), with regular cadence and SDF-coordinated validator-vote mechanism. Recent shipped upgrades include Protocol 22 (2024-11), 23, 24, and 25 X-Ray. One delayed upgrade (Soroban smart-contracts) was held back rather than ship a known bug.

4d · hybrid deployment readiness 3 / 15

No published PQ hybrid roadmap. No dual-stack Ed25519+ML-DSA spec or testnet branch identified in stellar-core or stellar-protocol. The architectural agility means a hybrid signature path is not foreclosed, but no document or merged spec specifies one.

4e · stateful hash state management 15 / 15

Stellar uses no stateful hash-based signature scheme. Default 15/15 per v3.1 rule for stateless schemes.

4f · bft aggregation path 0 / 0

N/A, SCP uses per-validator Ed25519 signatures over message envelopes; SCP is Federated Byzantine Agreement built on quorum slices, NOT BLS aggregation at consensus. The BLS12-381 host functions added in CAP-0059 are exposed to Soroban smart contracts, not used in consensus.

5 Deployment Execution weight 22% 13 / 100

5a · mainnet pqc traffic pct 0 / 25

Mainnet PQC traffic % = 0%. No PQ signature primitive deployed on the protocol or in Soroban host. The X-Ray upgrade (2026-01-22) added BN254 and Poseidon, not PQ.

5b · pqc code in consensus client 1 / 15

No PQ primitive code merged in stellar-core. The crypto subsystem lists Ed25519, ECDSA, and (in soroban-env-host) BLS12-381 / BN254 / Poseidon. No liboqs import, no ML-DSA / Falcon / SLH-DSA branch identified.

5c · validator pqc key adoption 0 / 15

Zero of 21 Tier-1 validators (across the 7 Tier-1 organizations: SDF, Blockdaemon, SatoshiPay, LOBSTR, Public Node, Creit Technologies, Franklin Templeton) operate any PQC key. SCP validator keys are Ed25519.

5d · published dated milestones 0 / 10

VOIDED to 0 per v3.1 rule (5d voided when 5a = 0). SDF has not published any PQ milestone, working group, or sunset date. The 2025 SDF Product Roadmap and the End of Year 2025 Report contain no post-quantum, PQC, ML-DSA, Falcon, or quantum-readiness language.

5e · pqc washing delta 12 / 15

Announced PQC count 0; shipped PQC bytes 0; ratio undefined. Tag: none, honest silence rather than narrative-only or aspirational PR.

5f · signature footprint multiplier 0 / 20

No published PQ signature footprint analysis from SDF. Ed25519 signatures are 64 bytes; ML-DSA-44 ~2420 bytes (~38×); Falcon-512 ~666 bytes (~10×); SLH-DSA-128s ~7856 bytes (~123×). Stellar has not picked a target primitive. Per rubric (>38× or undisclosed = 0).

6 Supply Chain Vendor Readiness weight 22% 9 / 100

6a · wallet 2 / 25

Top-3: Freighter (browser extension, SDF-maintained), LOBSTR (mobile + web), Ledger (HW). None has published a PQC roadmap for Stellar key types. Hardware wallet PQC support not Stellar-specific and not currently shipping for Ed25519 → ML-DSA migration on any chain.

6b · bridge 2 / 25

Top-3 venues: Allbridge Core, Squid Protocol, Wormhole-class native interop (USDC native via Circle Multi-Chain). No PQC roadmap on any. All rely on classical ECDSA / Ed25519 / BLS12-381 validator-set or guardian signatures.

6c · custodian 3 / 25

Top-3 by AUC: Coinbase Custody, BitGo (~$90B AUC, OCC national bank charter approved Dec 2025), Anchorage Digital (US qualified custodian, bank charter). All deploy threshold-cryptography (MPC) on classical secp256k1 / Ed25519 today.

6d · rpc hsm tee infra 2 / 25

Top RPC / infra: Stellar RPC (SDF-hosted), Blockdaemon, QuickNode, Validation Cloud. No PQC TLS (hybrid X25519+ML-KEM-768) confirmed across Stellar RPC fleet. HSM stack generic. No TEE attestation chain declared as part of the Stellar validator stack.

7 Governance & Coordination weight 8% 41 / 100

7a · validator stake distribution 6 / 20

7 Tier-1 organizations operating 21 Tier-1 validators (3 each) as of April 2025: SDF, Blockdaemon, SatoshiPay, LOBSTR, Public Node, Creit Technologies, Franklin Templeton. Quorum graph means consensus halts if 3 of 7 organizations go dark. SDF target to grow to 13 Tier-1 organizations by Q4 2025. Concentration is structural to Federated Byzantine Agreement. Client diversity: stellar-core dominant.

7b · upgrade cadence under pressure 13 / 20

25 protocol upgrades shipped since 2015; SDF coordinates validator-vote on each via stellar-core protocolVersion. Protocol 22 (2024-11), Protocol 25 X-Ray (2026-01-22) cadence is ~annual. One delayed upgrade was held back rather than ship a known bug.

7c · named coordination lead 14 / 20

Stellar Development Foundation (SDF) is the named single foundation, headquartered San Francisco, with a published roadmap, named CEO (Denelle Dixon), and a 10+ year track record of protocol coordination. CAP/SEP process documented and run on a public GitHub repo.

7d · adversarial coordination precedent 8 / 20

No cryptographic emergency precedent. The 2019 inflation-pool removal (CAP-0007) was coordinated cleanly. The 2017 disruption / consensus halt was resolved within hours under SDF coordination. No precedent of coordinating a cryptographic primitive change under active attacker.

7e · canary tripwire mechanism 0 / 20

None. No community honeypot, rate-limited spending rule, cryptographic tripwire embedded in SCP, or automated response declared.

X + Y vs Z, when does the math turn against you?

v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?

X, signature shelf life

10–30+ years (historical signatures since 2015), active-key forge horizon 1–15 years

Y, migration time

5–15+ years (undeclared)

Z10 (10% CRQC year)

2030

Z25 (25% CRQC year)

2035

Verdict

X+Y reaches 2031–2041+, Crisis Zone (vs Z10 2030); Outside risk window (vs Z25 2035)

Z-compliance

Outside NIST 2030 deprecation window and likely outside 2035 disallowance threshold absent rapid acceleration

Source-disagreement disclosure

v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.

X-Ray upgrade framing

X-Ray release notes describe BN254 and Poseidon as ZK enablers without quantum-readiness commentary. The 2025 SDF roadmap omits PQ entirely; the 2025 Year-in-Review focuses on usability, throughput, and decentralization. Cross-source consistency on Stellar's classical-only crypto status is high.

Delta-QRI under alternative weighting

Under privacy-focused-chain alternative-weighting (12/10/25/12/18/18/5), Stellar's transparent-ledger and zero-shielded-application stance pushes Dim 3 contribution slightly down and Dim 6 contribution down, leaving raw QRI similar (~21). Under a rollup-L2 weighting, Stellar would be misclassified, Stellar is an L1.