What Is Zama?
Zama is a French cryptography startup founded in 2020, backed by a $73M Series A in 2024. Their mission is to make fully homomorphic encryption accessible to developers who have no cryptographic background. They ship three primary products:
- TFHE-rs — a pure-Rust implementation of the TFHE (Torus Fully Homomorphic Encryption) scheme, licensed under BSD-3-Clause. It provides programmable bootstrapping (PBS), which allows arbitrary lookup-table evaluations on encrypted data.
- Concrete — a Python-to-FHE compiler that takes NumPy-style code, analyzes bit-widths, selects parameters, and compiles to TFHE circuits. It dramatically simplifies prototyping.
- fhEVM — a modified Ethereum Virtual Machine that executes Solidity smart contracts over encrypted state using TFHE. Primarily targets on-chain confidential computation.
This is genuinely useful work. Concrete in particular has helped hundreds of researchers explore FHE without manually tuning noise budgets. But Zama's architecture is optimized for generality and programmability, not for the sustained, high-throughput authentication workloads that enterprise security demands.
Where Zama Falls Short for Authentication
The fundamental bottleneck in Zama's stack is programmable bootstrapping. PBS is TFHE's most powerful primitive — it allows you to evaluate any function as a lookup table on encrypted data while simultaneously refreshing the ciphertext noise. This is elegant theory. In practice, a single PBS operation takes roughly 10–50 milliseconds depending on parameter sets, hardware, and the lookup table size.
Programmable bootstrapping is TFHE's strength and its ceiling. Every non-trivial operation chains through PBS, and each PBS costs 10–50ms. An authentication pipeline requiring multiple encrypted comparisons accumulates latency that cannot be parallelized away at the single-user level.
Beyond raw latency, Zama's architecture has structural gaps when evaluated against production authentication requirements:
- No SIMD batching. TFHE operates on individual encrypted integers, not batched polynomial slots. H33 packs 32 biometric templates into a single BFV ciphertext using CRT-based SIMD — one encrypt-multiply-decrypt cycle authenticates 32 users simultaneously in 967µs.
- No post-quantum signatures. Zama provides FHE encryption but no Dilithium attestation, no zero-knowledge proofs, and no biometric pipeline. Authentication requires more than encryption — it requires proof that the encrypted computation was performed correctly and that the result is bound to a specific identity.
- No integrated verification layer. H33's pipeline includes a STARK-based ZKP cache (0.062µs lookup) and a Dilithium signature (191µs) in every authentication call. Zama would require bolting on external libraries for each of these, with no guarantee of composability or performance.
- Compiler overhead. Concrete adds a compilation step that transforms Python into TFHE circuits. This is valuable for rapid prototyping, but the resulting circuits are not hand-optimized for specific workloads. H33's BFV engine uses Montgomery-form NTT with Harvey lazy reduction, radix-4 butterflies, and NEON-accelerated Galois rotations — optimizations that a general-purpose compiler cannot discover.
- Blockchain-first focus. fhEVM targets on-chain confidential smart contracts — a fundamentally different use case from enterprise biometric authentication at scale. The throughput constraints of blockchain consensus (seconds per block) mask FHE latency. In a real-time authentication API serving millions of requests per second, those milliseconds are disqualifying.
How H33 Solves the Same Problem Differently
H33 does not attempt to be a general-purpose FHE toolkit. The entire stack is purpose-built for one mission: post-quantum biometric authentication at production scale. Every architectural decision flows from that constraint.
The H33 authentication pipeline completes in a single API call. A 32-user batch flows through three stages:
- FHE Batch (BFV) — 32 biometric templates are SIMD-packed into one ciphertext. A single encrypted inner product computes all 32 match scores in 967µs. The NTT engine uses Montgomery multiplication with pre-computed twiddle factors, parallel moduli processing via Rayon, and pre-NTT public keys to eliminate redundant transforms.
- ZKP Verification — An in-process DashMap lookup retrieves the cached STARK proof for the batch in 0.062µs. No TCP, no serialization, no inter-process communication. The proof verifies that the FHE computation was performed correctly without revealing the biometric data.
- Post-Quantum Attestation — A single CRYSTALS-Dilithium sign-and-verify cycle binds the entire batch result to an unforgeable, quantum-resistant attestation in 191µs. One signature covers all 32 users — a 31x reduction versus individual attestation.
Total batch latency: ~1,160µs for 32 users. Per-authentication cost: ~36µs. Sustained throughput on a single Graviton4 instance (c8g.metal-48xl, 96 workers): 1,714,496 auth/sec over 120 seconds, with a 30-second peak of 2,154,351 auth/sec. These are Criterion.rs-measured numbers on production hardware, not theoretical projections.
H33's cryptographic stack is backed by 2,227 tests covering BFV, CKKS, NTT, Dilithium, Kyber, ZKP, biometric enrollment, batch verification, and edge cases. 108 patent claims are pending across the FHE, ZKP, and post-quantum signature pipeline. NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) compliant.
Head-to-Head Comparison
| Metric | H33 | Zama (TFHE-rs / Concrete) |
|---|---|---|
| FHE Scheme | BFV (exact arithmetic) + CKKS (approximate) | TFHE (Torus FHE) |
| Per-Operation Latency | 36µs per auth (32-user SIMD batch) | ~10–50ms per PBS operation |
| Batching Model | CRT SIMD: 32 users per ciphertext (4096 slots ÷ 128 dims) | No SIMD batching; per-integer operations |
| Sustained Throughput | 1.71M auth/sec (120s, Graviton4) | Academic benchmarks only; no published sustained auth numbers |
| Post-Quantum Signatures | CRYSTALS-Dilithium (FIPS 204 ML-DSA), 191µs attest | None integrated |
| ZKP Integration | STARK proofs + in-process DashMap cache (0.062µs) | None integrated |
| Biometric Pipeline | FHE-encrypted enrollment, matching, and verification in one API call | No biometric support; general-purpose FHE only |
| Primary Use Case | Enterprise authentication & identity at scale | FHE tooling, blockchain confidential compute (fhEVM) |
The comparison is not entirely apples-to-apples, and that is precisely the point. Zama builds general-purpose FHE tools. H33 builds a vertically integrated authentication engine. When the evaluation criterion is "authenticate millions of users per second with post-quantum guarantees," the vertical approach wins by three orders of magnitude.
When to Use Each
Choose Zama when:
- You are prototyping a novel FHE application and need a compiler to handle parameter selection (Concrete).
- You need programmable bootstrapping for arbitrary function evaluation on encrypted data — e.g., encrypted machine learning inference where the model topology changes frequently.
- You are building on-chain confidential smart contracts with fhEVM and throughput is bounded by blockchain consensus, not FHE latency.
- You want an open-source TFHE library (BSD-3-Clause) for academic research or experimentation.
Choose H33 when:
- You need production-grade biometric authentication at scale — thousands to millions of authentications per second with sub-millisecond latency.
- Post-quantum security is a requirement today, not a roadmap item. H33 ships Dilithium signatures and Kyber key exchange in every API call, compliant with NIST FIPS 203/204.
- You need an integrated verification stack — FHE + ZKP + PQ signatures — rather than assembling one from disparate libraries.
- Your SLA requires sustained throughput numbers validated by Criterion.rs benchmarks on real hardware, not theoretical projections from academic papers.
Zama's contributions to FHE accessibility are real. Concrete has made FHE approachable for thousands of developers. TFHE-rs is well-engineered Rust code. The question is not whether Zama is good — it is whether general-purpose FHE tooling can match a purpose-built authentication engine when the metric is production throughput. It cannot.
Try It Yourself
H33's authentication API is live today. A single POST to the
H33 API runs the full FHE + ZKP + Dilithium pipeline in under
36µs per user. No parameter tuning, no compilation step, no separate libraries to
integrate.