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

Updated August 20, 2026 with expanded technical benchmarks and side-channel research.

Published by: QubitChain Research
URL: qubitchain.io/blog/ml-dsa-dilithium-vs-fn-dsa-falcon-nist-signature-blockchain
Category: Cryptographic Standards, Blockchain Security
Reading Time: Approximately 21 minutes
Last Updated: August 2026

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.

What That Actually Costs a Network: The Bandwidth Math

It's worth turning "meaningful for bandwidth" into an actual number, because the abstract comparison hides how differently these algorithms behave at scale.

Take a network processing 1,000 transactions per second, a reasonable mid-range target for a Layer 1 chain. Using ECDSA (71-byte signatures), the signature component of that throughput adds roughly 71 KB per second of pure signature data. Switch to ML-DSA-65 (3,293 bytes) and the same throughput adds about 3.3 MB per second, a 46x increase. Switch to FN-DSA-512 (~690 bytes) instead, and it's roughly 690 KB per second, a 10x increase over ECDSA but less than a quarter of ML-DSA's bandwidth cost at the same throughput.

Over a 24-hour period at that same 1,000 TPS, ML-DSA-65 signatures alone would add close to 285 GB of raw signature data to whatever needs to propagate and eventually be stored across the network. FN-DSA-512 would add about 60 GB. Neither number is disqualifying for modern infrastructure, but they explain precisely why block size, state growth, and node hardware requirements are the real engineering conversation once you move past the topline security claims. A network that picks ML-DSA as its primary signature scheme without redesigning its block structure, propagation logic, and storage assumptions around that 3,293-byte reality is building the same kind of retrofit problem that makes adding post-quantum signatures to Bitcoin or Ethereum an engineering project measured in years, not a parameter change.

This is the concrete version of the crypto-agility argument the rest of this piece keeps returning to: the right answer depends on what you're building, and the cost of getting the primary scheme wrong compounds with every block.

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.

The clearest demonstration of this risk came from a 2024 paper by Xiuhan Lin, Mehdi Tibouchi, Yang Yu, and Shiduo Zhang, later presented at EUROCRYPT 2025, titled "Do Not Disturb a Sleeping Falcon: Floating-Point Error Sensitivity of the Falcon Sampler and Its Consequences." The paper identifies a specific design property of Falcon's discrete Gaussian sampler that makes it unusually sensitive to small floating-point rounding discrepancies, the kind that can arise from differences between hardware and emulated floating-point arithmetic, or from repeated use of the same randomness. In the attack scenarios the authors demonstrate, an adversary who can collect enough side-channel traces from the signing process, on the order of 170,000 traces in their worked example, can recover a complete Falcon-512 private key in about thirty minutes.

Two nuances matter here, and getting them right is the difference between an accurate risk assessment and an alarmist one. First, the authors are explicit that their core finding has limited impact on standard, properly randomized Falcon signing as specified in the reference implementation; the more serious exposure is in derandomized Falcon variants used in specific applications like identity-based encryption, SNARK-friendly signatures, and signature aggregation schemes, where the same or predictable randomness gets reused across signatures. Second, this builds on an existing research line, not a discovery from nothing: power-analysis attacks against Falcon's floating-point sampler were already an active area of study, and the cryptographic community has been developing responses in parallel rather than reacting after the fact.

The most notable of those responses is Mitaka, proposed by Espitau et al. at EUROCRYPT 2022, a variant of Falcon designed to be simpler, easier to mask against side-channel attacks, and more parallelizable, at the cost of a roughly 8-bit reduction in security margin compared to standard Falcon. A follow-up construction called Antrag, presented at ASIACRYPT 2023, closed that security gap, combining Mitaka's implementation-friendliness with Falcon's original security level. Neither Mitaka nor Antrag is part of the NIST FIPS 206 draft as it currently stands, but they represent the direction the underlying research is moving, and they're worth watching if you're planning a Falcon deployment on a multi-year horizon.

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.

Inside the Aborts: Why ML-DSA's Signing Loop Isn't Free Either

ML-DSA's integer-only signing avoids Falcon's floating-point exposure, but it isn't a free lunch either, and understanding the cost clarifies what "constant-time safe" actually buys you.

