Skip to main content

2026-09-17 Protocol Discussion

· 4 min read
Kaan Kacar
Kaan Kacar
Developer Advocate

After the Stellar Private Payments AMA, Jay Geng from the core team presented CAP-87. This is the CAP that audio problems pushed out of the previous week's discussion.

Why Post-Quantum Signatures​

The signature schemes that blockchains use today rely on the hardness of factoring and the discrete log problem, including its elliptic curve version. Shor's algorithm solves these problems in polynomial time on a large enough quantum computer. Nobody knows when that day comes, but Stellar wants to be ready.

A few months ago SDF published a three-stage quantum readiness plan for Stellar. CAP-87 is the first stage: add post-quantum signature verification to Soroban as host functions, so smart wallets can adopt a post-quantum scheme on their own. Network-level signatures are not part of this CAP.

Why ML-DSA​

NIST has three post-quantum signature candidates:

  • ML-DSA (FIPS 204), lattice-based.
  • SLH-DSA (SPHINCS+), hash-based. Signatures and keys are roughly an order of magnitude larger, and it is much more expensive to compute.
  • Falcon, also lattice-based and more compact, but its standard is not final yet.

ML-DSA is the most mature choice. Large cloud providers support it in their KMS products, Cloudflare supports it, and OpenSSL and Apple's CryptoKit list it. Its signatures are a few kilobytes, which fits a blockchain much better than hash-based schemes. Jay noted that the other two could still come later, because the blockchain world is split on all three.

What CAP-87 Adds​

Three host functions, one per ML-DSA parameter set: verify_sig_ml_dsa_44, verify_sig_ml_dsa_65 and verify_sig_ml_dsa_87. They share the same interface: public key, message, signature and an optional context string for domain separation. The context must be shorter than 256 bytes, as the standard requires.

  • The numbers 44, 65 and 87 refer to the size of the internal matrix. For ML-DSA-44 it is a 4x4 matrix of polynomials.
  • Key and signature sizes are exact. For ML-DSA-44, the verifying key is 1,312 bytes and the signature is 2,420 bytes. Any other size makes the function fail at once.
  • Each function decodes the key, decodes the signature, then verifies.

Costs​

The CAP adds nine new cost types, three per parameter set:

  • Decode verifying key: constant cost. This step does more than parse bytes. The public key holds a seed, and the host expands it into the full matrix with SHAKE.
  • Decode signature: constant cost.
  • Verify: linear in message and context length, because the message is hashed together with the context and the public key. Everything else is constant.

Jay shared early calibration numbers for ML-DSA-44: about 38k CPU instructions to decode the signature, about 850k to decode the verifying key, and about 686k to verify. About half of the work is in decoding.

Questions​

  • What makes it quantum safe: Lattice signatures rely on different hard problems, Short Integer Solution and Learning With Errors. Both come down to finding short vectors in a lattice, and there is no known efficient attack on them, even with a quantum computer.
  • Which library: AWS has a formally verified implementation, but it is low-level C. The team prefers a pure Rust dependency. The two mature Rust options are RustCrypto and libcrux. RustCrypto is the likely choice: its code is simpler and cleaner, it is widely used, and its decode and verify steps are well separated. The interface does not depend on the library, so it can change later.
  • Passkey smart accounts: ML-DSA is a new option, not a replacement. Passkeys today use secp256r1, and post-quantum passkeys need support from the platform and wallet side, for example in the WebAuthn layer. Jay warned against adopting it too early: if you give up hardware signing just to get a post-quantum property, that is a step backward. More ecosystem work is needed here.

Please add your comments to the CAP-87 discussion thread.