Post-Quantum Signature Verification Host Functions in Soroban

[jayz22]

The signature verification algorithms currently available in Soroban — ECDSA and EdDSA — rest on the (elliptic-curve) discrete logarithm problem, whose hardness assumption no longer holds in the post-quantum setting.

As a first step toward post-quantum readiness, we want to expose host functions for native PQ signature verification. This lets Soroban custom accounts (smart wallets) enforce PQ-secure auth on the user side without waiting for protocol-level key-type changes.

This thread tracks the discussion and effort.

Scope of candidates. NIST has standardized two PQ signature schemes: ML-DSA (FIPS 204, lattice) and SLH-DSA (FIPS 205, hash-based), with FN-DSA / Falcon (FIPS 206, lattice) selected for standardization but not yet final (see NIST PQC and NIST on Falcon/FN-DSA). Open Quantum Safe (liboqs) tracks available implementations.

Open questions for discussion:

• Scheme selection. Maturity, adoption, implementation readiness, and security margins of each candidate. Lattice vs hash-based.
• Abstraction level. Concrete instantiation (e.g. ML-DSA-65), family (ML-DSA), lower-level primitives (e.g. NTT, sampling) to enable broader schemes in contract code, or lattice operations directly?
• Libraries. What production-grade implementations exist (and audit status)?
• Cost profile. Signature size, public key size, verifier CPU, memory cost.
• Other properties. Signature aggregation; hybrid composition with classical schemes (e.g. Ed25519+ML-DSA).

[jayz22]

Cross-posting, there is another thread discussing support for Falcon (FN-DSA, one of the NIST standardized schemes mentioned above)
https://github.com/orgs/stellar/discussions/1830

[iftachh]

Thanks Jay. I would try to go as broad as possible, support all 3 signature scheme and expose also the low level primitive.
We should support the three of them since we do not know what the industry will choose. Also, since these are rather new schemes, some of them might be found to be insecure, or at least not as secure as we would like to them to be.
Also, since we have to implement the lower level primitives any how, it skills cost us rather little to expose them, isn't it?

Btw, what about signature batching? The ability to sign many different messages with a single short signature? Is it part of what we plan to support soon?

[Eshan276]

dont know if its relevant here, wanted to share- https://github.com/Eshan276/nebulav2

[gnosed]

Thanks @jayz22 for opening this, and +1 to @iftachh on supporting all three NIST schemes plus low-level primitives. We at Soundness Labs have been working on post-quantum cryptography for blockchains. As part of our SCF work we shipped a Soroban Smart Account that authorizes via Falcon (FN-DSA): SoundnessLabs/stellar-pq.

We analyzed the cost tradeoffs across all three NIST schemes and their support across wallets / custodians. We also describe what we and others, like the Coinbase Independent Advisory Board (IAB) on Quantum Computing and Blockchain, consider the best migration strategy, leveraging the properties of EdDSA that follow RFC 8032.

On-chain authenticator size

For a smart account, every authorization carries a public key + signature into the transaction. Those bytes get propagated, validated, and stored by every node, and that's what the fee model has to price. On Stellar today: 32 + 64 = 96 bytes for Ed25519. Comparing it with NIST PQ schemes:

Adding them together as a combined view:

Falcon-512 lands at ~16× Ed25519, ML-DSA-44 at ~39×, SLH-DSA-128f at ~178×. SLH-DSA's tiny 32-byte public key is its one structural advantage, and the signature column buries it. ML-DSA pays in both columns. Falcon-512 is the only one of the three that stays under 2 KB combined at NIST Cat 1.

The Coinbase IAB position paper frames signature size as "a first-order architectural constraint" in the post-quantum world. Naive replacement reduces blockchain throughput by 1–2 orders of magnitude. Stellar's transaction limits aren't where the bite hits first, but the Soroban resource budget and fee model were designed around 96-byte authenticators.

Verification cost

