Inventory fully public and reconstructible, including the transport layer named from stellar-core source (Curve25519 ECDH, HKDF, HMAC-SHA256). The XDR type definitions bound the classic-account surface precisely: the PublicKey union carries exactly one case, PUBLIC_KEY_TYPE_ED25519 over a uint256, and SignerKeyType carries four cases, all classical. CAP-0087 (Draft) enumerates the complete Soroban signature host-function surface and names ML-DSA-44/65/87 per FIPS 204 with exact verifying-key and signature byte sizes as the proposed first PQ addition; nothing PQ is merged or activated. The deployed protocol surface is unchanged since the Protocol 26 ZK BN254 host functions.

Every deployed protocol-level and account-level primitive is Shor-vulnerable or Grover-weakened. The Quantum Preparedness Plan states the same conclusion for both threat classes it identifies: Shor's algorithm can derive the private key for any Ed25519 public key, and the pairing-based ZK protocols built on BN254 and BLS12-381 break for the same reason. The two PQ-safe lattice entries are a Draft proposal and a third-party application contract respectively, neither in the consensus or classic-account path.

Zero PQ-safe families deployed. Classical-only across Edwards-curve EdDSA, Weierstrass-curve ECDSA, pairing-friendly curves, SHA-2 and arithmetic-friendly hashes. The proposed path is lattice-only (ML-DSA per CAP-0087) and the third-party Falcon-512 contract is the same lattice family. SLH-DSA (hash-based, FIPS 205) is placed second in the priority order stated by the CAP author in the protocol discussion on 2026-05-13, and the Quantum Preparedness Plan says additional schemes will be added over time, but no SLH-DSA CAP is filed, so no second family is in scope.

Ed25519 / secp256k1 / secp256r1 ≈ 128-bit classical / 0-bit post-Shor. BLS12-381 ≈ 120 to 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. CAP-0087 (Draft) maps its proposed primitives to NIST categories exactly, matching NIST IR 8547 Table 3: ML-DSA-44 category 2 (1312-byte verifying key, 2420-byte signature), ML-DSA-65 category 3 (1952 / 3309), ML-DSA-87 category 5 (2592 / 4627). The third-party Falcon-512 contract targets NIST Level I per the Falcon Round-3 specification. No NIST-PQC-categorized primitive is deployed at protocol level.

Ed25519 and ECDSA secp256k1/secp256r1 in the reference stack use standard, widely reviewed libraries: ed25519-dalek 2.0.0, k256 0.13.3 and p256 0.13.2 in soroban-env-host, with ark-bls12-381 0.5.0 and ark-bn254 0.5.0 for the pairing host functions, plus sha2, sha3, hmac and curve25519-dalek. Rust ed25519-dalek verification is enabled at the Protocol 24 boundary in stellar-core and cannot be disabled once enabled. All deployed schemes are stateless. Cryptanalytic tier 1 for Ed25519 / SHA-2 / ECDSA-secp256r1; tier 1 to 2 for BLS12-381; tier 4 for Poseidon. Deployed-verifier provenance for PQ is 0: the only deployed PQ verifier is the third-party Falcon-512 contract, self-described as not audited, whose vendor states it is winding down; the community TestNet ML-DSA path is guest-side WASM with no published audit. CAP-0087's own Security Concerns section states that the host functions would wrap an external library, that several candidates are being evaluated, and that most ML-DSA implementations are early, immature and lack auditing or formal verification. An SDF engineer deprioritized Falcon host functions citing floating-point operations that are architecture dependent and therefore a determinism risk, a sound implementation-quality concern recorded before any code exists. LayerQu did not corroborate a machine-checked SCP safety proof this run and makes no such claim.

