FIPS 204 (ML-DSA / Dilithium) vs FIPS 206 (FN-DSA / Falcon): Which NIST Signature Standard Is Right for Blockchain?

NIST finalized three post-quantum cryptographic standards in August 2024. Two of them, ML-KEM (FIPS 203) for key encapsulation and SLH-DSA (FIPS 205) for hash-based signatures, generate relatively little confusion. The third, ML-DSA (FIPS 204, based on CRYSTALS-Dilithium), generates a very specific search query that shows up constantly in technical discussions: "dilithium signature nist." And a fourth standard, FN-DSA (FIPS 206, based on Falcon), is in public draft with a final publication expected late 2026 or early 2027, prompting its own cluster of "FIPS 206 Falcon status" searches.

This post exists because the comparison question, which NIST lattice-based signature scheme should a blockchain use and why, does not have a clean single-source answer yet. The short version: ML-DSA for transaction signing, FN-DSA for bandwidth-constrained attestation contexts, and not yet for production unless your signing hardware is controlled and audited. Here is the full reasoning.

What Each Algorithm Actually Is

Both ML-DSA and FN-DSA are lattice-based digital signature schemes selected by NIST from the same post-quantum standardization process that ran from 2016 to 2024. Both are resistant to Shor's algorithm and Grover's algorithm on a quantum computer. Both are meaningfully faster and generate meaningfully smaller outputs than RSA or ECDSA for equivalent security levels, at least in comparison to the classical alternatives. That is where their similarities largely end.

ML-DSA is the standardized name for CRYSTALS-Dilithium. CRYSTALS stands for Cryptographic Suite for Algebraic Lattices. Dilithium uses module lattices, meaning the hard mathematical problem is the Module Learning With Errors (MLWE) problem over polynomial rings. Its signing algorithm uses only integer arithmetic and Fiat-Shamir with aborts, a technique that makes the signing process straightforward to implement securely on any hardware without side-channel risk from timing variation.

FN-DSA is the standardized name for Falcon, which stands for Fast-Fourier Lattice-Based Compact Signatures over NTRU. Falcon uses NTRU lattices rather than module lattices, and its signing algorithm relies on Gaussian sampling using fast Fourier transforms. This produces extremely compact signatures, roughly three to four times smaller than ML-DSA at equivalent security levels, but the Gaussian sampling requires floating-point arithmetic to achieve its target performance on commodity hardware.

The Standardization Status Gap

This distinction matters practically right now. ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) are finalized and effective. They are not experimental; they are approved and ready for federal and commercial adoption.

FN-DSA (FIPS 206) is not yet finalized. NIST submitted the Initial Public Draft in late 2025. Based on past timelines, the public review will last about a year, with the final standard expected in late 2026 or early 2027. The IETF draft for FN-DSA JOSE and COSE serialization, as of March 2026, cites FIPS 206 as expected to be published in late 2026 or early 2027.

DigiCert, one of the largest certificate authorities in the world, has stated it will not implement FN-DSA in production products until the standard is finalized, specifically to avoid the naming and OID confusion that affected ML-DSA and SLH-DSA between their initial public drafts and their final versions. For any production system, ML-DSA is the buildable standard today. FN-DSA is the one you test, prepare for, and plan crypto-agility around.

Key and Signature Sizes: The Central Trade-Off

The primary reason FN-DSA exists as a separate standard from ML-DSA, rather than just picking one lattice-based scheme for all use cases, is size. Falcon produces dramatically smaller signatures than Dilithium.

ML-DSA (FIPS 204) sizes:

FN-DSA (FIPS 206 draft) sizes:

For a blockchain signature in a transaction, the difference between a 690-byte Falcon signature and a 2,420-byte Dilithium signature is meaningful for network bandwidth and on-chain storage cost. For a network processing thousands of transactions per second, that 3.5x size difference in signatures compounds into significantly higher bandwidth requirements. This is why Algorand chose Falcon-1024 for its State Proofs, the periodic attestations that compress historical block data for light clients and cross-chain bridges. State proofs get broadcast to many participants and need to be as compact as possible.

