Algorand ships Falcon in production. The September 2024 v4.3.0 consensus upgrade added falcon_verify as a native AVM opcode – on-chain signature verification, not a proof wrapper, not a precompile proposal.
That makes Falcon unusual among NIST-selected post-quantum schemes: it has a real deployment to study, benchmark, and learn from before your team has to make the same decisions. This article focuses on what that deployment teaches – and what it leaves unresolved for chains.
This article draws on a comprehensive technical paper covering Falcon's cryptographic foundations, implementation subtleties, security analysis, and blockchain migration considerations.
📄 Falcon: A Lattice-Based Digital Signature Algorithm for Post-Quantum Blockchains — Mike Mu (January 2026)
Why Signature Size Is the Biggest Post-Quantum Challenge for Blockchain
Signature size is not an abstract concern in blockchain infrastructure. Every extra byte per transaction multiplies across block payloads, archive storage, and fee markets. At scale, the cumulative costs are unforgiving.
Falcon-512 signatures are 3.6× smaller than comparable ML-DSA at the same security level – and on ARMv8-A hardware, Falcon verification runs 3–4× faster. For high-throughput systems, this is the difference between a feasible post-quantum migration and one that requires renegotiating block size limits entirely.
How Falcon Uses NTRU Lattices to Produce the Smallest Post-Quantum Signatures
Where ML-DSA builds on module lattices with clean integer arithmetic, Falcon uses a structurally different construction – the NTRU lattice – that enables smaller outputs at the cost of a more demanding implementation.
Falcon operates over the polynomial ring , with . The secret key holds four short polynomials (f, g, F, G) satisfying the fundamental NTRU equation:
The public key is derived as – a single polynomial. Recovering (f, g, F, G) from h reduces to the Shortest Vector Problem in the NTRU lattice, for which no polynomial-time quantum algorithm is known.
Signing finds a short vector close to a message-hash target using the secret trapdoor. Verification checks one modular equation and one norm bound:
, and
The compactness follows directly: the NTRU structure produces shorter vectors than module lattices, and shorter vectors mean smaller signatures. FFT and NTT reduce polynomial multiplication from , enabling microsecond-range verification in practice.
Security estimates. The best known forgery attack on Falcon-512 requires BKZ lattice reduction with block size B ≈ 411, corresponding to ~120 classical and ~108 quantum bits of security. Falcon-1024 requires B ≈ 952, reaching ~277 classical and ~252 quantum bits – NIST Level V.
Falcon's Hidden Complexity: Floating-Point Side Channels and the Formal Proof Gap
Falcon's size advantage rests entirely on its trapdoor Gaussian sampler – and that sampler is where implementations fail.
The signing algorithm uses double-precision IEEE 754 floating-point arithmetic for FFT operations and discrete Gaussian sampling. This introduces risks that do not exist in ML-DSA:
Floating-point side-channel exposure. Researchers demonstrated single-trace power analysis on Falcon-512 that recovers secret key coefficients by observing floating-point bit-shifts during sampling. This has been reproduced on embedded microcontrollers – it is not a theoretical concern. On hardware where power or electromagnetic side channels are accessible, constant-time floating-point is required, and masked sampling or fixed-point conversion becomes non-negotiable.
Cross-platform non-determinism. Signing can produce different outputs across x86, ARM, and embedded targets when floating-point controls are not explicitly enforced. Verification is deterministic – it uses NTT integer arithmetic modulo q. Signing is not. In consensus systems with heterogeneous validator hardware, cross-architecture KAT validation must be part of CI.
The Formal Proof Gap – and Falcon+. Standard Falcon parameters do not satisfy all conditions of the classical GPV trapdoor-signature security proof. A 2024 paper (A Closer Look at Falcon, Gajland, Janneck, Kiltz) identified this gap and proposed Falcon+, which introduces three targeted modifications:
- A per-message salt incorporated into the HashToPoint input
- Public-key binding in the hash computation: H(pk, r, m) rather than H(r, m)
- Adjusted Gaussian width and rejection threshold to satisfy lossy trapdoor sampling requirements
These changes enable a full EUF-CMA proof in the Random Oracle Model – the standard security guarantee for production signature schemes.
Deploying Falcon on EVM: Gas Costs, EIP-8052, and On-Chain Integration Paths
Algorand could add falcon_verify as a native opcode. Ethereum cannot – at least not yet.
There is no Falcon precompile on EVM today. A pure Solidity implementation of Falcon-512 verification costs 1.8–7 million gas depending on the variant. Draft EIP-8052 proposes a standardised precompile targeting ~3,000 gas per verification. Until that lands, practical on-chain Falcon integration requires one of two paths:
- Off-chain verification with on-chain attestation. Signature validity is checked off-chain; only a proof or status bit is posted on-chain. This is the lowest-friction path available today.
- ERC-4337 account abstraction. Enables Falcon-signed user operations without a protocol-level hard fork. Limitation: bundler transactions still require ECDSA, so complete ECDSA removal demands deeper protocol changes.
For hybrid transitions – where ECDSA and Falcon coexist during a migration epoch – model the full per-transaction footprint before any protocol-level commitment. A Falcon-512 signature (666 B) plus public key (897 B) represents a ~16× increase in per-signer on-chain footprint compared to Ed25519.
Falcon vs. ML-DSA (CRYSTALS-Dilithium): Which Post-Quantum Signature Is Right for Your Chain?
Both Falcon and ML-DSA are NIST-standardised lattice-based signature schemes targeting equivalent security levels. Their underlying algebraic structures differ – Falcon operates over NTRU lattices, ML-DSA over module lattices – and that difference propagates into every practical deployment consideration: size, signing latency, implementation surface, and ecosystem readiness.
Neither scheme is strictly superior. The selection criteria are determined by the dominant constraints of the target system.
One constraint is definitive: Falcon-based threshold multisig does not exist in production form. Lattice-based TSS/MPC (including both Falcon and ML-DSA) remains at the research stage; ML-DSA may have a somewhat more active threshold ecosystem in the near term, but neither has production-grade m-of-n tooling yet.
Falcon Security Audit Checklist
Conclusion
Falcon addresses the size problem that makes most post-quantum signatures difficult to deploy at blockchain scale. Algorand's production deployment is the proof of concept. The unresolved questions – EVM precompile standardisation via EIP-8052, floating-point hardening at firmware level, lattice-based threshold schemes – are engineering problems, not fundamental research barriers.
The honest starting point for most teams is not "should we use Falcon?" but rather answering three prior questions: Where do our ECDSA keys live? How long do our assets need to remain secure? Can our chain absorb a 10× signature size increase? Answer those, and the migration path becomes concrete.
Hacken provides post-quantum readiness assessments for blockchain protocols, covering cryptographic dependency mapping, migration architecture review, and implementation audit for Falcon and ML-DSA deployments.
Ready to assess your protocol's post-quantum exposure? [Request a security review]