Stellar account IDs are Ed25519 public keys directly: the G-prefixed strkey is a base32 encoding of the raw 32-byte Ed25519 public key with a version byte and CRC16 (STRKEY_PUBKEY_ED25519 = 6 maps to 'G' in stellar-core src/crypto/StrKey.h), not a hash. The Quantum Preparedness Plan states the same in SDF's own words: account 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. The master key's weight can be set to 0 and additional signers added through set_options, but every available signer type is itself an Ed25519 key or a SHA-256 digest recorded in the ledger, so rotation does not remove the exposed verifying key from public view. CRQC-Shor-forgery applies to 100% of active accounts.

There is no hash-address regime on Stellar: the address is the verifying key, so a dormant account's Ed25519 public key is public without any spend ever occurring. The MainNet network passphrase, 'Public Global Stellar Network; September 2015', dates the ledger to 2015, so a decade of dormant XLM is fully pubkey-exposed. The Quantum Preparedness Plan acknowledges a large population of dormant accounts whose holders are unreachable, states any forced cutoff requires freezing them, and defers the handling mechanism to community design discussion.

Every historical Ed25519 transaction signature is Shor-forgeable post-CRQC. Light-client schemes verify SCP messages through the Tier-1 quorum, relying on Ed25519 validator signatures over SHA-256 message hashes, so a CRQC adversary can forge historical SCP nominate/prepare/commit messages. The Quantum Preparedness Plan names this explicitly as the network-integrity threat: an attacker who can forge enough validator signatures to control quorum intersection can compromise consensus itself. SDF's live quorum set comprises 21 validators across 7 organizations at threshold 5 (read 2026-08-20).

Stellar overlay peer authentication (stellar-core src/overlay/PeerAuth.h) uses ephemeral Curve25519 ECDH key agreement with HKDF_extract/HKDF_expand derivation and HmacSha256Key per-session send and receive MAC keys, with the long-lived node identity key being Ed25519; inbound RPC (Horizon, Stellar RPC) uses standard classical TLS. No hybrid PQ KEM such as X25519+ML-KEM-768 is documented at any layer, and the Quantum Preparedness Plan does not address transport confidentiality.

Fully transparent ledger with no confidential-transaction or shielded-pool CAP in Draft, Accepted, Implemented or Final status in the CAP registry. Payment memos commonly carry user identifiers, customer IDs or external-account references: the XDR MemoType enum defines MEMO_TEXT, MEMO_ID, MEMO_HASH and MEMO_RETURN, and the muxed-account scheme (CAP-0027 First-class multiplexed accounts, Final, Protocol 13; SEP-0023 Strkeys, Active) multiplexes many end-users behind one G-account. Regulated asset issuance is on-chain and attributable: USDC on Stellar is natively issued by Circle from the Ed25519 account GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN.

Public Horizon and Stellar RPC access is concentrated among SDF-hosted Horizon plus commercial infrastructure providers and Tier-1 validator-operated endpoints. The fee-pool and surge-pricing model means transaction-queue ordering is observable to participating nodes. No protocol-level validator-metadata-retention policy is declared.

USDC on Stellar is natively issued by Circle and Circle issues the same asset natively on many other networks, so a passive observer can correlate Stellar source-of-funds against off-Stellar destinations without a bridge being involved. Anchor flows tie Stellar addresses to off-chain KYC by design: SEP-0006 (Deposit and Withdrawal API), SEP-0012 (KYC API), SEP-0024 (Hosted Deposit and Withdrawal) and SEP-0031 (Cross-Border Payments API) are all Active in the ecosystem registry. LayerQu did not complete a dedicated inventory of third-party bridge venues; that gap is recorded in source_disagreement rather than asserted as an absence.