Recall that ML-DSA signing uses Fiat-Shamir with aborts: the signer generates a candidate signature and checks whether its coefficients fall within a required size bound. If they don't, the attempt is discarded and the signer tries again with fresh randomness. This isn't a rare edge case. Benchmarking work on ARM Cortex-M0+ hardware published in 2026 measured the expected number of signing attempts per parameter set: an average of 4.25 iterations for ML-DSA-44, 5.1 for ML-DSA-65, and 3.85 for ML-DSA-87 before a valid signature is produced. In practice, that means signing a single transaction with ML-DSA-65 typically runs the core signing computation four to five times internally before returning a result.

That variability is why ML-DSA signing time isn't perfectly constant in wall-clock terms; what's constant-time is each individual attempt, which is what matters for preventing timing side-channels, since the number of attempts itself doesn't leak information about the private key the way Falcon's floating-point rounding can. It's a genuinely different risk category, not just a smaller version of the same risk.

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.

Real Hardware Numbers: What Constrained and Validator-Class Devices Actually See

Most of this comparison so far has been about algorithmic properties. It's worth grounding it in what actually happens on real hardware, because the gap between "theoretically fine" and "fits in a validator's memory budget" is where production deployments succeed or fail.

The pqm4 benchmarking framework, the de facto standard for testing NIST PQC candidates on ARM Cortex-M4 microcontrollers, found that Falcon's reference implementation for Falcon-1024 signing dynamically allocates over 200 KiB of memory during key generation, more than the 196 KiB of RAM available on the standard pqm4 test board. Getting Falcon to run on constrained hardware at all has required dedicated optimization work separate from the reference implementation, and even then, only the smaller Falcon-512 parameter set with tree-based key storage fits comfortably.

ML-DSA has its own memory footprint to account for, just a more predictable one. Recent benchmarking on the ARM Cortex-M0+ (used in devices like the Raspberry Pi Pico) measured peak stack usage during signing at 50.6 KB for ML-DSA-44, 77.6 KB for ML-DSA-65, and 119.6 KB for ML-DSA-87, scaling roughly linearly with security level because the signing algorithm allocates larger polynomial vectors as parameters increase.

On verification, the picture flips. Independent 2025 benchmarking work on ARM Cortex-M4 hardware by cryptographer Thomas Pornin found that while Falcon's key generation is dramatically more expensive than its verification step, and signing itself several times slower than verification, Falcon's actual signature verification is fast, competitive with or faster than comparable operations in other schemes, and uses relatively little RAM. This is consistent with Falcon's design intent: it was built to be expensive where it's run rarely (key generation, once per identity) and cheap where it's run constantly (verification, once per transaction observed by every node on the network).

For a blockchain specifically, that asymmetry matters differently depending on where in the system the operation happens. Validators sign infrequently relative to how often they verify, so Falcon's verification speed is attractive for validator-heavy networks with many nodes checking every block. But wallets and light clients that need to generate fresh keys or sign transactions on constrained hardware, hardware wallets, mobile devices, IoT-adjacent signing devices, feel Falcon's key generation and signing cost much more directly, which is a large part of why ML-DSA's more even cost profile has made it the more common default choice for general-purpose transaction signing rather than specialized attestation roles.

Who's Actually Deploying What, as of 2026

The theoretical comparison matters less than what's actually shipping. Beyond QubitChain.io and QANplatform on the ML-DSA side, and Algorand's Falcon-1024 state proofs on the FN-DSA side, two additional data points are worth tracking.

Bitcoin's BIP-360 proposal, merged into the official BIP repository in February 2026, names ML-DSA as its primary candidate for post-quantum transaction signing inside its new Pay-to-Merkle-Root output type, with a working testnet already running five live ML-DSA (Dilithium) signature opcodes. We covered the full mechanics of that proposal, including exactly what it does and doesn't fix, in a separate piece: BIP-360, Hardware Wallets, and Bitcoin's Real Post-Quantum Migration Path.

The XRP Ledger has published its own post-quantum readiness roadmap with milestones through 2026 and a target of full transition no later than 2028, including a contingency plan the team refers to internally as "Quantum-Day" for accelerating migration if the threat timeline moves up. It's a useful signal that this isn't a QubitChain-specific or Bitcoin-specific conversation; every serious chain is now being asked to show its work.

Common Misconceptions Worth Correcting

A few claims about this comparison circulate often enough to be worth addressing directly.