Signing happens off-chain in the wallet or HSM and doesn't concern the blockchain itself. For the host-function design we are concerned about verification as shown in the following diagram:

Falcon-512 verifies faster than ML-DSA-44 (0.7× vs 1.0×). Falcon's verification is plain integer arithmetic over short polynomials: no FFT-tree, no floating point, no rejection sampling. Of the three NIST schemes, it's the cheapest to verify.

ML-DSA-44 sits in Ed25519's ballpark — Cloudflare's PQ-signature on-ramp benchmarks normalize ML-DSA-44 to 1.0 vs Ed25519 at 1.3. The ML-DSA pain isn't on the verify path. It's on the wire and at signing time.

SLH-DSA verify is 40–110× ML-DSA-44 at Cat 1 (same Cloudflare data). The inner loop is just SHAKE, but those numbers decide which use cases make sense on-chain.

Sign vs verify asymmetry

The "Falcon has a side-channel concern" framing is true, however the risk lives in signing, not verification, which matters for a smart-account host function.

Falcon signing has two paths in the wild. The fast reference path (3× ML-DSA-44) uses double-precision floating-point for the FFT-tree-based discrete Gaussian sampler, and that's what leaks via FP side channels — see Fouque–Kirchner–Tibouchi–Wallet–Yu, Eurocrypt 2020, key recovery from Gram-Schmidt norm leakage. Signing securely on a CPU an adversary can observe means moving to emulated FP. That's the constant-time path at ~60× ML-DSA-44, about 20× slower than the reference per Cloudflare.

Grouped, the asymmetry is hard to miss:

And the picking-a-scheme map:

What this means for host-function design.

A verify_falcon_512 host function inherits none of the Falcon FP concerns. The SCA concerns the wallet / HSM layer.

Security on that matter is relayed to signers who have different options. Software wallets ship the constant-time emulated FP and accept the slowdown. Hardware wallets, HSMs, and secure enclaves run the FP path with side-channel isolation provided by the device. Both are deployable today.

SLH-DSA's signing cost shapes its use cases: 14,000× ML-DSA-44 for 128s, 720× for 128f. Use it for cold and batched signing — vault keys, governance, anything that doesn't need to be fast. Not recommended for daily transaction signing.

A comparison among the three schemes

ML-DSA is the candidate that is supported across HSMs and MPC implementations. NIST's chosen general-purpose PQ signature, full FIPS 204 spec, Apple CryptoKit support in iOS 26 / macOS 26, AWS and Google Cloud KMS support, IETF LAMPS encoding into X.509.

Falcon (FN-DSA) is the compact choice, though practical MPC schemes for it are still an open research area. Smallest signatures of the three, verification on the fast path. Right scheme for high-frequency on-chain auth and bandwidth-sensitive Soroban contracts. Algorand uses this pattern in its state proofs (the only mainnet Falcon deployment we know of).

SLH-DSA is the conservative choice since it doesn't rely on assuming that lattices are secure (see FIPS 205). Security reduces to standard hash preimage and second-preimage resistance. Best fit for high-value vaults, governance, key-rotation, root-of-trust signing. Bad fit for everyday authorization due to the high signing cost. The Coinbase IAB report also flags that SLH-DSA resists efficient MPC and threshold protocols, which limits its KMS / custodial story.

@iftachh's "some of these might be found insecure" point is the one we take most seriously. MLWE/MSIS has had a decade of public cryptanalysis and held up, but lattice cryptography is still seeing parameter tightening. SLH-DSA is the explicit fallback NIST kept in standardization for that reason. Supporting all three lets Soroban migrate from one to another without a host-side breaking change.

Abstraction level

We'd push for per-scheme verification host functions plus a small set of shared primitives — shake, sha512, and a constant-time poly_ntt are worth considering to reduce verification costs.