Stellar deploys no ZK-shielded transactions and no DL-based ring signatures at protocol level. Protocol 25 X-Ray (2026-01-22) added ZK building blocks (BN254 host functions via CAP-0074, Poseidon/Poseidon2 via CAP-0075) and Protocol 26 added efficient ZK BN254 host functions (CAP-0080, Implemented), but no shielded-pool feature has shipped. The production application ZK path is Groth16 over BLS12-381 (CAP-0059, Protocol 22), which is pairing-based and Shor-breakable, so any application-layer privacy built on it is retroactively breakable. The Quantum Preparedness Plan states that it does not yet address pairing-based zero-knowledge protocols built on Stellar and that there is no drop-in post-quantum replacement with comparable performance. The one community proposal for a hash-based FRI alternative (protocol discussion opened 2026-04-29) built a working BN254 FRI verifier and prover on the poseidon2_permutation host function but does not ship: production parameters exceed the per-transaction CPU budget by roughly two orders of magnitude, blocked on missing batching and aggregation primitives, with no further activity after 2026-05-02.

None at protocol level.

The classic-account key surface is an XDR union with room to grow but no growth to date: PublicKey carries exactly one case (PUBLIC_KEY_TYPE_ED25519) and SignerKeyType carries four, all classical, and the Stellar documentation states that Stellar uses the ed25519 signature scheme but there is also a mechanism for adding additional types of public and private key schemes. Two hard constraints bound how far that mechanism reaches today. First, the XDR signature field is 'typedef opaque Signature<64>', variable-length per its own comment but capped at 64 bytes, so a 2420-byte ML-DSA-44 or 3309-byte ML-DSA-65 signature cannot occupy a classic transaction signature slot without an XDR change, not merely a new SignerKey case. Second, adding a case requires a CAP and a validator-ratified protocol version. CAP-0051 (secp256r1) shows the Soroban host can add new signature primitives through a finite CAP path, and CAP-0087 (Draft) is the only filed CAP applying that path to a PQ primitive. Adjacent live and filed infrastructure a PQ signer composition could build on: CAP-0071 (Final, activated at Protocol 27) adds authentication delegation and address-bound Soroban credentials; CAP-0072 (Draft, no PQ content) would let a Soroban contract act as a signer on a classic G-account. The Soroban custom-account model already admits a PQ-authorized account with no protocol change, as a community TestNet custom account authorized solely by guest-side ML-DSA-65 demonstrated on 2026-08-19, at 77,519,116 instructions per verification, which the measuring author reports as 167 times Ed25519 net of the VM baseline and 24 times ECDSA secp256r1. There is still no in-protocol signature-scheme switch at the classic-account level.

Native weighted multisig with signer weights and low/medium/high operation thresholds in the 0 to 255 range, a master key whose weight can be set to 0, pre-authorized transactions, Hash(x) signers and Ed25519 Signed Payload Signers (CAP-0040). The Quantum Preparedness Plan confirms the live rotation property in SDF's own words: the G-address is a stable identifier and the keys that authorize transactions can be rotated through the existing set_options operation without changing the address. Soroban contracts can implement custom-account authorization through __check_auth, and CAP-0071 (Final, activated with Protocol 27, live on MainNet per the Horizon protocol-version check on 2026-08-20) generalizes Soroban authorization with delegated signatures and address-bound credentials. This is stronger than a single-key model but is not a general per-account programmable authorization module for classic G-accounts; CAP-0072, which would allow a contract to act as a G-account signer, is still Draft. Account-model component 10. The seed-rebind floor (6) applies to single-key Ed25519 accounts and is subsumed by the higher account-model score (MAX selects 10). PQ-rebind bonus is 0: no Stellar-specific seed-rebind design is published and none is deployed; the key-index wire-format idea raised in the protocol discussion is design commentary, and the roadmap's mention of seed-based proofs is an option named for the undecided dormant-account question, not a construction. Dim 2 Forge exposure unchanged. 10.