"Falcon is just better because the signatures are smaller." Signature size is one variable among several. Falcon's smaller output comes with a harder implementation profile, a heavier key generation cost, and a standard that isn't finalized yet. Smaller isn't the same as better; it's a trade-off that's the right call for some use cases and the wrong one for others.

"ML-DSA is slow." ML-DSA's signing does run its core computation multiple times on average due to the aborts mechanism, but each individual operation is fast and constant-time, and verification, the operation that happens far more often on any blockchain, is efficient. The rejection sampling overhead is a known, bounded, and well-understood cost, not an open-ended performance problem.

"You have to pick one algorithm for your whole network." This is the misconception the crypto-agility argument throughout this piece exists to correct. The strongest architectures use ML-DSA as the general-purpose default and reserve FN-DSA, once finalized, for the specific bandwidth-constrained contexts where its size advantage actually pays for its implementation complexity, with SLH-DSA available as a hash-based fallback that depends on neither lattice problem.

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

For the full breakdown of that third column, including WOTS+, FORS, hypertree construction, real signature sizes, and where SLH-DSA actually gets deployed today, see our dedicated deep dive: SLH-DSA (SPHINCS+) Explained.

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.

Q: What is "Do Not Disturb a Sleeping Falcon" and how serious is it for production use?

A: It's a 2024 research paper by Xiuhan Lin, Mehdi Tibouchi, Yang Yu, and Shiduo Zhang, presented at EUROCRYPT 2025, identifying a specific sensitivity in Falcon's Gaussian sampler to floating-point rounding errors. In their demonstrated attack, an adversary with enough side-channel traces, around 170,000 in their example, can recover a Falcon-512 private key in roughly thirty minutes. The authors are clear that the most severe exposure applies to derandomized Falcon variants used in specialized applications, not standard randomized signing as specified in the reference implementation, but it's a real and actively studied risk that any production Falcon deployment needs to account for through careful, side-channel-resistant implementation.

Q: Is there a fix for Falcon's floating-point risk?

A: Two research constructions address it directly. Mitaka, presented at EUROCRYPT 2022, is a variant of Falcon designed to be easier to implement in a masked, side-channel-resistant way, at a small cost to security margin. Antrag, presented at ASIACRYPT 2023, closes that security gap while keeping Mitaka's implementation advantages. Neither is currently part of the NIST FIPS 206 draft, but both represent active directions in the research addressing this exact problem.

Q: How much bandwidth does ML-DSA actually add to a blockchain compared to ECDSA?

A: At 1,000 transactions per second, ECDSA's 71-byte signatures add about 71 KB per second of signature data. ML-DSA-65's 3,293-byte signatures add about 3.3 MB per second at the same throughput, roughly a 46x increase. Over 24 hours at that rate, that's the difference between a few gigabytes and close to 285 GB of raw signature data. This is why signature scheme choice has to be a block-structure and throughput design decision from the start, not a parameter swapped in later.

Q: Can Falcon actually run on constrained hardware like hardware wallets or IoT devices?

A: It's workable but genuinely harder than ML-DSA. Falcon's reference implementation for Falcon-1024 key generation allocates over 200 KiB of memory, more than fits on standard constrained-device testing boards, and required dedicated optimization work to run at all on ARM Cortex-M4-class hardware. Falcon-512 with optimized implementations is more tractable. Falcon's verification step, by contrast, is fast and lightweight on the same hardware, which is why it tends to be a stronger fit for roles where verification happens far more often than signing, such as light-client attestations, rather than for general-purpose wallet signing on constrained devices.

Q: Is Falcon used by any blockchain besides Algorand?

A: As of 2026, Algorand's use of Falcon-1024 for State Proofs remains the clearest production deployment. Bitcoin's BIP-360 proposal, still in the testnet stage, currently has five live signature opcodes built around ML-DSA (Dilithium) rather than Falcon, though the proposal's broader design leaves room for FN-DSA once FIPS 206 finalizes, particularly for bandwidth-sensitive contexts similar to Algorand's use case.

Q: When exactly will FIPS 206 be finalized?

A: NIST submitted the Initial Public Draft in late 2025. Based on the timeline NIST followed for FIPS 203, 204, and 205, the public comment period typically runs about a year, putting final publication in the late 2026 to early 2027 window. This is an estimate based on precedent, not a confirmed date; organizations planning around FN-DSA should track the NIST PQC forum directly for status updates rather than treating any specific date as fixed.

Reference Links