H33 vs Zama: Multi-Scheme FHE Pipeline Comparison

The homomorphic encryption space is seeing real commercial investment for the first time. Two companies sit at the center of this moment: Zama, which has raised significant venture capital to build open-source TFHE tooling, and H33, which has built a multi-scheme FHE pipeline fused with zero-knowledge proofs and post-quantum signatures. Both companies believe that computation on encrypted data is the future of privacy. They disagree fundamentally on how to get there, and those disagreements have concrete consequences for anyone evaluating FHE for production deployment.

Zama's thesis is that TFHE (Torus Fully Homomorphic Encryption) is the right scheme for general-purpose encrypted computation, and that the path to adoption runs through developer tooling. Their flagship products are TFHE-rs, a Rust implementation of the TFHE scheme, and Concrete, a Python-to-FHE compiler that lets developers write standard Python code and have it automatically converted into FHE operations. This is an elegant vision: make FHE as accessible as writing a Python script, and adoption will follow.

H33's thesis is different. FHE alone is not enough for production systems. Encrypting data during computation solves one problem, but production systems also need attestation (proof that the computation happened correctly), verification (proof that results were not tampered with), and quantum-resistant security (protection against both current and future threats). H33 builds all of these into a single pipeline that runs in a single process, using multiple FHE schemes selected to match the workload rather than forcing everything through one scheme.

Scheme Coverage: One vs Three

Zama focuses exclusively on TFHE. This scheme operates on individual bits or small integers, performing gate-by-gate operations on encrypted data. TFHE has a distinctive advantage: each gate operation includes a bootstrapping step that refreshes the noise in the ciphertext, which means you can perform computations of arbitrary depth without the noise growing unboundedly. This makes TFHE conceptually clean for boolean circuits and small-integer arithmetic.

However, TFHE is not the best scheme for every workload. Batched integer arithmetic, where you want to perform the same operation on thousands of values simultaneously, is much more efficient with BFV (Brakerski-Fan-Vercauteren). BFV packs up to 4,096 integer values into a single ciphertext using SIMD (Single Instruction, Multiple Data) slots, and a single homomorphic operation processes all 4,096 values at once. For workloads like biometric authentication, where you compute inner products over encrypted feature vectors, BFV's batching delivers throughput that TFHE cannot match.

Approximate floating-point arithmetic, the kind needed for machine learning inference or statistical analysis on encrypted data, is the domain of CKKS (Cheon-Kim-Kim-Song). CKKS encodes real numbers into polynomial rings and supports approximate arithmetic that preserves enough precision for practical workloads. Training a linear model on encrypted medical data or computing encrypted risk scores on financial portfolios are CKKS problems, not TFHE problems.

H33 implements all three schemes: BFV for batched integer arithmetic, CKKS for approximate floating-point, and TFHE for bit-level operations. All three are implemented from scratch in Rust with zero external FHE dependencies. The scheme selection is driven by the workload, not by what a single library happens to support. H33's production authentication pipeline uses BFV because batched biometric comparison is an integer inner product problem where 4,096 SIMD slots per ciphertext is the natural fit. The CKKS engine handles floating-point workloads like encrypted analytics. The TFHE engine handles bit-level operations where gate-by-gate bootstrapping is the right tool.

The Python Problem

Zama's Concrete compiler is designed to make FHE accessible to Python developers. You write Python code, annotate it with type hints, and Concrete compiles it into an FHE circuit that executes on encrypted data. This is a genuinely innovative approach to developer experience. The problem is that Python introduces overhead that compounds in production.

Python's Global Interpreter Lock (GIL) limits true parallelism to one thread of Python execution at a time. For FHE workloads, which are computationally intensive and benefit enormously from parallel execution across many cores, this is a fundamental bottleneck. Zama mitigates this by having the actual FHE operations run in Rust (via TFHE-rs) underneath the Python layer, but the orchestration, data marshaling, and control flow still run in Python. On a machine with 192 cores, the Python orchestration layer becomes the ceiling.