MainNet has advanced through numbered protocol versions to Protocol 27 (codename Zipper, activated 2026-07-08) since the network's September 2015 epoch, using an SCP-voted ledgerVersion bump coordinated by SDF. Recent activations are dated and documented: Protocol 25 X-Ray 2026-01-22, Protocol 26 Yardstick 2026-05-06, Protocol 27 Zipper 2026-07-08, giving a recent cadence of roughly two to three and a half months. Protocol 28 Adapter continues that cadence with published operational detail: stellar-core v28.0.0 released 2026-08-13, TestNet upgrade vote 2026-08-27 1700 UTC, validator arming deadline 2026-09-09 1700 UTC, MainNet upgrade vote 2026-09-16 1700 UTC, and 38 of 94 validating nodes already running Protocol-28-capable software a month ahead of the vote. The CAP governance taxonomy requires formal acceptance by a majority of validators before a CAP reaches Final, and no contested fork was found in the material reviewed. No primary source supports a claim that a specific upgrade was delayed rather than shipped with a known bug, so none is carried.

The Quantum Preparedness Plan (2026-06-09) documents a dual-stack path in specific terms: Stage 2 (2027 target) states every existing G-account can add a quantum-safe signer alongside its Ed25519 signer through set_options, with no new account type, no address change and no balance migration, and that wallets, SDKs, anchors and SEPs will be updated accordingly. Stage 1's ML-DSA-44/65 Soroban verification is filed as CAP-0087 (Draft). Against that: no CAP exists for Stage 2, no hybrid combiner (AND or OR composition) is specified, no SUF-CMA or commit-to-hash analysis is published, no protocol-level PQC is on testnet, and the 64-byte XDR signature bound means the classic-account wire format itself must change before any Stage 2 signer can carry an ML-DSA signature. Architecturally the weighted-threshold multi-signer model and the Soroban custom-account __check_auth path are natural dual-stack substrates, and a community TestNet custom account already authorizes under ML-DSA-65 while the envelope stays Ed25519-signed; the path is documented but unspecified in protocol terms.

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

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. The Quantum Preparedness Plan states network integrity will be addressed through a protocol upgrade to SCP, but names no primitive, no CAP and no date. Not scored, so it is left out of the dimension total rather than counted as a zero.

Mainnet PQC traffic % = 0%. CAP-0087 (Draft) has no merged implementation in stellar-core or rs-soroban-env: authenticated code search for ML-DSA and dilithium returns 0 results in both repositories, with an Ed25519 query on the same index returning 94 hits as a positive control (queried 2026-08-20). MainNet runs Protocol 27 while CAP-0087's host-function entries set min_supported_protocol 29, and the next scheduled upgrade (Protocol 28 Adapter, MainNet vote 2026-09-16) contains no cryptography CAP. One third-party, unaudited Falcon-512 verifier contract exists on MainNet (deployed 2026-06-11) with one recorded verify call confirmed by a no-auth Horizon query: transaction successful, ledger 62992420, closed 2026-06-12T06:17:17Z. That transaction envelope was itself Ed25519-signed and the contract is application-layer code, not protocol signing traffic, so it rounds to 0%.

No PQ primitive code merged in stellar-core. The crypto subsystem covers Ed25519 and ECDSA, and soroban-env-host covers BLS12-381, BN254 and Poseidon. No liboqs import and no ML-DSA, Falcon or SLH-DSA branch identified. Reconfirmed 2026-08-20: CAP-0087 lists Implementation as TBD and final cost calibration parameters as TBD. A community TestNet measurement published 2026-08-19 reports guest-side ML-DSA-65 verification inside a Soroban contract at 77,519,116 instructions, 19.4% of tx_max_instructions and 13.4% of the per-ledger instruction budget per call against ledger_max_instructions of 580,000,000, versus 1.0% for the ECDSA secp256r1 host function and 0.5% for the Ed25519 host function; that is exactly the gap the CAP proposes to close with native host functions. The measurement is third-party WASM contract code, not client code, and carries no published audit.

