ML-DSA-65 in Production: Looking for Others Deploying FIPS 204

[Juan Todolí]

Introducing ourselves to the community. We're running ML-DSA-65 (FIPS 204) natively in a production blockchain environment — not as a hybrid or migration layer, but as the primary signature scheme.

Our main takeaway after months in production: the algorithm itself is not the bottleneck. The real challenges are infrastructure-level — key management at scale, signature verification throughput, and peer-to-peer propagation with larger message sizes.

Curious to hear from others who are deploying FIPS 204 in production. Most of the conversation around PQC is still theoretical or focused on migration planning. 

We'd like to connect with teams who are past the planning phase and into real-world deployment.

What PQC deployment challenges are you encountering?

[Jason Wang]

Hi Juan,

Thanks for sharing production numbers — this is exactly the kind of ground-truth data the community needs more of.

Your observation resonates: the algorithm itself is sound, but the infrastructure cost of 2.4 KB signatures at scale is structural, not an implementation artifact. Larger message sizes affect peer propagation, mempool bandwidth, and persistent ledger growth simultaneously, and there is no parameter-tuning path out of it.

One direction I have been exploring addresses this at the authorization model layer rather than the signature layer. The core observation is that consensus does not inherently require verifying a specific signature object — it requires assurance that a transaction was authorized by the correct entity. ZK-ACE replaces transaction-carried ML-DSA signature objects with identity-bound zero-knowledge statements, so no signature material appears on-chain or inside the ZK circuit. The circuit itself requires only ZK-friendly hash evaluations (2,155 R1CS constraints in the Groth16 backend; 341 AIR rows in Circle STARK), roughly 500–2,300× smaller than in-circuit ML-DSA verification. I posted a longer description of the approach earlier in this forum: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/m-Mk6MVXTLM/m/5ieDz2zrBAAJ

This is not a compression of ML-DSA — it is a different authorization model. In our own devnet testing, we found that end-to-end TPS was not signature-verification-bound once verification is parallelized and the gossip path strips the full signature object before relay — which is part of why the on-chain footprint question felt more pressing to us than raw verification speed. Whether that matches your production bottleneck is exactly what I am curious about: are your infrastructure constraints primarily on the verification side, or on the propagation and storage side?

Best regards,
Jason