H33 is written entirely in Rust. There is no Python layer, no GIL, no serialization boundary between the orchestration code and the cryptographic code. When H33 runs on a 192-vCPU Graviton4 machine, all 192 cores are doing useful cryptographic work. The result is 2,293,766 authenticated operations per second sustained, where each operation includes FHE encryption, STARK-based ZKP verification, and post-quantum digital signature generation and verification. The per-authentication latency is 38 microseconds for the complete pipeline.

Zama does not publish equivalent end-to-end pipeline benchmarks because Zama does not provide an end-to-end pipeline. Their benchmarks measure individual TFHE operations: gate execution times, bootstrapping throughput, and key generation latency. These are useful numbers for understanding TFHE performance in isolation, but they do not tell you what throughput you will achieve when you integrate TFHE with your own ZKP system, your own signature layer, and your own caching infrastructure.

Attestation and Verification

This is the widest gap between the two systems. Zama provides encrypted computation. H33 provides encrypted computation with proof. When H33 processes a batch of 32 biometric authentications, the output includes not just the encrypted computation result but also a STARK-based zero-knowledge proof that the computation was performed correctly and a post-quantum digital signature that binds the result to the computation. The signature uses three independent hardness assumptions: MLWE lattices (ML-DSA), NTRU lattices (FALCON), and stateless hash functions (SLH-DSA). An attacker must break all three families simultaneously to forge an attestation.

Zama has no attestation layer. If you build a system on Zama's tooling, the FHE computation itself is sound, but you have no cryptographic proof that the computation was performed correctly, no tamper-evident signature on the result, and no post-quantum protection on whatever signature scheme you add yourself. You must source, evaluate, integrate, and maintain separate ZKP and signature libraries. The integration surface between these components is where security vulnerabilities most commonly hide.

H33's attestation output is distilled into a fixed 74-byte primitive called H33-74. This is not compression; it is distillation. The full cryptographic guarantees of three post-quantum signature families are preserved in a 74-byte artifact that can be stored on-chain or in any constrained environment. Thirty-two bytes live on-chain as a root hash, and forty-two bytes reside in Cachee for full verification on demand. This means every computation that flows through H33 generates a permanent, quantum-resistant attestation record at negligible storage cost.

Production Readiness

Zama's tooling is designed for developers building FHE applications. Concrete lowers the barrier to entry by allowing Python developers to experiment with encrypted computation without learning the mathematics of lattice-based cryptography. TFHE-rs provides a lower-level Rust library for developers who need more control. Both are open source and well-documented. For research, prototyping, and building proof-of-concept applications, Zama's tooling is capable and accessible.

Production readiness requires more than accessible APIs. It requires sustained throughput under load, deterministic latency under contention, memory safety guarantees in the hot path, and operational simplicity in deployment. H33 deploys as a single Rust binary with a REST API. There is no Python runtime to manage, no virtual environment to maintain, no dependency conflicts between FHE libraries and application code. The binary runs on ARM (Graviton4) or x86, and the entire pipeline executes in a single process with shared memory between the FHE, ZKP, and signature stages.

The operational difference is significant. A Zama-based production system requires you to manage the Python environment, the Rust compilation of TFHE-rs, the integration with whatever ZKP and signature libraries you choose, and the orchestration between all of these components. Each component has its own update cycle, its own security advisories, and its own performance characteristics that may interact unpredictably when combined. H33 ships as one binary that contains the entire pipeline, updated atomically, benchmarked as a unit.

Open Source vs Proprietary

Zama's TFHE-rs and Concrete are open source, which means you can inspect the code, modify it, and contribute improvements. This is valuable for trust, for research, and for organizations that require source code access for compliance reasons. The tradeoff is that open-source projects depend on continued investment from their maintainers, and Zama's business model for sustaining that investment long-term is still evolving. The FHE-as-a-service market is early, and the commercial viability of open-source FHE tooling remains an open question.

H33's FHE, ZKP, and signature engines are proprietary. The advantage is that H33 can make deep architectural decisions, like fusing the FHE and ZKP pipelines to share memory without serialization, that would be difficult to maintain across an open-source project with many contributors. The patent-pending optimizations in H33's pipeline are designed for a specific production workload and are tuned together as a system. The tradeoff is that you must trust H33's implementation through audits, benchmarks, and contractual SLAs rather than through source code inspection.