Zero of the 21 validators in SDF's live quorum set (7 organizations at threshold 5: SDF, Blockdaemon, OBSRVR, Franklin Templeton, LOBSTR, Creit Technologies, Public Node, three nodes each, read 2026-08-20) operate any PQC key. SCP validator keys are Ed25519, and the public network monitor exposes no PQC-relevant field because there is nothing PQ to observe at the validator layer.

VOIDED to 0 per v3.1 rule (5d voided when 5a = 0). SDF has now published dated milestones for the first time on this chain's record: Quantum Preparedness Plan Stage 1 targeted 2026 (ML-DSA-44/65 Soroban host functions, filed as Draft CAP-0087 with Protocol version TBD), Stage 2 targeted 2027 (quantum-safe signer types on classic accounts, no CAP filed), Stage 3 with readiness work stated complete in 2027 and the Ed25519 cut-off ledger undated. None is protocol-enforced. The Stage 1 2026 target has produced no merged code and no scheduled protocol version in the ten weeks since publication, while the one remaining 2026 upgrade on the calendar (Protocol 28, MainNet vote 2026-09-16) carries no PQC. With zero shipped mainnet PQC traffic the milestone credit is voided regardless. The 2026 target becomes the first entry in this chain's hit/slip/miss record.

Announced PQC now exists: the Quantum Preparedness Plan (2026-06-09) and Draft CAP-0087 (2026-06-05) name ML-DSA-44/65/87 for future deployment, promise quantum-safe classic-account signer types, and promise a later SCP protocol upgrade for network integrity, while shipped SDF PQC bytes on mainnet remain 0, so the announced-to-shipped ratio exceeds the 1.5 deduction threshold (four announced claims, zero shipped, recorded at 2.0). Deduction applied, partly offset on the honesty side: the roadmap is future-tense throughout and states its own open problems (the undecided dormant-account mechanism, and that pairing-based ZK is not yet addressed), and CAP-0087 states explicitly that it does not change the network's Ed25519 transaction signature scheme. Independent press coverage dated 2026-06-09 also describes every stage in the future tense, though it contains no explicit statement that nothing is live on mainnet, so it corroborates framing rather than status. No narrative-only tag.

No published PQ signature footprint or fee-accounting analysis from SDF. Ed25519 signatures are 64 bytes and the XDR field is capped at 64 bytes ('typedef opaque Signature<64>'). CAP-0087's own parameter table gives ML-DSA-44 2420-byte signatures (~38×), ML-DSA-65 3309-byte (~52×) and ML-DSA-87 4627-byte (~72×); the third-party Falcon-512 path is 666 bytes (~10×) per the Falcon Round-3 specification. CAP-0087 lists final calibration parameters as TBD and no transaction-weight recalibration is published; an SDF engineer's discussion proposal to store the verifying key on-ledger and send only the signature would limit per-transaction growth to the signature itself, but it is design commentary, not a spec. Per rubric (>38× or undisclosed = 0).

Wallet tile reviewed across the SDF-maintained browser extension Freighter, the SDF-maintained TypeScript wallet SDK, and the JavaScript SDK. Authenticated code search for 'quantum' returns 0 results in all three repositories, and an ed25519 query against the same index returns hits in each, confirming the search is live rather than empty (queried 2026-08-20). No SDF-maintained wallet tooling contains any PQC-related code or reference, and no reviewed wallet has published a PQC roadmap for Stellar key types. LayerQu did not verify a usage ranking for Stellar wallets, so this tile is described by the surfaces reviewed, not by a claimed top-3 ordering.

No bridge operator serving Stellar was found to have published a PQC roadmap. Cross-chain value movement for Stellar's largest asset runs through native multi-chain issuance rather than a single canonical bridge, and all bridge-class designs in this ecosystem rely on classical ECDSA, Ed25519 or BLS12-381 validator-set or guardian signatures. LayerQu did not complete a dedicated bridge-venue sweep; this tile records an untested gap rather than a confirmed vendor absence, and is scored at the floor accordingly.