E.g. per scheme: verify_ml_dsa_44, verify_ml_dsa_65, verify_falcon_512, verify_slh_dsa_128s, verify_slh_dsa_128f, with stable wire formats per FIPS 204/205/206.

Note on jurisdictional requirements (for institutional use case)

Concrete divergence across NIST-standardized signature schemes:

• CNSA 2.0 (NSA/US): ML-DSA (high security, e.g., ML-DSA-87) as the mandatory baseline. Does not include SLH-DSA in the CNSA suite, but defines a constrained profile rather than the full set of acceptable PQ schemes.
• BSI (Germany): ML-DSA (Levels 3/5) and SLH-DSA. Emphasizes SLH-DSA (hash-based) for long-term and high-value signatures due to conservative security assumptions.
• ANSSI (France): ML-DSA, Falcon (FN-DSA) Levels 3/5, and SLH-DSA. Maintains a diversified portfolio including lattice and hash-based schemes.
• NCSC (UK): ML-DSA, SLH-DSA, and stateful hash-based schemes (LMS/XMSS) for specific use cases. Focus on flexibility and crypto-agility rather than a single mandated scheme.
• ASD (Australia): Aligns with NIST PQC (including ML-DSA) with a migration target around 2030. Emphasizes transition planning and interoperability over prescribing a single scheme.