For individual transaction signatures on a network where signature size is one cost among many, Dilithium's larger size is entirely manageable.

The Floating-Point Signing Risk in Falcon

The performance case for Falcon is compelling on paper. Its key generation and signature verification are significantly faster than Dilithium's, and its signatures are far smaller. But the signing operation introduces an implementation challenge that does not appear in Dilithium at all.

Falcon's signing complexity means any use of Falcon with an external floating-point implementation involves risk. A paper titled "Do Not Disturb a Sleeping Falcon" raised concerns about timing side-channel vulnerabilities arising from floating-point arithmetic in the signing algorithm. Floating-point operations on general-purpose CPUs do not execute in constant time. The execution time varies based on the specific values being processed. In a signature scheme, that timing variation can leak information about the private key to an observer who can measure signing time.

This is not a theoretical problem. Timing side-channel attacks have broken real-world cryptographic implementations before, including earlier versions of ECDSA. Within the NIST standardization community, there has been active discussion about whether FN-DSA should require a fixed-point implementation rather than floating-point, to reduce this optionality and the implementation errors that follow from it.

ML-DSA signing uses only integer arithmetic and is straightforward to implement in constant time on commodity hardware. There is no equivalent floating-point signing concern. For a blockchain network where validators run diverse hardware configurations across many geographies, the constant-time signing guarantee from ML-DSA is a material practical advantage.

CNSA 2.0 and the Parameter Set You Actually Need

The US NSA's CNSA 2.0 framework, the mandatory algorithm suite for US National Security Systems, specifies ML-DSA-87, which is Dilithium 5 at Category 5 security. It does not include FN-DSA in its current suite, which is consistent with the fact that FIPS 206 is not yet finalized.

This matters for two reasons. First, if a blockchain network or application needs to demonstrate compliance with CNSA 2.0, it uses ML-DSA-87 specifically, not the lower-security ML-DSA-44 or ML-DSA-65, and not FN-DSA. Second, institutions building on quantum-resistant infrastructure for regulated environments will increasingly follow CNSA 2.0 as the benchmark, which means the network they choose needs to implement the right parameter set.

The UK NCSC's recommended parameter set for ML-DSA is ML-DSA-65 (Category 3), which is slightly less conservative than CNSA 2.0 but aligned with the same algorithm. Both reference the FIPS 204 final standard. SLH-DSA (FIPS 205) is also available as a hash-based alternative whose security relies on well-understood hash functions, providing very strong long-term assurance for data that needs to be verifiably secure for decades, such as government archives or legal documents. For blockchain transaction signing it is generally not chosen as the primary scheme due to its very large signature sizes, but it is the conservative fallback in a crypto-agile architecture.

Original Framework: NIST PQC Signature Comparison Matrix for Blockchain Use Cases

Which One Is Right for Blockchain Right Now?

For transaction signing, the unambiguous current answer is ML-DSA, specifically ML-DSA-87 if you need CNSA 2.0 alignment, or ML-DSA-65 for general post-quantum security at a slightly smaller size. It is finalized, implementable in constant time, CNSA 2.0 specified, and already deployed in production by QubitChain.io and QANplatform among others.

For bandwidth-constrained use cases where you are broadcasting a large number of attestations to many nodes, Falcon's size advantage is real and architecturally significant. Algorand's deployment of Falcon-1024 for State Proofs is the clearest real-world validation of this specific use case. But the operative constraint is that FIPS 206 is not final, and responsible production deployments should wait for the finalized standard before committing to FN-DSA.