No custodian or exchange was found to have published a PQC roadmap covering Stellar key types. Custodial and exchange signing for Stellar assets is performed over classical Ed25519, since that is the only key type the protocol accepts. LayerQu did not complete a dedicated custodian and exchange sweep and does not assert specific custodian names, assets-under-custody figures or charter status; this tile records an untested gap rather than a confirmed vendor absence, and is scored at the floor accordingly.

RPC and infrastructure tile: SDF-hosted Stellar RPC and Horizon plus commercial providers. No PQC TLS (hybrid X25519+ML-KEM-768) is confirmed across the Stellar RPC fleet. The HSM stack is generic and no TEE attestation chain is declared as part of the Stellar validator stack. The one third-party PQC tooling vendor active on Stellar in 2026, and a named consultee on CAP-0087, states on its own site that the project is winding down, is no longer developed or maintained, and that all services are offline, so no active PQC-specialist vendor remains in the Stellar supply chain.

SDF's live quorum set, read 2026-08-20, contains 21 validators across 7 organizations at threshold 5: SDF, Blockdaemon, OBSRVR, Franklin Templeton, LOBSTR, Creit Technologies and Public Node, three nodes each. Threshold 5 of 7 means consensus halts for this quorum set if 3 of the 7 organizations go dark. The wider public network on the same reading shows 406 known nodes, 216 active, 94 validating and 70 full validators across 14 distinct organizations, so the operator set beyond the quorum set is broader, but SCP quorum weight remains concentrated in the Tier-1 set. Concentration is structural to Federated Byzantine Agreement. Client diversity: stellar-core dominant.

SDF coordinates a validator vote on each protocol bump through stellar-core's ledgerVersion, and the recent record is dated and clean: Protocol 25 X-Ray activated on MainNet 2026-01-22, Protocol 26 Yardstick 2026-05-06, Protocol 27 Zipper 2026-07-08, a recent cadence of roughly two to three and a half months. Protocol 28 Adapter carries published operational dates (stellar-core v28.0.0 released 2026-08-13, TestNet vote 2026-08-27 1700 UTC, arming deadline 2026-09-09 1700 UTC, MainNet vote 2026-09-16 1700 UTC), and 38 of 94 validating nodes were already running Protocol-28-capable core software on 2026-08-20, a month ahead of the vote. The CAP process requires formal acceptance by a majority of validators before Final status.

Stellar Development Foundation is the named single foundation coordinating the protocol, with a published team page, a published roadmap, and a CAP/SEP process run on a public GitHub repository with a documented status taxonomy (Draft → Awaiting Decision → Final Comment Period → Accepted → Implemented → Final). The PQC effort has named leads with a published mandate: Nicolas Barry authored the Quantum Preparedness Plan (2026-06-09) and is listed as Consulted on CAP-0087, and Jay Geng is CAP-0087's owner and author and previously authored CAP-0059, CAP-0074 and CAP-0075, the cryptographic host-function CAPs now live on MainNet. No chartered PQC working group was identified in the public record, and the SDF team page renders no job titles, so no individual's role or title is asserted here beyond the CAP and blog authorship on the public record.

No cryptographic emergency precedent. The closest coordinated precedent for removing a live protocol behaviour is CAP-0026 'Disable Inflation Mechanism' (Final, Protocol 12, created 2019-07-10), which retired an economically significant mechanism through the ordinary validator-ratified CAP path. There is no precedent of coordinating a cryptographic primitive change under an active attacker. A 2017 consensus-disruption precedent is sometimes cited but is not corroborable from a primary source, so it is not carried.

None. No community honeypot, rate-limited spending rule, cryptographic tripwire embedded in SCP, or automated response is declared. The Quantum Preparedness Plan's only stated trigger for the Stage 3 Ed25519 cut-off ledger is qualitative: activation will be determined by quantum computing progress and ecosystem readiness. No numeric threshold, logical-qubit benchmark or calendar tripwire is published.