Encrypted Computation vs Verifiable Decision Infrastructure

What Zama Does Well

Zama focuses on FHE primitives. The Concrete compiler transforms Python programs into optimized FHE circuits. TFHE-rs provides a Rust implementation of the TFHE scheme with programmable bootstrapping -- the ability to evaluate arbitrary lookup tables on encrypted data, refreshing noise budgets in the process. This enables general-purpose computation over encrypted inputs without scheme-switching or manual noise management.

The technical contribution is real and significant. Programmable bootstrapping is the mechanism that makes TFHE practical for complex circuits. Graph-level optimization in the Concrete compiler reduces the number of bootstrapping operations required, directly improving performance. Key switching, circuit packing, and parallelization strategies further reduce latency for specific workloads. Zama has also extended this into ML inference over encrypted data, allowing models to classify encrypted inputs without decryption.

This is computation infrastructure. It is important work. FHE primitives are necessary for encrypted processing, and Zama has invested heavily in making those primitives faster, more ergonomic, and more accessible through compiler tooling. The Concrete compiler allows developers to write standard Python and have it compiled to FHE circuits -- a meaningful developer experience improvement over manual parameter selection and noise budget tracking.

None of this is in dispute. The question is what computation infrastructure alone can and cannot provide.

What Computation Alone Cannot Provide

Encrypted computation proves that a computation occurred on encrypted data. It produces a result. The FHE scheme's mathematical properties guarantee that the result is correct -- the homomorphic property ensures that operations on ciphertexts produce ciphertexts that decrypt to the correct plaintext result. This is a cryptographic guarantee about computational correctness.

But computational correctness is only one dimension of what regulated systems require. Encrypted computation does not prove:

• Why the computation was permitted. What governance policy authorized this specific operation on this specific data at this specific time? Was the requester authorized? Was the data classification appropriate for the requested operation? Was the security tier sufficient?
• How it was routed. Which FHE engine processed the computation? Why was that engine selected over alternatives? What parameters were used? What security tier was applied? If the system has five proprietary engines (BFV, CKKS, TFHE, TFHE Bootstrap, FHE-IQ), the routing decision itself is a governance event that must be recorded and verifiable.
• What policy state authorized it. Governance policies change. A computation authorized under Tuesday's policy may not be authorized under Wednesday's policy. The governance graph at the moment of the decision -- the exact state of every relevant policy, scope constraint, and authorization rule -- must be captured and bound to the result.
• Whether the decision can be independently replayed. Given the same governance graph and the same inputs at the same timestamp, does an independent implementation produce the identical result? Deterministic replay is the strongest form of verification: not "trust our output" but "reproduce it yourself."
• Whether the execution lineage is verifiable. Can a third party trace the decision from input through governance evaluation, engine routing, computation, attestation, and output -- verifying each link in the chain without trusting any single component?
• Whether an independent party can verify the result without trusting anyone. Public verification -- no API key, no network connection, no trust assumption about the issuing system -- is the operational standard for systems that face regulatory scrutiny, litigation, or adversarial audit.

These are not optional features for sophisticated deployments. For enterprises operating under regulatory scrutiny -- healthcare systems processing encrypted patient data, financial institutions computing on encrypted transactions, government agencies evaluating encrypted intelligence -- these are requirements. A correct computation that cannot prove its authorization, cannot be replayed, and cannot be independently verified is a correct computation that cannot be deployed.

What H33 Provides Above the Computation Layer

H33 operates at the orchestration, governance, attestation, and verification layer above encrypted computation primitives. The computation layer -- five proprietary engines (BFV, CKKS, TFHE, TFHE Bootstrap, FHE-IQ) -- is necessary infrastructure. What H33 builds on top of it is the decision infrastructure that makes encrypted computation governable, replayable, and independently verifiable.

• Routing (FHE-IQ): FHE-IQ routes computations to the optimal engine based on security tier, data type, and performance requirements. A biometric match routes to BFV. A financial model routes to CKKS. A gate-level boolean evaluation routes to TFHE. This is system-level routing above engines, not optimization within a single engine's computation graph. The routing decision itself is attested and bound to the governance state that authorized it.
• Governance (HATS Protocol): Every computation is bound to a governance state via the HATS protocol. The governance graph captures why a computation was permitted, what policy authorized it, what scope constraints applied, and what authorization chain led to the decision. The governance state is immutable at the moment of decision -- it is a snapshot, not a reference.
• Attestation (H33-74): Every operation produces an H33-74 attestation -- 74 bytes containing three independent post-quantum signature families (ML-DSA, FALCON, SLH-DSA). The attestation is the decision rendered as an independently verifiable artifact. It is not a log entry. It is not metadata. It is a cryptographic commitment to the entire decision state.
• Replay: Any attested session can be deterministically replayed. Same governance graph + same timestamp = byte-identical output. This is verified with h33 replay session session.json. Replay is the strongest form of trust: not "believe our output" but "run it yourself and compare."
• Verification: Any receipt can be verified offline. h33 verify receipt receipt.json -- no API key, no network, no trust assumption. The verifier is a standalone binary. The verification is a pure function of the receipt contents. Independent parties can verify any attestation without any relationship to H33.
• Diff: Semantic comparison of what changed between two attested states. h33 diff receipt before.json after.json produces a categorized diff across six dimensions: identity, execution path, governance state, policy output, attestation, and temporal. This is not a text diff. It is a semantic analysis of what changed in the decision infrastructure between two points in time.
• Agent Governance: Bounded autonomous execution with cryptographic lineage. Agent-Zero provides delegation budgets (how much authority is delegated), approval quorums (how many parties must approve), exposure proofs (what was accessed), and full attestation chains for every autonomous action. Every agent decision is replayable and verifiable through the same infrastructure.

The Abstraction Layer Map

The clearest way to understand the relationship between Zama and H33 is to map what each system provides at each layer of the encrypted computation stack.

The table reveals the structural difference. Zama provides deep capability at the primitive layer. H33 provides capability across the full operational stack. These are not competing approaches -- they address different requirements at different layers of the system.

Why This Matters Operationally

Consider a healthcare system computing on encrypted patient data. The computation itself -- matching encrypted biometric templates, evaluating encrypted diagnostic models, computing encrypted risk scores -- requires FHE primitives. The math must be correct. The noise budget must be managed. The performance must be acceptable.

But the healthcare system also needs to prove that the computation was authorized by the correct policy. That the patient's consent scope covered this specific operation. That the data classification was appropriate for the security tier used. That the result was attested with signatures that will survive quantum computers. That a regulator can replay the entire session independently -- not by trusting the healthcare system's logs, but by running the replay themselves and comparing the output.

A financial institution computing on encrypted transaction data faces the same requirements. So does a government agency, an insurance company, a legal discovery platform, or any system that processes sensitive data under regulatory oversight. The computation must be correct. But it must also be authorized, attested, replayable, and independently verifiable.

Encrypted computation is the foundation. Verifiable decision infrastructure is what makes it operationally deployable.

The Correct Position

This is not "H33 replaces Zama." It is "H33 addresses requirements that Zama's architecture is not designed to address." Zama's Concrete compiler does not attempt to capture governance state, produce attestations, enable deterministic replay, or provide offline verification -- because these are not compiler problems. They are infrastructure problems at a different abstraction layer.

A sophisticated buyer evaluating both systems should not ask "which one is faster at FHE." They should ask "what do I need beyond FHE to operate this system under regulatory scrutiny?" The answer to that question determines whether computation primitives alone are sufficient, or whether the full operational stack -- routing, governance, attestation, replay, verification, agent governance, conformance -- is required.