GPU Strategy

Zama has invested significantly in GPU acceleration for TFHE operations. Their roadmap includes GPU-accelerated bootstrapping, which could dramatically improve TFHE throughput for individual operations. GPU acceleration makes sense for TFHE because bootstrapping is the computational bottleneck, and the operation maps well to GPU architectures with thousands of parallel compute units.

H33 has validated GPU acceleration for multi-bit TFHE operations, achieving over 1,100 operations per second on an A10G GPU. However, H33's primary production path is CPU-based, running on ARM Graviton4 hardware where the entire pipeline fits in a single process without the complexity of CPU-GPU memory transfer. The production BFV pipeline uses SIMD batching across 4,096 slots to achieve parallelism at the mathematical level, which maps efficiently to wide CPU vector units without requiring GPU hardware.

The GPU question is ultimately about workload fit. For TFHE-heavy workloads with large bootstrapping requirements, GPU acceleration provides meaningful speedup. For batched BFV workloads where the parallelism comes from SIMD slot packing and multi-core execution, CPU-based deployment is simpler and more cost-effective. H33 supports both paths; Zama's GPU investment is exclusively for TFHE.

Developer Experience

Zama leads on developer experience for Python developers. Concrete's ability to compile annotated Python into FHE circuits is a significant achievement that lowers the barrier to entry for FHE adoption. For a data scientist who wants to run an encrypted computation on sensitive data, writing Python and having it "just work" on encrypted inputs is compelling. The documentation is extensive, the examples are clear, and the community is active.

H33's developer experience is API-first. You send data to an API endpoint, and you receive encrypted, verified, signed results. You do not need to understand FHE parameters, scheme selection, or noise budgets. The API abstracts the cryptographic complexity behind standard HTTP semantics. For backend engineers integrating encrypted computation into existing services, this is straightforward. For data scientists who want to write Python and have it execute on encrypted data, H33 requires a different workflow.

The choice between these approaches depends on your team and your use case. If your primary need is FHE experimentation with Python, Zama's developer experience is hard to beat. If your primary need is adding encrypted, attested, quantum-resistant computation to an existing production service, H33's API approach integrates with less friction because it does not require changing your programming language or development workflow.

Security Model Comparison

Both systems provide lattice-based FHE security for the encryption layer. The difference is in what surrounds the encryption. Zama's security model covers the confidentiality of data during computation. H33's security model covers confidentiality, integrity (through STARK proofs), authenticity (through post-quantum signatures), and non-repudiation (through on-chain attestation via H33-74). These are four distinct security properties, and only one of them is addressed by FHE alone.

For regulated industries like healthcare, finance, and government, integrity and authenticity are often as important as confidentiality. A healthcare system must not only encrypt patient data during processing but also prove that the processing was performed correctly and produce a tamper-evident record of the result. A financial system must not only encrypt transaction data but also attest that compliance checks were actually executed. These requirements cannot be met by FHE alone, regardless of which scheme or library you use.

The Bottom Line

Zama is building accessible FHE tooling with a focus on TFHE and Python developer experience. Their open-source approach and compiler-driven workflow lower the barrier to entry for FHE adoption. For research, prototyping, and TFHE-specific workloads, Zama provides capable tools with good documentation and an active community.

H33 is building a production cryptographic pipeline that fuses multi-scheme FHE with zero-knowledge proofs and post-quantum signatures. The pipeline processes 2,293,766 operations per second at 38 microseconds per authentication, including FHE, ZKP, and three-family PQ signing. Every computation produces a 74-byte attestation primitive that is quantum-resistant and verifiable. For production deployments that require the full spectrum of cryptographic guarantees, H33 provides a complete system where Zama provides one layer of a system you must build yourself.

The decision comes down to what you are building. If you need a TFHE library with a great Python interface, Zama is a strong choice. If you need a production pipeline that encrypts, verifies, and signs computation results with post-quantum security at millions of operations per second, that is what H33 was built for.