The FHE industry is shipping the wrong thing. Open-source libraries like Microsoft SEAL, PALISADE, and OpenFHE provide correct implementations of FHE schemes. They support BFV, BGV, CKKS, and other encryption algorithms. They include polynomial arithmetic, key generation, encryption, decryption, and homomorphic evaluation. They are well-tested and academically rigorous. And they are almost completely useless for building production systems.
This is not a criticism of the library authors. These libraries serve their intended purpose: providing building blocks for researchers and developers who understand FHE at a mathematical level. The problem is that the gap between a correct FHE library and a production FHE system is enormous, and the industry has been underinvesting in closing that gap.
A production FHE system needs everything the library provides plus: automatic parameter selection based on the workload, key management with lifecycle and rotation policies, noise budget tracking and exhaustion prevention, ciphertext serialization and compression for network transport, multi-tenant isolation between different customers' encrypted data, monitoring and alerting for performance and correctness, error recovery when operations fail, batching optimization to maximize SIMD utilization with 4096 slots, attestation that computations were performed correctly, and integration with existing authentication and authorization systems.
Each of these requirements is a substantial engineering project. Together, they represent years of engineering effort that must be completed before a single encrypted computation serves a real user. This is why most FHE proofs-of-concept never reach production: the demo works on a laptop with hardcoded parameters, but the production system requires infrastructure that was never built.
The Workload Abstraction
H33's approach is to ship workloads, not primitives. A workload is a complete business function implemented in encrypted space, with all the infrastructure required to operate it in production. The developer interacts with the workload through a REST API that accepts business-level inputs and returns business-level outputs. The FHE machinery is invisible.
Consider biometric authentication. The primitive-level interface would require the developer to: generate FHE keys with appropriate parameters, encrypt biometric feature vectors into BFV ciphertexts with correct encoding, submit the ciphertexts to a computation endpoint, manage the homomorphic inner product evaluation, handle noise budget exhaustion, deserialize the encrypted result, decrypt with the secret key, and interpret the plaintext similarity score. Each step has error modes that the developer must handle, and the parameter choices at each step are interdependent.
The workload-level interface is: POST a biometric template to the enrollment endpoint, POST a biometric probe to the authentication endpoint, receive a match/no-match decision with a 74-byte attestation. Three API calls. No encryption parameters. No noise budgets. No polynomial arithmetic. The developer gets encrypted biometric authentication without becoming an FHE expert.
What Goes Into a Workload
Building a workload on top of FHE primitives requires solving several problems that the primitives do not address.
Parameter selection is the first problem. FHE parameters (polynomial degree, coefficient modulus, plaintext modulus) must be chosen to support the specific computation with adequate security and noise tolerance. Incorrect parameters cause either decryption failure (parameters too small) or unnecessary performance overhead (parameters too large). The optimal parameters depend on the computation graph, the security level, and the hardware. H33 solves this once per workload type and encodes the solution in the workload configuration.
Key management is the second problem. FHE requires multiple key types: secret keys for decryption, public keys for encryption, evaluation keys for homomorphic operations (including relinearization keys and Galois keys for rotation). These keys are large (evaluation keys can be hundreds of megabytes), they have security lifecycles, and they must be distributed to the right components without exposure. H33's key management system handles generation, storage, distribution, rotation, and revocation as infrastructure concerns.
Batching optimization is the third problem. With 4096 SIMD slots available per ciphertext, packing data efficiently into slots is critical for throughput. The optimal packing strategy depends on the computation structure. For matrix-vector products, you want to pack matrix rows into slots. For element-wise operations, you want to pack corresponding elements from multiple inputs. For reduction operations, you need rotation networks to accumulate values across slots. H33 selects the packing strategy based on the workload's computation graph.
Attestation is the fourth problem and the one most often overlooked. A production workload must prove that computations were performed correctly. H33's post-quantum attestation generates a 74-byte H33-74 token for every computation, using three independent hardness assumptions. This attestation is integral to the workload, not an add-on. Every response includes it, and the client SDK verifies it automatically.
The Developer Experience Gap
The developer experience of using FHE libraries directly is comparable to the developer experience of writing web applications using raw TCP sockets. It is technically possible, and some developers do it, but it is not how production systems are built. Production web applications use frameworks that abstract TCP, HTTP, TLS, session management, request routing, and response serialization. Developers work at the application level, not the protocol level.
FHE needs the same abstraction layers. Developers should work at the workload level (authenticate this user, score this credit application, detect fraud in these transactions), not at the cryptographic level (multiply these polynomials, manage this noise budget, rotate these ciphertext slots). The abstraction layers must be built once, by people who understand both the cryptography and the systems engineering, and then reused by every application developer.
H33 is building these abstraction layers. The API is RESTful. The SDKs are available in Python, Rust, and JavaScript. The documentation focuses on use cases, not on polynomial ring arithmetic. The error messages describe business-level failures, not cryptographic failures. A developer who has never heard of RLWE can deploy encrypted biometric authentication in an afternoon.
Performance Through Specialization
Generic FHE libraries optimize for generality. They support every parameter set, every computation pattern, and every use case. This generality comes at a performance cost because general-purpose code cannot exploit workload-specific optimization opportunities.
H33's workload approach enables workload-specific optimizations that generic libraries cannot match. The biometric authentication workload uses BFV with N=4096 and a single 56-bit modulus, parameters that are optimal for this specific computation but would be inappropriate for other computations. The encrypted ML inference workload uses CKKS with different parameters optimized for multiplicative depth. Each workload uses the minimum parameters that satisfy its security and correctness requirements.
The polynomial arithmetic is also workload-optimized. Generic libraries implement polynomial multiplication for arbitrary polynomial degrees and modulus sizes. H33's implementations are specialized for the specific degrees and moduli used by each workload, enabling algorithmic shortcuts and hardware-specific optimizations that generic implementations cannot use.
The result is production throughput of 2,293,766 authentications per second at 38 microseconds each. This is not achievable with generic FHE libraries running on the same hardware. The specialization makes the difference between a proof-of-concept and a production system.
The Path to Adoption
FHE adoption has been slow not because the cryptography is immature but because the engineering around the cryptography is immature. The schemes are well-understood, formally proven, and standardized. The implementations are correct and efficient. But the workloads, the complete business functions that organizations actually need, have been left as an exercise for the reader.
H33 is changing this by shifting the deliverable from primitives to workloads. Instead of asking organizations to hire FHE experts and build production systems from scratch, H33 provides production-ready encrypted workloads that can be deployed with an API key. The cryptographic expertise is embedded in the platform, not required of the customer.
This approach mirrors how every successful infrastructure technology has achieved adoption. Databases succeeded when SQL abstracted away B-tree management. Cloud computing succeeded when APIs abstracted away server provisioning. Machine learning succeeded when frameworks abstracted away gradient computation. FHE will succeed when workloads abstract away polynomial arithmetic. H33 is building that abstraction layer.
The primitives exist. The theory is proven. The implementations are efficient. What remains is the engineering that transforms cryptographic building blocks into business solutions. That engineering is the hard part, and it is where H33 focuses its effort. Encrypted workloads, not primitives. That is the path to production.
Case Study: From Library to Production
Consider the journey of a financial institution that wanted to deploy encrypted credit scoring. They started with an open-source FHE library and a working Python notebook that could encrypt a credit application, evaluate a logistic regression model homomorphically, and decrypt the score. The notebook ran on a laptop and produced correct results in about 30 seconds per application.
The production requirements were: process 10,000 applications per hour, integrate with the existing credit application API, maintain an audit trail for regulatory compliance, rotate encryption keys quarterly, support multi-tenant operation for different lending products, and monitor computation health with alerting for anomalies.
Bridging the gap from notebook to production required: selecting FHE parameters that balanced security with the 3.6-second-per-application latency target, building a key management service with HSM integration, implementing SIMD batching to pack multiple applications into each ciphertext (with 4096 SIMD slots, up to 4096 applications could be processed in parallel), building serialization and deserialization for network transport, implementing multi-tenant key isolation, building monitoring dashboards and alerting rules, and establishing an operational runbook for key rotation and incident response.
The institution spent nine months building this infrastructure. After nine months, they had a system that processed credit applications at the required throughput. But the system had no attestation of computation correctness, which their auditors flagged during the next examination cycle. Adding attestation would have required another six months of engineering.
With H33, the same deployment would have taken weeks, not months. The credit scoring workload is a standard H33 product. Parameter selection, key management, SIMD batching, serialization, multi-tenancy, monitoring, and attestation are all built into the platform. The institution would call the API, receive encrypted credit scores with 74-byte attestations, and present the attestation to auditors as compliance evidence. The nine months of infrastructure engineering is eliminated because H33 has already done it.
This case study is not unique. Every organization that tries to build production FHE from primitives encounters the same infrastructure gap. The cryptographic operations work correctly. The production surrounding them takes months to years to build. H33 exists to close that gap, converting months of infrastructure engineering into API calls that work on day one.