The correct architecture for a blockchain being built today is to implement ML-DSA as the primary signature scheme, design the account and signature layers with crypto-agility so that FN-DSA can be integrated for specific use cases when FIPS 206 finalizes, and include SLH-DSA as a long-term archival fallback that does not depend on the security of any lattice problem. That layered, crypto-agile approach is exactly the structure that allows a network to absorb the next iteration of NIST standards without requiring users to migrate or a hard fork to land.

QubitChain.io uses ML-DSA-87 for all transaction signing from the genesis block, with FN-DSA support planned for state attestation use cases once FIPS 206 is finalized.

Frequently Asked Questions

Q: What is the difference between ML-DSA and FN-DSA?

A: ML-DSA (Module-Lattice-Based Digital Signature Algorithm, standardized as FIPS 204) and FN-DSA (Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm, being standardized as FIPS 206) are both lattice-based post-quantum digital signature schemes selected by NIST for standardization. ML-DSA is based on CRYSTALS-Dilithium and uses module lattices and integer arithmetic for signing. FN-DSA is based on Falcon and uses NTRU lattices with fast Fourier transforms, producing significantly smaller signatures at the cost of a more complex, floating-point-dependent signing process.

Q: Is ML-DSA finalized? Is FN-DSA finalized?

A: ML-DSA was finalized and published as FIPS 204 in August 2024. It is a fully approved NIST standard ready for production implementation. FN-DSA is being standardized as FIPS 206. NIST submitted the Initial Public Draft (IPD) in late 2025. Based on prior NIST timelines, the final standard is expected in late 2026 or early 2027. FN-DSA should be treated as an emerging standard: implementation can begin now for testing and preparation, but production systems should generally not deploy it until FIPS 206 is finalized.

Q: Which is better for blockchain: ML-DSA (Dilithium) or FN-DSA (Falcon)?

A: For general blockchain transaction signing, ML-DSA is the stronger current choice because it is finalized, uses only integer arithmetic (avoiding Falcon's floating-point timing attack risk), is specified by CNSA 2.0 for National Security Systems, and its larger signature sizes are manageable in most blockchain contexts. FN-DSA's compact signatures (roughly 690 bytes for Falcon-512 vs 2,420 bytes for Dilithium-2) make it better for bandwidth-constrained applications like state proofs, light-client attestations, or signatures that must be broadcast frequently, which is why Algorand uses Falcon-1024 for state proofs specifically rather than for everyday transactions.

Q: Why does Falcon use floating-point arithmetic and why does it matter?

A: Falcon's signing algorithm requires Gaussian sampling over NTRU lattices, and the most efficient implementation of this sampling uses floating-point arithmetic (IEEE 754 double precision). The problem is that floating-point operations on commodity hardware do not execute in constant time: the computation time varies based on the values being processed. This timing variation can leak information about the private key in a side-channel attack. A paper titled 'Do Not Disturb a Sleeping Falcon' demonstrated practical side-channel vulnerabilities in floating-point Falcon implementations on general hardware. This is why DigiCert, as of mid-2026, has stated it will not implement FN-DSA in production products until the final standard is published and the implementation guidance around fixed-point alternatives is clarified.

Q: What security level is ML-DSA-65 or Dilithium 3?

A: ML-DSA-44 (Dilithium 2) targets NIST security Category 2, approximately equivalent to 128-bit classical security. ML-DSA-65 (Dilithium 3) targets Category 3, approximately equivalent to 192-bit classical security. ML-DSA-87 (Dilithium 5) targets Category 5, approximately equivalent to 256-bit classical security. The NSA's CNSA 2.0 framework, which governs US National Security Systems, specifies ML-DSA-87 as the required parameter set.

Q: What does CRYSTALS stand for in CRYSTALS-Dilithium?

A: CRYSTALS stands for Cryptographic Suite for Algebraic Lattices. CRYSTALS-Dilithium is the original academic name for the algorithm now standardized as ML-DSA under FIPS 204. CRYSTALS-Kyber, the related key encapsulation mechanism from the same research group, is standardized as ML-KEM under FIPS 203.

Reference Links