
Fast post-quantum signature aggregation with lattice SNARKs
a16z crypto announces Aerie, a lattice-SNARK system that aggregates Falcon-512/1024 signatures into one ~66 KiB proof. On an M4 Max laptop it handles 32,768 signatures in 0.65 s (~50k/s), verifies in 54 ms, and costs ~42 bytes per signature. It benchmarks against Orthus and Ethereum's leanVM hash-based XMSS aggregation, and argues that recursion-free lattice aggregation is simpler than hash-only designs. It also covers Falcon's hardware-wallet and side-channel constraints and why private payments need lattice encryption such as ML-KEM.
What it is
Aerie is a16z crypto's open-source (a16z/aerie) lattice-SNARK aggregator for Falcon-512 and Falcon-1024 signatures. It targets proof-of-stake chains that need post-quantum signature aggregation, which BLS cannot provide. The authors are Centelles, Dao, Thaler and Badakhshan. The post links a paper.
Numbers the summary lacks
- Proof size: about 66 KiB, regardless of batch. That covers 32,768 Falcon-512 signatures or 16,384 Falcon-1024 signatures.
- Salts are the hidden cost: Falcon's verifier hashes the message plus a 40-byte salt, so the aggregate must ship every salt. At 32,768 signatures that is about 1.3 MB, versus the 66 KiB proof. The ~42 bytes/signature figure includes the salts. Falcon-512 signatures are 666 bytes and Falcon-1024 signatures are 1,280 bytes.
- Algorand's deterministic Falcon could drop the salts entirely and ship just the proof, with small changes to Aerie's salt and signature-encoding handling.
- Single-core prover cost: about 8x standard Falcon verification time and 1.4x signing time.
- Versus Orthus (fastest prior Falcon aggregation, same AVX-512 server, one core): proves 1.5x faster, verifies 38x faster, proofs 1.7x smaller.
- Versus PSE's LaBRADOR-based Falcon aggregation: about 74 KB for 10,000 signatures, with verification taking seconds.
- Versus leanVM:
- XMSS: about 50,800 vs 1,770 signatures/s (29x).
- Stateless hash-based signatures: leanVM aggregates about 820/s on the same laptop model, roughly 60x slower than Aerie.
- The leanVM benchmark configuration caps each key at about 127,000 signatures.
- Each leanVM proof covers only about 900 signatures, so a full slot needs recursive merging.
- The Lean Consensus team's 2026 target is 1,000 signatures/s.
- Correctness claim: Aerie proves everything a standard Falcon verifier checks, including canonical signature encoding. The page says prior Falcon aggregation work skipped that check, so its aggregates could accept signatures a standard verifier rejects.
How it works
Two things make it fast:
- Akita, a lattice polynomial commitment scheme built with LayerZero Labs, plus sum-check proving techniques from the Lattice Jolt work. These are described as highly parallel and GPU-friendly. The reported numbers use no GPU.
- Falcon verification involves almost no hashing. The hash takes only the message and salt, so the verifier computes the hashes itself and the proof covers only the algebraic checks. Hash-based schemes need hundreds of hashes per signature, and proving hashes costs over 100x native.
The result is one proof from a node holding the slot's signatures, with no recursion. Any node holding the same signatures can replace a failed aggregator.
Preconditions and caveats
- Falcon only: ML-DSA is not supported yet, because its hash depends on the signature. It is planned, along with in-SNARK hashing to remove the salts and hybrid lattice plus elliptic-curve signatures. Those extensions may not reach 50k/s, but the authors expect headroom over 1,000/s.
- Benchmark conditions: the headline figures are from an Apple M4 Max with no GPU. Comparisons with Orthus and leanVM were run on the same machine.
- Falcon deployment constraints: signing is complex and was historically hard on hardware wallets. NIST plans to require fixed-point arithmetic in FN-DSA. One implementation signs Falcon-512 in about 11 kB of RAM. Side-channel hardening is still active work. The authors say they do not suggest every chain adopt Falcon.
- Advocacy: this is the authors' own post and benchmarks. Their argument that recursion-based hash designs are riskier and that lattices are unavoidable for private payments (ML-KEM) is an opinion, and the promised fuller security case is not in this post. They concede no one can rule out new lattice attacks.
What to do
If you are evaluating post-quantum aggregation for a chain, treat the 1.3 MB salt overhead, or the deterministic-Falcon variant, as the real size figure. Check the paper and repo for the canonical-encoding handling and for reproducing the benchmarks.
Organisations named here
- Aerie
- Akita
- Impagliazzo-Rudich
- Justin Thaler
- LaBinius
- LaBRADOR
- Lattice Jolt
- Lean Ethereum
- leanVM
- Merkle puzzles
- ML-DSA
- ML-KEM
- Orthus
Technologies named here
- BLS signatures
- Akita
- Lattice Jolt
- XMSS stateful hash-based signatures
- Orthus
- SPHINCS- variants light enough for a hardware wallet
- Prior Falcon aggregation work
- LaBRADOR-based Falcon aggregation
- LaBinius
- ML-DSA
- ML-KEM
- Algorand deterministic Falcon
- FALCON
- Ethereum
- Solana
- Ledger
- Alpenglow
- XMSS
- SPHINCS
- FN-DSA
- NIST
- Algorand
Techniques named here
- SNARK-based signature aggregation
- Recursive proof merging
- Impagliazzo and Rudich result
Related in other

Rerandomizable Garbling for Arithmetic Circuits

