An ML-DSA-65 signature authorising a real transaction on Stellar testnet.
Transaction
5f62349d0b8faeb61746fe457f461ad7fe4d03044c976163ac14f5b52215f4b9
__check_authValues recorded from Horizon. Check it yourself on stellar.expert →
$ git clone https://github.com/latticework-dev/soroban-ml-dsa $ cd soroban-ml-dsa && ./demo.sh
No configuration, no funded account, no cost. Builds the contracts, creates its own testnet account, deploys, signs a real transaction with a post-quantum key, and prints the hash.
A Stellar smart-contract account whose authorisation is verified with an ML-DSA-65 (FIPS 204) signature, checked on-chain inside __check_auth. It works on testnet today with no protocol change — it uses Soroban's existing account abstraction.
The contracts, the signing library, and the measurement harness are in one repository, and the figures below reproduce from a clean clone.
Every Stellar account today is protected by Ed25519, which a sufficiently powerful quantum computer would break.
No mandate forces private firms to act. US financial-sector guidance is advisory, and no private-sector post-quantum requirement exists. What does exist is a set of dated official roadmaps pointing at the same window.
The Stellar Development Foundation published its Quantum Preparedness Plan in June 2026, and said plainly that this is not work SDF can do alone.
Making it work is half the question. The other half is what it costs, and nobody had published that. Measured on-network against deployed contracts, testnet protocol 27. “Sequential” is the same figure without Soroban's parallel execution.
| Operation | Per ledger | Sequential | Per transaction |
|---|---|---|---|
| ML-DSA-65 in contract | 14 | 7 | 19.4% |
| ML-DSA-44 in contract | 22 | 11 | 12.8% |
| Ed25519 host function | 390 | 195 | 0.7% |
Roughly 28× fewer per ledger than an Ed25519-verifying contract call. That suits low-volume, high-value accounts: treasury, custody, institutional holdings. It does not suit consumer wallet traffic.
CAP-0087, which proposes native host functions for this operation, lists cost calibration as still to be determined. These measurements support the CAP. They were posted to its discussion thread on 19 August 2026.
This is a new kind of account, not an upgrade to an existing one.
Stellar has two kinds: classic accounts, whose addresses start with G, and smart-contract accounts, starting C. This is the second kind. Existing classic G… accounts cannot be made quantum-safe on protocol 27 — there is no way to attach a post-quantum key to one until the protocol upgrade planned for 2027. This serves new high-value accounts today and lays groundwork for upgrading existing ones later. Said plainly, because "quantum-safe Stellar accounts" naturally reads as covering the account you already have. It does not.
Testnet only. Not for real funds.
The ML-DSA dependency is unaudited. ml-dsa 0.1.1 states it has never been independently audited, and so does the alternative, fips204. No audited pure-Rust ML-DSA implementation exists — the general state of the art, not a shortcut taken here, and CAP-0087's own Security Concerns section describes the same difficulty.
It is tested against NIST ACVP and Wycheproof vectors, and differentially against a second independent implementation, producing byte-identical signatures. That lowers the risk. It does not remove it.
The transaction envelope is still Ed25519-signed. Protocol 27 offers no alternative. What is post-quantum is the account's authorisation — QPP Stage 1.
Migration: getting existing accounts onto post-quantum protection without changing addresses or moving funds.
One part of it cannot wait. An account can publish a signed, on-chain record today stating that a new post-quantum key succeeds its current one. Its value comes entirely from when it was recorded — the ledger proves it existed before anyone could have forged it. Once quantum computers are real, that record can no longer be created honestly, because an attacker could produce an identical-looking one.
Protocol support can arrive later. The evidence has to be laid down first.