H33-Compile vs Zama Concrete:
Why We Built a Python FHE Compiler with 4-Engine Auto-Routing

Zama's Last Advantage

For months, every honest comparison between H33 and Zama ended with the same asterisk: "Zama has a Python FHE compiler. H33 doesn't."

Concrete lets data scientists write a Python function, decorate it with @fhe.compiler, and compile it into an FHE circuit. The function runs on encrypted data. The user never touches FHE parameters. That's a genuinely powerful developer experience, and we said so publicly on our comparison page.

We listed it as Zama's strongest differentiator. Not because we had to—because it was true. When you're building cryptographic infrastructure that people stake their security on, honesty isn't optional. If a competitor does something better, you say so. Then you go build something better.

Today that asterisk is gone. H33-Compile is built, tested, and shipping.

What We Built

H33-Compile is a Rust compiler with Python bindings (via PyO3) that does everything Concrete does—and then makes one critical architectural decision differently.

Concrete compiles to one FHE backend: TFHE. Every function, every data type, every workload goes through the same gate-by-gate TFHE pipeline. If your workload is better suited to a different FHE scheme—too bad.

H33-Compile compiles to four backends with automatic selection:

When you write @h33.compile, the compiler:

1. Parses your Python AST via rustpython-parser, in Rust, with no Python runtime dependency
2. Infers encrypted types from h33.EncInt, h33.EncFloat, h33.EncVec annotations
3. Builds a circuit DAG with multiplicative depth tracking
4. Runs 6 optimization passes: dead code elimination, common subexpression elimination, depth minimization, SIMD vectorization, relinearization placement, and latency estimation
5. Routes to the optimal engine via FHE-IQ in under 500 nanoseconds

Concrete can't do this. It has one engine. One set of parameters. One performance profile.

The Architecture

H33-Compile is a 6-crate Rust workspace. Each crate has a single responsibility, and they compose into a pipeline that takes Python source code and produces an optimized FHE circuit routed to the correct engine.

10 tests pass across the workspace. The frontend parses real Python functions. The optimizer reduces circuits. The router selects engines. It works.

Show Me the Code

from concrete import fhe

@fhe.compiler({"x": "encrypted"})
def add(x, y):
    return x + y

circuit = add.compile(
    inputset=[
        (i, i) for i in range(100)
    ]
)

import h33

@h33.compile
def match_biometric(
    template: h33.EncVec[128],
    sample: h33.EncVec[128]
) -> h33.EncBool:
    similarity = h33.dot(template, sample)
    return similarity > 0.85

circuit = match_biometric.compile()
print(circuit.engine)  # "Hybrid"
print(circuit.latency) # "939µs"
print(circuit.depth)   # 2

The key differences:

• 1. Type annotations over string hints. H33 uses Python type annotations (h33.EncVec[128]) instead of string dictionaries ({"x": "encrypted"}). Cleaner syntax, IDE-friendly autocompletion, and errors caught at compile time rather than runtime.
• 2. Automatic engine selection. You don't choose FHE parameters. You don't pick a scheme. FHE-IQ analyzes your circuit and selects the optimal engine. In the example above, it detects a float dot product (CKKS territory) followed by a comparison (BFV territory) and auto-selects Hybrid mode—splitting the computation across both engines.
• 3. Native vector and dot product support. H33 supports typed vectors and dot products as first-class operations. Concrete requires manual encoding of vectors into integer lookup tables or bootstrapped circuits.
• 4. Transparent routing. The compiled circuit tells you which engine was selected, the estimated latency, and the circuit depth. No black box. You can inspect the routing decision and override it if needed.

Why 4 Engines Beats 1

This isn't a marketing number. Four engines is a fundamental architectural advantage.

TFHE is a universal gate-based scheme. It can compute anything, but it computes everything the same way—through programmable bootstrapping. That's powerful but slow. A 64-bit addition takes 124ms on CPU. Bootstrapping is the bottleneck, and every operation hits it.

BFV is a batched integer scheme. It packs 4,096 plaintexts into SIMD slots and processes them in parallel. A 32-user biometric batch takes 939µs—not per user, per batch. That's 29µs per user. No bootstrapping. No gate-by-gate evaluation. Just polynomial arithmetic on packed ciphertexts.

CKKS is an approximate arithmetic scheme. It handles floating-point natively—dot products, similarity scores, ML inference weights, sigmoid activations. No precision loss from integer encoding. No awkward fixed-point quantization. Native float operations on encrypted data.

The right tool depends on the job:

Concrete sends all five of these through TFHE. Same bootstrapping pipeline. Same parameters. Same performance ceiling. H33-Compile sends each to the engine that was designed for that workload.

The performance difference isn't marginal. BFV processes a 32-user biometric batch in 939µs. TFHE's programmable bootstrapping takes 124ms for a single 64-bit addition. That's a gap measured in orders of magnitude, and it exists because the schemes are fundamentally different—not because one implementation is better than another.

What This Means for Zama

We're not shy about this: Zama has zero remaining technical advantages over H33.

Zama still has Ethereum depth (fhEVM) and more funding ($150M). Those are real advantages in their respective domains. But on technology—FHE performance, compiler UX, scheme coverage, post-quantum security, product breadth, and commercial accessibility—the gap is closed. And on most of those dimensions, it was never close to begin with. The Python compiler was the one area where Zama genuinely led, and that lead no longer exists.

Open Source

H33-Compile is Apache 2.0. The compiler, optimizer, and all backends are open source. The evaluation circuits, the routing logic, the test suite—all public.

Concrete's source is BSD-3-Clause-Clear with a mandatory patent license for commercial use. You can read the code for free. You can run it for research. But you cannot deploy it commercially without negotiating a patent license with Zama's legal team. Every Zama technology is patented, and the open-source license explicitly excludes commercial patent rights.

We chose Apache 2.0 deliberately. FHE adoption is still early. The last thing the ecosystem needs is a patent wall between developers and encrypted computation. If H33-Compile helps someone build something we never imagined, that's a win for the entire field—not a licensing opportunity.

Get Started

pip install h33-compiler is coming—currently Rust-only while PyO3 Python 3.14 support lands. In the meantime, you can build from source or use H33-Compile through the H33 API without installing anything: compile your function server-side and execute on H33's managed infrastructure.