Fully homomorphic encryption and zero-knowledge proofs solve different problems. FHE lets you compute on encrypted data without seeing it. ZK proofs let you prove something is true without revealing why it is true. Most systems offer one or the other. H33 chains them together in a single pipeline, executed in a single API call, because real-world applications need both confidentiality and verifiability simultaneously.
Consider what happens when a bank sends encrypted biometric data to a cloud authentication service. FHE ensures the cloud never sees the raw biometric template. The cloud computes a match score on encrypted vectors and returns an encrypted result. So far, so good. But the bank has a critical question: how does it know the cloud actually ran the biometric matching algorithm? What if the cloud returned a random ciphertext? What if it ran a cheaper, less accurate algorithm to save compute costs? What if a compromised server injected a fabricated match result?
Encryption alone cannot answer these questions. You need verification. And that verification must be independent of the encryption, because if the same compromised system that might fake the computation also generates the proof, the proof is worthless. This is why H33 uses STARKs, which produce proofs that can be verified by anyone, require no trusted setup, and rely on hash-based security that remains robust against quantum attacks.
The Three-Stage Pipeline
H33's production pipeline processes every API call through three stages. Understanding each stage, what it provides and what it costs, is essential for evaluating whether a combined FHE+ZK architecture makes sense for your workload.
Stage one is FHE computation. The client submits encrypted data, and H33 performs the requested computation homomorphically. For biometric authentication, this means computing inner products between encrypted feature vectors using BFV with 4096 SIMD slots. Each ciphertext encodes 32 user biometric vectors in parallel, and the homomorphic inner product produces encrypted similarity scores. This stage accounts for approximately 70% of the total pipeline latency because polynomial arithmetic on large ciphertexts is inherently expensive.
Stage two is batch attestation. After the FHE computation completes, H33 generates a cryptographic attestation of what was computed. This involves hashing the input ciphertexts and the computation result with SHA3-256, then signing the hash with Dilithium (ML-DSA), a post-quantum digital signature scheme. The attestation binds the specific input to the specific output through a specific computation, creating an unforgeable record. This stage accounts for approximately 29% of the pipeline latency, dominated by the post-quantum signature operations.
Stage three is ZK verification. H33 generates a STARK proof that the attestation was computed correctly, linking the FHE computation trace to the signed attestation. This proof is cached and looked up rather than generated from scratch for common computation patterns, reducing the verification overhead to less than 1% of the pipeline. The ZK layer ensures that even the attestation itself was produced honestly, closing the trust gap entirely.
The result is a response that contains: the encrypted computation result (confidentiality from FHE), a post-quantum signed attestation of correctness (integrity from digital signatures), and a STARK proof that the attestation is honest (verifiability from ZK). All three properties distilled into 74 bytes through H33-74.
Why Not Just FHE?
FHE advocates sometimes argue that encryption is sufficient. If the data is encrypted, the reasoning goes, it does not matter what the server does because the client holds the decryption key and can verify the result after decryption. This argument has two fatal flaws.
The first flaw is that decryption does not prove correctness. When you decrypt an FHE result and get a biometric match score of 0.97, you cannot determine whether that score resulted from the actual biometric matching algorithm or from a malicious server that encrypted the value 0.97 under your public key. Both would decrypt to the same plaintext. FHE guarantees that the server cannot read your data. It does not guarantee that the server processed your data correctly.
The second flaw is that many applications never decrypt on the client side. In multi-party computation scenarios, the encrypted result is passed to another encrypted stage. In privacy-preserving analytics, the aggregated result is decrypted by a collective key holder, not the individual data contributors. In these cases, no single party can decrypt and inspect the intermediate results. Verification must happen on the ciphertext level, and that requires zero-knowledge proofs.
Why Not Just ZK Proofs?
Zero-knowledge proofs have their own limitations when used alone. A ZK proof proves that a computation was performed correctly, but it does not hide the input data from the prover. In a typical ZK system, the prover sees the witness (the secret data) and generates a proof about it. The verifier learns nothing about the witness, but the prover sees everything.
This is fine for blockchain applications where the prover is the user proving their own statement. It is not fine for cloud computation where the prover is a third-party server that should not see the data at all. You cannot ask a cloud service to generate a ZK proof about data it is not allowed to see. This is precisely the gap that FHE fills: it allows the cloud to compute on the data without seeing it, and then ZK proofs verify that the computation was honest.
The combination is strictly more powerful than either primitive alone. FHE without ZK gives you confidentiality without verifiability. ZK without FHE gives you verifiability without confidentiality from the prover. FHE plus ZK gives you both, which is what regulated industries actually need.
The Caching Optimization
Generating a STARK proof from scratch for every API call would be prohibitively expensive. STARK proof generation involves converting the computation into an algebraic intermediate representation (AIR), interpolating execution traces over polynomial domains, and committing to those polynomials through Merkle trees. This process can take seconds for complex computations, far too long for a latency-sensitive authentication pipeline.
H33 solves this through cached STARK lookups. For common computation patterns like biometric matching, credit scoring, and fraud detection, the STARK proof structure is pre-computed and cached. Each incoming request is matched to a cached proof template, and only the input-specific values are substituted. This transforms proof generation from a seconds-long process to a sub-microsecond lookup, which is how the ZK stage achieves less than 1% of the total pipeline latency.
The cache is not a security shortcut. Each cached proof template is bound to a specific computation graph. If the computation changes, the cache miss forces a full proof generation. The caching only accelerates the common path; it never compromises the verification guarantee. And the cache itself is protected by the same post-quantum attestation layer, so a tampered cache entry would fail verification.
Post-Quantum Considerations
Both the FHE and ZK components of the pipeline must be quantum-resistant, or the system fails the moment a cryptographically relevant quantum computer exists. H33 addresses this at every layer.
The FHE layer uses BFV and CKKS, both lattice-based schemes. Lattice problems are believed to be hard for quantum computers, and they form the basis of NIST's post-quantum encryption standards. The encryption itself is quantum-resistant by construction.
The attestation layer uses Dilithium (ML-DSA) for signatures, a NIST-standardized post-quantum signature scheme also based on lattice assumptions. The STARK proofs use hash-based commitments (SHA3-256), which derive their security from the pre-image resistance of hash functions, a completely different mathematical assumption from lattices.
H33-74 distills the full attestation into 74 bytes using three independent hardness assumptions. This means the verification remains secure even if one cryptographic family is broken. If lattice assumptions fall to a quantum attack, the hash-based STARK commitments survive. If a breakthrough in hash function analysis occurs, the lattice-based signatures provide a second line of defense. Three independent mathematical bets, each of which must fail simultaneously for the system to be compromised.
Integration Patterns
The combined FHE+ZK pipeline supports several integration patterns depending on the application's trust model and performance requirements.
The simplest pattern is encrypt-compute-verify. The client encrypts data, sends it to H33, receives the encrypted result plus attestation, decrypts the result locally, and verifies the attestation. This pattern works for any application where the client has the decryption key and can tolerate the round-trip latency.
The delegation pattern is more complex. A client encrypts data and submits it, but designates a different party to receive and decrypt the result. The attestation travels with the encrypted result, so the receiving party can verify correctness before decryption. This is common in healthcare, where a patient might encrypt their medical records and send them to a specialist, with verification that the cloud processed them correctly in transit.
The consortium pattern involves multiple parties contributing encrypted data to a shared computation. Each party encrypts its inputs with its own key, and the FHE computation operates on multi-key ciphertexts. The STARK proof attests that all inputs were processed by the agreed-upon algorithm, and each party can independently verify the proof without needing to trust the other participants. This pattern powers H33's cross-institution fraud detection and privacy-preserving analytics products.
The streaming pattern is designed for continuous workloads like real-time authentication. Encrypted biometric vectors arrive in a stream, and H33 processes them in batches, generating a single attestation per batch. The batch attestation is amortized across all items in the batch, reducing the per-authentication verification overhead. At production throughput of 2,293,766 authentications per second with 38 microsecond per-authentication latency, the per-authentication cost of attestation becomes negligible.
What the Developer Sees
From the developer's perspective, the combined pipeline is a single API endpoint. You send encrypted data to the endpoint, and you receive back an encrypted result plus a verification object. You do not need to understand the internal staging, the proof generation strategy, or the caching mechanisms. The API abstracts all of this behind a clean request-response interface.
The verification object is designed to be independently checkable. Any party with the public verification key can confirm that the computation was performed correctly, without needing access to the encrypted data or the decryption key. This separation of concerns is critical: the party that verifies does not need to be the party that decrypts, and the party that decrypts does not need to be the party that computed.
Error handling in the combined pipeline follows a fail-secure model. If the FHE computation fails due to noise budget exhaustion, no attestation is generated and no result is returned. If the STARK proof generation fails due to a cache miss combined with a timeout, the FHE result is held and the proof is retried. Under no circumstances does the system return an encrypted result without a valid attestation. The attestation is not optional; it is a mandatory component of every response.
Performance at Scale
The combined pipeline at production scale on ARM Graviton4 processes authenticated encrypted computations at 2,293,766 per second with a per-authentication latency of 38 microseconds. The FHE batch computation takes approximately 70% of the total time, the post-quantum attestation takes approximately 29%, and the STARK verification takes less than 1%.
These numbers reflect the full pipeline, not individual components benchmarked in isolation. Every authentication is encrypted, computed homomorphically, attested with post-quantum signatures, verified with a STARK proof, and distilled into a 74-byte H33-74 token. There is no FHE-only mode that skips attestation for better performance numbers. The pipeline is all-or-nothing because partial security is not security.
Memory consumption is dominated by the FHE ciphertexts and evaluation keys. The STARK proof cache adds minimal overhead because cached proofs are compact and shared across concurrent requests. The system is designed to scale horizontally: additional Graviton4 instances process independent batches, and the STARK cache is shared across instances through a distributed caching layer.
The future of encrypted computation is not FHE or ZK proofs in isolation. It is FHE and ZK proofs combined in a single pipeline that delivers the full spectrum of security properties that regulated industries demand. H33 builds and operates that pipeline today, running in production at scale.