The Signature Size Problem in Quantum-Resistant Blockchains
Every post-quantum digital signature scheme that survives real-world cryptanalysis pays a penalty in size. ECDSA, the algorithm protecting Bitcoin, Ethereum, and most major blockchains, produces signatures of roughly 64 bytes. The NIST-standardised post-quantum alternative CRYSTALS-Dilithium produces signatures of approximately 2,420 bytes at its standard security level. That is a 37-fold increase in per-transaction data, compounding across block capacity, storage, and bandwidth for every node on the network.
For a chain targeting 200,000 transactions per second, this is not a theoretical concern. It is a hard arithmetic problem: naive post-quantum migration collapses throughput and makes storage costs catastrophic before the network reaches meaningful scale.
FALCON solves a large part of that problem. At its 128-bit security level, FALCON-512 produces signatures of approximately 660 bytes. At its 256-bit security level, FALCON-1024 produces signatures of approximately 1,280 bytes. Both are dramatically more compact than Dilithium at equivalent security, and both are now standardised by NIST under the formal name FN-DSA (FIPS 206). Understanding why FALCON achieves that compactness, and what the implementation tradeoffs are, is essential reading for anyone building or evaluating quantum-resistant blockchain infrastructure.
NTRU Lattices: The Mathematical Foundation
FALCON is a lattice-based signature scheme, which means its security rests on the presumed hardness of certain geometric problems involving high-dimensional lattices. Specifically, FALCON is built on the NTRU lattice, a structured subset of the broader lattice cryptography landscape that offers both strong security assumptions and a highly efficient algebraic representation.
To understand what makes NTRU lattices special, it helps to contrast them with the module lattices underpinning CRYSTALS-Dilithium. Dilithium operates over module lattices: essentially grids of polynomial rings arranged in matrix form. The security of Dilithium relies on the Module Learning With Errors (MLWE) problem and the Module Short Integer Solution (MSIS) problem. These are conservative, well-studied problems with strong reductions to worst-case lattice hardness.
NTRU lattices are a specialised construction with additional algebraic structure. They operate in polynomial rings of the form Z[x]/(x^n + 1), where n is a power of two (512 or 1024 for the two FALCON parameter sets). This ring structure enables an extremely efficient key generation algorithm, but more importantly it enables the compact representation of the trapdoor used for signing.
In any lattice-based signature scheme, signing requires a trapdoor: a secret piece of structure that allows the signer to produce a short vector in the lattice that a verifier can check against the public key. In FALCON, that trapdoor is a Gram-Schmidt basis of the NTRU lattice. The key insight is that the NTRU structure allows the Gram-Schmidt basis to be computed and stored compactly, and it allows the signing algorithm to sample short lattice vectors with high efficiency. The result is that FALCON signatures are dominated by the short vector itself, which, given the tight algebraic structure of the NTRU ring, is genuinely small.
The security of FALCON rests on two related problems: the NTRU problem (recovering the secret key from the public key) and the Short Integer Solution problem over NTRU lattices. Neither has an efficient quantum algorithm. As the NIST post-quantum standardisation process established after eight years of public cryptanalysis, these assumptions are robust against both classical and quantum adversaries at current and projected hardware scales.
Signature Size Comparison: FALCON vs Dilithium
The size difference between FALCON and Dilithium is substantial, and it matters at every layer of blockchain infrastructure.
- CRYSTALS-Dilithium (ML-DSA-65): Signature 2,420 bytes, public key 1,952 bytes
- FALCON-512 (FN-DSA-512): Signature 660 bytes, public key 897 bytes
- FALCON-1024 (FN-DSA-1024): Signature 1,280 bytes, public key 1,793 bytes
- ECDSA (secp256k1, for reference): Signature 64 bytes, public key 33 bytes
At 128-bit security, FALCON-512's 660-byte signature is less than one-quarter the size of Dilithium's 2,420 bytes. For a blockchain processing millions of transactions per day, that difference compounds into terabytes of storage and bandwidth saved annually. On a 200,000 TPS network, the gap between FALCON and Dilithium amounts to roughly 356 gigabytes per second in raw signature data, a figure that makes the choice architecturally significant rather than merely aesthetic.
Why is Dilithium so much larger? The module lattice structure that makes Dilithium simple and conservative to implement requires larger polynomial coefficients and more of them. Dilithium's security proof is tight and well-understood, but it pays for that conservatism in bytes. FALCON's NTRU structure is tighter algebraically, and the Gaussian sampling process produces vectors that are genuinely shorter relative to the lattice dimension. Fewer bits are needed to represent them.
The tradeoff is implementation complexity. And that is where FALCON's primary engineering challenge lives.
The Floating-Point Sampling Problem
FALCON's signing algorithm requires sampling from a discrete Gaussian distribution over the NTRU lattice. Unlike simpler rejection sampling approaches, FALCON's signing procedure uses a Gram-Schmidt technique called "fast Fourier sampling over NTRU lattices," published by Ducas and Prest in 2016. This algorithm operates in the frequency domain using Fast Fourier Transforms over the ring Z[x]/(x^n + 1).
The core of the signing operation requires floating-point arithmetic, specifically 53-bit double-precision floating-point operations on the Gram-Schmidt norms and the ring elements during sampling. This creates two practical challenges that any serious FALCON implementation must address.
The first challenge is side-channel vulnerability. Floating-point operations on many hardware platforms are not constant-time. Execution time can vary depending on the values being processed, and an adversary who can measure those timing variations can potentially learn information about the secret Gram-Schmidt basis used during signing. Timing attacks are a well-documented threat in production cryptographic implementations, and floating-point arithmetic makes them harder to eliminate than the integer arithmetic that Dilithium relies on.
The second challenge is correctness under precision constraints. The Gaussian sampling algorithm requires sufficient floating-point precision to avoid producing signatures that are either too long (failing the signature's norm bound and being rejected) or biased in a way that leaks information about the private key. The FALCON specification precisely defines the required precision and provides test vectors, but implementing this correctly on platforms with non-standard floating-point behaviour, including some embedded processors and hardware security modules, requires careful engineering.
These are not theoretical obstacles. Several early FALCON implementations were found to have timing-channel vulnerabilities in their floating-point sampling code. The FALCON reference implementation and the subsequently standardised FN-DSA specification address these issues with carefully designed countermeasures, including fixed-point approximations for the most sensitive operations. But the implementation burden is meaningfully higher than for Dilithium, which is built entirely on integer arithmetic and is considerably easier to audit for constant-time correctness.
This is one reason why production deployments of FALCON tend to lag behind Dilithium despite FALCON's bandwidth advantage. It is also a reason why the blockchain quantum migration problem is not simply a matter of swapping one algorithm for another: the engineering work required to deploy a scheme like FALCON safely is non-trivial.
Algorand's Falcon-1024 Mainnet Deployment
The highest-profile production deployment of FALCON in a public blockchain occurred on the Algorand mainnet in 2023. Algorand became the first major blockchain to execute a live mainnet transaction secured by a post-quantum digital signature, using Falcon-1024 at the 256-bit security level.
Algorand's choice of Falcon-1024 over Dilithium reflects the bandwidth constraints of a high-throughput network. Algorand's consensus mechanism, Pure Proof of Stake, requires validators to exchange and verify many signatures per round. At Algorand's transaction volumes, the difference between 1,280-byte Falcon-1024 signatures and 3,366-byte Dilithium-5 signatures has a direct impact on consensus message size and round latency.
The deployment was a landmark not just because it demonstrated FALCON working at production scale, but because it validated the floating-point implementation under real network conditions. Algorand's engineering team invested heavily in auditing their FALCON implementation for side-channel safety before the mainnet launch, and the result provided the broader blockchain ecosystem with a tested reference point for FALCON deployment.
The Algorand deployment also highlighted a practical nuance: FALCON-1024 was chosen rather than FALCON-512, despite FALCON-512 providing 128-bit security, which is above the classical security level of the ECDSA schemes it replaces. The reason is forward margin. Given the uncertainty in long-term quantum threat timelines, and the irreversibility of on-chain data, conservative practitioners are deploying at 256-bit post-quantum security levels to ensure that data signed today remains protected as quantum hardware advances. The harvest now, decrypt later threat makes that conservatism rational: adversaries collecting blockchain data today will attempt to verify signatures against harvested public keys once quantum hardware is available.
How QuanChain Deploys Both Dilithium and FALCON
QuanChain uses both CRYSTALS-Dilithium and FALCON as part of its TADEQS security architecture, with the choice of scheme determined by the security tier of the transaction in question.
The logic behind using two schemes reflects the genuine engineering tradeoffs between them. Dilithium's advantages are robustness and implementation simplicity: its reliance on integer arithmetic makes constant-time implementations straightforward to audit and verify, and its module lattice security assumptions are extremely conservative. FALCON's advantage is compactness: its NTRU-based Gaussian sampling produces signatures three to four times smaller than Dilithium at comparable security levels, which matters enormously for high-frequency, lower-value transactions where bandwidth and storage costs compound rapidly.
QuanChain's Three-Channel Architecture creates a natural mapping. Channel 1, which handles payments at 200,000+ TPS, is the primary consumer of FALCON. The combination of high transaction volume and relatively standardised transaction types makes Channel 1 the environment where FALCON's compactness delivers the greatest benefit and where the implementation overhead of its floating-point sampling can be amortised across a purpose-built, thoroughly audited signing module. For high-value transactions and smart contract operations on Channel 2, where the priority shifts from bandwidth efficiency toward maximum conservatism and implementation auditability, Dilithium is the default scheme.
This tiered approach is not unique to QuanChain, but building it into the protocol architecture from genesis, rather than retrofitting it later, is what makes it coherent. The Quantum Oracle that monitors real-time quantum computing capability feeds into the security tier assignment, so that as quantum hardware advances and the cost of attacking lower-security parameter sets falls, transactions are automatically routed to stronger schemes.
The result is a network that deploys post-quantum signatures across all transactions, uses the most bandwidth-efficient scheme where it is safe to do so, and maintains the flexibility to ratchet up to more conservative parameters as the threat landscape evolves. That is a materially different posture from blockchains that have not yet deployed any post-quantum cryptography at the protocol level, and it illustrates why the quantum vulnerability gap between chains is widening, not narrowing.
FALCON in the Broader Post-Quantum Landscape
NIST's finalisation of FN-DSA (the standardised form of FALCON) in FIPS 206, alongside ML-DSA (Dilithium) in FIPS 204 and SLH-DSA (SPHINCS+) in FIPS 205, established a clear hierarchy of post-quantum signature options. Each occupies a different position in the compactness-simplicity-conservatism tradeoff space.
SLH-DSA (SPHINCS+) is the most conservative: it relies only on hash function security, requires no lattice assumptions, and is therefore the safest bet against unknown cryptanalytic advances. But its signatures range from 8,000 to 50,000 bytes, making it impractical as a primary transaction signature scheme for high-throughput networks. ML-DSA (Dilithium) is the pragmatic middle ground: strong lattice security assumptions, integer arithmetic, conservative parameter choices, and signatures in the 2,000 to 3,000 byte range. FN-DSA (FALCON) is the compact specialist: NTRU lattice security, Gaussian floating-point sampling, and signatures in the 600 to 1,300 byte range, at the cost of a significantly more demanding implementation.
For blockchain specifically, the comparison that matters most is between ML-DSA and FN-DSA, since SLH-DSA's signature sizes effectively preclude it from widespread on-chain use. FALCON's compactness advantage is real and meaningful. The question for any given deployment is whether the engineering team has the capability to implement FALCON's floating-point sampling correctly and audit it for side-channel safety. The reference implementation and NIST test vectors provide a starting point, but production safety requires considerably more work.
The properties of a genuinely quantum-resistant blockchain include not just the choice of algorithm but the quality of implementation, the key management architecture, and the protocol-level decisions about what gets exposed on-chain. FALCON's compactness is only an advantage if the implementation is correct. That is the engineering challenge that separates theoretical post-quantum security from production post-quantum security.
Why Signature Size Matters More Than It Appears
The instinct to treat signature size as a second-order concern, something to be addressed after the primary security question is settled, underestimates how deeply signature overhead propagates through a blockchain's performance envelope.
At 200,000 TPS with ECDSA signatures of 64 bytes, raw signature data generates roughly 12.8 MB per second. Replace those with Dilithium at 2,420 bytes and the figure becomes 484 MB per second, before accounting for public keys. At FALCON-512's 660 bytes, the equivalent figure is 132 MB per second. Both are vastly larger than the ECDSA baseline, but the gap between Dilithium and FALCON amounts to 352 MB per second of additional bandwidth, which translates directly into hardware requirements, node costs, and the practical degree of decentralisation the network can sustain.
For anyone evaluating the differences between quantum-resistant and traditional blockchains, this arithmetic is part of the answer. Post-quantum migration is not free, but the cost varies dramatically depending on which post-quantum scheme is chosen and how it is deployed. FALCON's compactness, when implemented safely, is the closest thing the post-quantum signature space has to a free lunch: it gets you most of the way back from the Dilithium overhead without sacrificing NIST-standardised security.
That is why FALCON matters for high-performance blockchains, and why the engineering effort required to deploy it safely is worth taking seriously. The quantum threat calculator can help assess how urgently these design decisions matter for a given security horizon, but for any network expecting to remain operational through the next decade of quantum hardware development, the answer to that question is increasingly: more urgently than most chains have yet acknowledged.
FALCON is not a drop-in replacement for Dilithium. It is a complementary tool for environments where bandwidth is the binding constraint and implementation quality can be guaranteed. Deploying both, with the right architecture to route transactions to the right scheme, is the approach that maximises post-quantum security without sacrificing performance.
Conclusion
FALCON's NTRU lattice foundation gives it a structural compactness advantage that no other NIST-standardised signature scheme matches. At 660 bytes for FALCON-512 versus 2,420 bytes for Dilithium, the difference is not marginal, it is architectural. Algorand's Falcon-1024 mainnet deployment demonstrated that this compactness is achievable in production, and QuanChain's dual-scheme architecture shows how FALCON and Dilithium can coexist within a single network, each deployed where its properties best fit the workload.
The floating-point sampling challenge is real, but it is an engineering problem, not a theoretical obstacle. Teams with the capability to implement FALCON correctly gain a significant bandwidth advantage. For anyone building infrastructure intended to remain secure against quantum adversaries, that advantage is worth the investment in getting the implementation right.
The broader post-quantum blockchain landscape in 2026 is still dominated by networks that have not yet deployed any post-quantum signatures at the protocol level. FALCON, alongside Dilithium and SPHINCS+, represents the toolkit that changes that, one transaction at a time.