A Stellar participant under BSI guidance may prefer or require SLH-DSA for long-term or high-value signatures, while one operating under CNSA 2.0 is expected to use ML-DSA (e.g., ML-DSA-87) within that profile. Falcon (FN-DSA) addresses compact signature use cases and is explicitly included in ANSSI guidance. No jurisdiction we are aware of currently mandates non-NIST PQC signature schemes for general-purpose use, although some national programs (e.g., Korea's KpqC selections) exist and may be adopted domestically.

A Stellar-specific migration angle: proof of seed

The IAB framework defines four desired properties for any PQ migration strategy:

• P1: The transition does not compromise our current security posture. Any attacker who can break the new scheme can already break the existing one. ("Mathematically guaranteed, not subjective.")
• P2: The new scheme provides post-quantum security (P2a: as-is; P2b: enables a fast switch when needed).
• P3: No significant cost added until a quantum threat is imminent.
• P4: Minimal blockchain changes until needed.

The paper analyzes four candidate strategies (naive plug-and-play, private keys as hash outputs, 2-of-2 hybrid signing, 1-of-2 hybrid signing) and concludes that only one fulfills all four properties: private keys as hash outputs. The summary table on page 34 lays it out cleanly. The report cites our work directly: "This therefore looks like an ideal solution, and is even being deployed today (see http://soundness.xyz)."

The technique fits Stellar natively. Ed25519 with RFC 8032 already derives the signing scalar deterministically from a seed via SHA-512 — exactly the key-generation structure the strategy requires. The seed is the preimage. When a quantum threat becomes realistic, Stellar can stop accepting Ed25519 signatures and start accepting proofs of seed: a PQ zero-knowledge proof that the holder of an address knows the seed x such that Q = (SHA-512-derived scalar of x) · G, without revealing x.

Against the four properties, this strategy is four-for-four: P1 (security never weaker than today's Ed25519), P2b (PQ security the moment the network flips the acceptance switch), P3 (zero on-chain cost until the switch), P4 (Ed25519 keys are already hash outputs under RFC 8032, so users with mnemonics need no key-generation change).

The verifier on the Soroban side is based on WHIR. We'll share numbers and a writeup once the prototype is benchmarked.

Aggregation (re: @iftachh)

Short answer: no native PQ signature scheme aggregates the way BLS does.

State of the art has two threads.

1. leanXMSS plus a hash-only PQ SNARK, the Lean Ethereum / Strawmap line, with Justin Drake and the Ethereum Foundation as the active research effort. Proving cost is the constraint.
2. LaBRADOR-based aggregation of Falcon signatures, where LaBRADOR is the underlying lattice SNARK from Beullens & Seiler, CRYPTO 2023. The aggregate is smaller, but the security argument leans on rewinding whose PQ implications aren't fully resolved.

Neither is production-ready for a Soroban smart account today. For "many different messages with one short signature" the safe path now is plain non-aggregated multi-sig with N independent verifications.

Where we'd be useful next

1. Public Soroban PQ benchmark harness. Run all three schemes (host function vs. pure WASM) inside a real contract and publish CPU / memory budget numbers per verify_* per security level. Until those are public, every cost-profile argument in this thread is informed but speculative. The harness extends naturally from our Falcon Smart Account work.
2. Reference hybrid Ed25519 + ML-DSA Smart Account contract. Parallel verification of both, transaction valid only if both pass — the "2-of-2 hybrid" strategy in the Coinbase IAB framework. NIST CSWP-2024 hybrid guidance recommends this pattern, and it's a clean migration on-ramp that doesn't need a protocol change. We can ship it as a follow-up to the Falcon contract.
3. PQ migration via proof of seed: design doc / SEP-CAP draft. Spec the host-function shape, the WHIR-verifier interface, and the policy for stopping Ed25519 acceptance once the switch is flipped. Natural write-up of the Strategy 1 prototype, with the Coinbase IAB report having already validated it as the only strategy that hits all four desired properties.

[MonsieurNicolas]

This is great! Thank you. Something to note is that wrt "on-wire" cost, in most situations we can probably avoid having to re-send the key with the signature: in both the context of a "G-account" and smart wallet, the runtime just needs to be able to find the key for verification: this could be an index or the hash of the key (the runtime just needs to be able to find a match)

[MonsieurNicolas]

Thought about this some more.

I think we should separate near-term host functions (in production) from longer-term research.
For the first CAP, I’d avoid exposing low-level primitives and instead expose high-level, parameter-specific verification functions with canonical encodings and precise metering (that look like verify_mldsa_65(public_key, message_or_digest, signature, domain_separator) -> bool). It looks to me that in that context and with the "on-wire cost" mostly mitigated as per my previous comment, ML-DSA-44/65 look like the best initial target as they're both an approved standard and supported in HSMs.

Falcon/FN-DSA is attractive for compactness but should probably wait until FIPS 206 and production-quality implementations stabilize: my main concern in the context of a host function is going to be around correctness issues with floating point operations that are architecture dependent (therefore creating potential determinism issues).

[jayz22]

@gnosed thank you for your detailed post, lots of gold nuggets there.

I definitely think each method has its own advantages, and given this is still an early field, we should keep our mind open and support multiple of them.

In terms of priority and immediate impact, I agree with @MonsieurNicolas the ML-DSA seems like the best option to tackle first. Here would be my order of attack:

1. ML-DSA. Decent signature size and verification cost. But the true differentiator is existing standards and hardware support. Which means they have the cleanest enterprise adoption path and immediate impact once enabled.
2. SLH-DSA. A good alternative to algebraic approaches. Better/more conservative security story. Even though highest costs and sizes across the board, but not totally prohibitive on-chain. Good choice for high value or governance-level use cases at a lower frequency.
3. Falcon. The most attractive in terms of numbers. But the FP issue we can't ignore, even if FP is only relevant for signing flow, the potential of platform/implementation divergence could have implication on verification (e.g. cross library edge cases), this needs to be better understood. Plus lack of hardware support and lack of standardization (FIPS-206 is yet to be finalized) means lack of adoption initially. We need to keep an eye on it as the scheme for the future.

I think each of these families should be a separate CAP (in the mentioned order). Each CAP should support multiple parameter sets under a shared implementation strategy, e.g ML-DSA-44 and ML-DSA-65 are the same standardized algorithm family with different parameters.

[jayz22]

cap-0087 - Host functions for ML-DSA has been added.

[Jagadeeshftw]

CAP-0087 lists cost calibration as TBD. I measured guest-side ML-DSA-44 and
ML-DSA-65 on testnet, in case the baseline is useful for that work.

Per ledger (ledger_max_instructions = 580,000,000):

Operation	% of ledger budget per call	per ledger	per second
ML-DSA-65 in contract	13.4%	14	2.8
ML-DSA-44 in contract	8.8%	22	4.4
ECDSA secp256r1 host fn	1.0%	204	40.8
Ed25519 host fn	0.5%	390	78.0

Derivation, so it can be checked: under CAP-0063 ledgerMaxInstructions bounds
the critical path rather than the raw sum — sequential(stage) is the max
across its clusters, summed across stages. With
ledger_max_dependent_tx_clusters = 2, one stage of balanced, non-conflicting
work admits 2 × floor(580,000,000 / per_tx). Custom-account calls do partition
(ro = {instance, code}, rw = {nonce}), so 14 is the favourable case;
strictly sequential it is 7. Measured close time 5.00 s.

Per transaction ML-DSA-65 is 77,519,116 instructions — 19.4% of
tx_max_instructions; net of the VM baseline that is 167× Ed25519 and 24×
secp256r1. The secp256r1 comparison may be the more useful one given CAP-0051
is the CAP's cited precedent.

Two things aimed directly at the cost types in the spec. The
decode/ExpandA share is 40% for ML-DSA-65 and 38% for ML-DSA-44, which
puts a number on the expanded-key caching the CAP mentions as a future
optimisation. And the linear message-length model holds — marginal cost settles
around 400 instructions/byte, with the constant term dominating so heavily
that 32 bytes to 8 KiB adds only 4.4%.

Method: wasm32v1-none, current soroban-sdk, deployed to testnet
(protocol 27), invoked through simulateTransaction, resources read from the
returned SorobanTransactionData — so the compiled wasm is what executes and
guest-side cost is included. Denominators read from
ConfigSettingContractComputeV0.

A custom account authorised solely by an ML-DSA-65 signature verified in
__check_auth — account
CDDE2DU2VR4W2XSHIE62VYAFJ3VNIBDIV3IMGZ3N4MPISCKPW2EIIA3S,
transaction
5f62349d0b8faeb61746fe457f461ad7fe4d03044c976163ac14f5b52215f4b9,
ledger 4,219,543. The envelope is still Ed25519-signed as protocol 27 requires;
what is post-quantum is the account's authorization.

These measurements support the CAP. Guest-side verification is comfortably
feasible per transaction, but 14 authorizations per ledger network-wide is not a
basis for broad wallet authentication — which I take to be the substance of
"exceeds reasonable network limits". Guest-side looks viable for the low-volume,
high-value tier, as a bridge to protocol 29 rather than an alternative.

@MonsieurNicolas's point upthread about not re-sending the key holds up: the
account stores the 1,952-byte verifying key on-ledger and only the signature
travels with the transaction, which keeps transaction size immaterial.

Full tables — including the message-length sweep and the decode/verify split —
are in
BENCHMARK.md; contracts, harness and deployed
addresses are in the same repo,
latticework-dev/soroban-ml-dsa.
This uses ml-dsa 0.1.1, which is unaudited, as is fips204; the crate is
differential-tested across ACVP and Wycheproof vectors against fips204, but
that is mitigation rather than assurance. Testnet only.

One footnote: Soundness Labs ceased operations on 18 June 2026, citing market
timing. Their Falcon-512 verifier is still live on mainnet at
CA5RY3BU…
— stateless, and they flagged the audit-pending status themselves — but anyone
building against it should know
stellar-pq went quiet on 12 June.
Worth preserving: pure-Rust no_std Falcon-512, all 100 NIST Round-3 KAT
vectors in CI, a full pre-audit pack, and Rocky's scheme comparison upthread is
still the best survey of the trade-offs here.

Is this useful, and is there anything else on CAP-0087 I could help measure?