FHE gives you encrypted computation. ZK gives you verifiable computation. Together: compute on data nobody can see, then prove the computation was correct without revealing the data or the result. One API call. Three PQ signature families. Measured on production Graviton4 hardware.
Fully homomorphic encryption solves one half of a problem. You can compute on encrypted data without ever seeing it. A bank can send you encrypted customer records, you can run a scoring model, and you can return encrypted results. Nobody in the pipeline — not even the compute operator — sees the plaintext data. That is real privacy.
But privacy alone is not enough. The bank also needs to know that you ran the correct model. The regulator needs to know that the compliance checks were applied. The auditor needs to know that the encrypted result is mathematically bound to the encrypted inputs and not fabricated. Privacy without accountability is a black box, and regulators do not trust black boxes.
Zero-knowledge proofs solve the other half. A ZK proof demonstrates that a specific computation was executed correctly — without revealing the inputs, the outputs, or any intermediate state. The verifier learns exactly one thing: "yes, this computation was applied to these encrypted inputs and produced this encrypted output, and nothing else happened."
Neither technology alone is sufficient for regulated production workloads. FHE without ZK is private but unverifiable. ZK without FHE is verifiable but requires the prover to see the data. The combination — FHE computation with ZK verification — is the first architecture where data remains encrypted throughout computation AND the computation is independently verifiable.
The core insight: FHE protects the data. ZK protects the computation. H33-74 protects the proof itself with three independent post-quantum signature families. Each layer addresses a different threat model. Together, they close every gap.
The H33 pipeline executes three stages for every computation. These stages are not optional modules that developers wire together. They execute automatically, in sequence, for every API call.
Stage 1: FHE Engine. The input data arrives encrypted. The FHE engine — BFV for exact integer operations, CKKS for real-number arithmetic, or TFHE for boolean comparisons — executes the requested computation on the ciphertext. The engine never decrypts the data. The computation operates entirely on encrypted polynomial representations. The output is an encrypted result that can only be decrypted by the data owner.
Stage 2: STARK Proof. Immediately after the FHE computation completes, a STARK (Scalable Transparent Argument of Knowledge) proof is generated. This proof captures the computation trace — every polynomial operation, every key-switch, every rescale — and compresses it into a proof that any third party can verify in microseconds. The proof reveals nothing about the data or the result. It proves only that the declared computation was executed correctly on the declared inputs.
Stage 3: H33-74 Attestation. The STARK proof, the computation metadata, and the encrypted result are committed via H33-74: a 74-byte attestation containing three post-quantum signatures (ML-DSA + FALCON + SLH-DSA) covering three independent mathematical hardness assumptions. This attestation is the permanent, quantum-resistant receipt that binds the encrypted result to the verified computation.
One API call. The developer submits encrypted data and a computation specification. The pipeline returns the encrypted result, the STARK proof, and the H33-74 attestation. No manual proof generation. No separate verification endpoint. No assembly required.
A bank wants to evaluate a customer for a loan. The customer's financial data is sensitive. The scoring model is proprietary. The regulator requires proof that the correct model was applied. Traditional approaches force a choice: share the data (privacy loss), trust the compute provider (verification gap), or build a bespoke secure enclave pipeline (18 months and seven figures).
In the H33 pipeline, this becomes a single API call with four stages:
The bank receives: an encrypted yes/no decision (decryptable only by the bank) and an H33-74 attestation. The regulator receives: the STARK proof demonstrating that the declared scoring model was applied correctly. Neither H33 nor the regulator sees the customer data. Neither the bank nor the regulator sees the model weights (if the model owner is a separate party). The STARK proof is independently verifiable by anyone with the public verification key.
Total pipeline latency for a 64-feature credit model: CKKS scoring (~333ms for the dot product layer) + TFHE threshold comparison (~1.3ms for an 8-bit encrypted comparison) + STARK proof (2.0µs cached) + H33-74 attestation (3.7µs). Under 350ms wall-clock for the full chain.
Two banks want to detect fraud across their combined transaction networks. Neither bank can share transaction data with the other — regulatory constraints, competitive concerns, and customer privacy all prohibit it. Without shared data, coordinated fraud detection is impossible. With shared data, compliance is impossible. This is the deadlock that has stalled cross-institutional fraud detection for a decade.
The H33 pipeline resolves the deadlock:
Neither bank sees the other's data. The compute provider sees neither bank's data. The regulator can verify correctness without seeing anyone's data. Fraud detection proceeds across institutional boundaries for the first time without a data-sharing agreement.
The examples above use multiple FHE engines in a single pipeline: CKKS for scoring, TFHE for comparison, BFV for exact matching. A developer building these pipelines should not need to select engines, manage scheme transitions, or decide when to generate a STARK proof. That is infrastructure, not application logic.
FHE-IQ is the routing layer that handles this automatically. Given a computation specification, FHE-IQ makes three decisions:
Routing overhead: under 500 nanoseconds per decision. For a pipeline that takes 350ms to execute, the routing layer contributes less than 0.0002% of total latency.
Every number below was measured on AWS Graviton4 c8g.metal-48xl (192 vCPUs, 96 physical cores, Neoverse V2). These are production hardware numbers, not projections.
| Stage | Latency | Notes |
|---|---|---|
| BFV batch (32 users) | 943 µs | Exact integer, biometric auth |
| BFV per-auth | 42 µs | Including Dilithium sign+verify |
| CKKS multiply pipeline | 61 ms | Full mul + relin + rescale |
| CKKS dot product (64-dim) | 333 ms | Encrypted vector inner product |
| TFHE 8-bit comparison | ~1.3 ms | Greater-than on encrypted integers |
| STARK proof (cached) | 2.0 µs | CacheeEngine lookup |
| STARK proof (cold) | 495 ms | Full proof generation |
| STARK verify | 71 µs | Independent verification |
| H33-74 attestation | 3.7 µs | Three-family PQ commitment |
| FHE-IQ routing | < 500 ns | Engine selection + proof boundary |
The critical number is the overhead that ZK and attestation add to an FHE computation. On cached paths — which represent the steady-state for repeated computation types — STARK proof lookup costs 2.0 microseconds and H33-74 attestation costs 3.7 microseconds. Total: under 6 microseconds. For a BFV authentication that takes 42 microseconds, the verification overhead is 14%. For a CKKS dot product that takes 333 milliseconds, the verification overhead is 0.002%. The verification cost is dominated by the FHE computation in every realistic workload.
Cold-path proof generation (495ms) is a one-time cost per computation type. Once a STARK proof for a specific computation pattern is cached in CacheeEngine, subsequent executions of the same pattern verify in 2.0 microseconds. A credit scoring pipeline that runs thousands of times per day pays the 495ms cost once.
The FHE ecosystem and the ZK ecosystem have developed largely in parallel. FHE libraries — SEAL, OpenFHE, Lattigo, TFHE-rs — provide encrypted computation without any proof of correctness. ZK libraries — Plonky2, Halo2, RISC Zero — provide verifiable computation but require the prover to see the plaintext data. These are two separate toolchains solving two separate problems, and the gap between them is where regulated production workloads need to live.
H33 is the first platform that combines both in a single pipeline with the following properties:
This is a platform, not a library. The distinction matters because nobody building a production system wants to wire together an FHE library, a ZK library, a post-quantum signature library, and a caching layer. They want to submit encrypted data and get back a verified, attested, encrypted result.
The combined FHE+ZK pipeline is available through the H33 API. A minimal example:
curl -X POST https://api.h33.ai/v1/compute \
-H "Authorization: Bearer $H33_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"operation": "dot_product",
"encrypted_input": "<base64-encoded CKKS ciphertext>",
"model_id": "credit-score-v3",
"proof": true,
"attest": true
}'The response includes:
encrypted_result — The CKKS ciphertext containing the computation output, decryptable only by the data owner.stark_proof — The STARK proof verifiable by any third party via /v1/verify.h33_74 — The 74-byte three-family PQ attestation.routing_decision — Which FHE engine(s) were used and why.Verification is a separate, stateless call:
curl -X POST https://api.h33.ai/v1/verify \
-H "Content-Type: application/json" \
-d '{
"stark_proof": "<proof from compute response>",
"h33_74": "<attestation from compute response>"
}'The verification endpoint requires no API key. Anyone can verify. That is the point of zero-knowledge proofs: verification is public, computation is private.
Pricing scales with computation type. BFV operations start at $0.001 per call. CKKS workloads are priced per operation in the computation graph. STARK proof generation is included — no separate ZK fee. Full pricing details at h33.ai/pricing.
Documentation, SDK installation, and quickstart guides: docs.h33.ai.
Encrypted computation with built-in proof of correctness. No data exposure. No trust assumptions. No assembly required. If you are building in a regulated industry where both privacy and auditability are non-negotiable, schedule a technical demo and see the pipeline end-to-end on your own data.