Why We Open-Sourced the Verifier,
Not the Engine

The Trust Question

When an organization evaluates a cryptographic platform, the fundamental question is: why should I trust this system? There are two very different answers, and which one you choose determines your entire architecture.

The first answer is: trust the implementation. This is the open-source-everything approach. You publish every line of code. Anyone can inspect it, audit it, and verify that it does what it claims. Trust comes from transparency of the implementation itself.

The second answer is: trust the output. This is the verifiability approach. You publish the verification algorithm. Anyone can verify that the system's outputs are correct, without knowing how those outputs were produced. Trust comes from the mathematical properties of the output, not from inspection of the process.

H33 chose the second approach. Here is why.

The TLS Analogy

The TLS protocol secures the vast majority of internet traffic. When you visit a website over HTTPS, your browser verifies the server's TLS certificate using a public verification algorithm. The browser does not need access to the server's private key. The browser does not need to inspect the server's TLS implementation. It verifies the certificate, confirms the cryptographic handshake, and establishes a secure connection.

The TLS verification algorithm is public and standardized (RFC 8446). Certificate Authorities like Let's Encrypt and DigiCert are proprietary businesses. Nobody argues that TLS is insecure because Certificate Authorities are closed-source. The trust model does not depend on the CA's implementation being public. It depends on the verification being public.

H33 follows the same model. The verification algorithm is public and open-source. The proving engines (FHE, ZKP, signature generation, attestation) are proprietary. Trust flows from the verifiability of the output, not from inspection of the engine.

What We Open-Sourced

The H33 open-source verifier (available at github.com/H33ai-postquantum) includes the following components.

STARK proof verification. The complete FRI-based STARK verification algorithm. Given a STARK proof and a set of public inputs, the verifier confirms the proof is valid: the computation was performed correctly, the constraint polynomial is low-degree, and the Merkle commitments are consistent.

H33-74 attestation validation. The algorithm that verifies a 74-byte H33-74 attestation. Given the 74 bytes, the verifier reconstructs the SHA3-256 hash chain and confirms that the attestation is self-consistent.

Dilithium signature verification. ML-DSA (FIPS 204) signature verification. Given a signature, a message, and a public key, the verifier confirms the signature is valid.

SHA3-256 hash chain reconstruction. The algorithm that reconstructs the hash chain used in batch attestations. Given a batch of authentication results and the claimed hash chain, the verifier confirms each link was computed correctly.

These four components allow any third party to independently verify any output produced by the H33 platform. The verification is deterministic: given the same inputs, it always produces the same result.

What We Kept Proprietary

H33 maintains five proprietary cryptographic engines not included in the open-source release.

The FHE engine. H33's BFV implementation processes 32 users per ciphertext with a per-batch latency of 943 microseconds on Graviton4. This includes custom polynomial arithmetic, hardware-specific optimizations, and batching strategies covered by our patent portfolio.

The STARK prover. The prover includes the 7-column AIR constraint system, the trace generation pipeline, the FRI commitment strategy, and the DashMap caching architecture. These contain patented technology (Claims 124-125 cover batched Merkle response attestation).

The attestation pipeline. The orchestration system for FHE computation, signature generation, STARK proof creation, and H33-74 distillation. This pipeline processes over 2.2 million authentications per second.

The signature orchestration engine. The system managing three concurrent post-quantum signature families (ML-DSA, FALCON, SLH-DSA), including key management, signing coordination, and the distillation into the 74-byte H33-74 format.

Cachee. H33's distributed caching layer storing H33-74 expansion data, STARK proof references, and revocation status, with proprietary CacheeLFU eviction policy and count-min sketch admission control.

Why Open-Sourcing Everything Would Weaken Security

There is a counterintuitive argument here. In some cases, open-sourcing everything can actually weaken the security of a system. Not because security through obscurity works (it does not), but because open-sourcing the prover changes the threat model.

When the prover is closed-source, an attacker who wants to forge a proof must do so using only the mathematical properties of the proof system. They cannot study the prover's implementation for side-channel vulnerabilities, timing leaks, or edge cases. They must attack the math.

When the prover is open-source, an attacker gains additional attack surface. They can study the constraint system for under-constrained variables. They can look for edge cases in trace generation where constraints might not fully bind the computation. They can analyze Merkle tree construction for potential second-preimage attacks.

By keeping the prover closed and the verifier open, H33 forces attackers to attack the math (which is public and well-studied) rather than the implementation. The verifier is simple enough to audit exhaustively. The prover is complex enough that publishing it would create more risk than it would eliminate.

The Fundamental Asymmetry

There is a fundamental asymmetry in cryptographic systems between proving and verifying. Proving is hard, expensive, and full of implementation pitfalls. Verifying is simple, fast, and straightforward to implement correctly.

A STARK prover must generate a valid trace, compute constraint evaluations, build Merkle trees, perform FRI folding, and produce a proof satisfying all verification checks. The prover is thousands of lines of code with performance-critical inner loops and complex memory management.

A STARK verifier must check Merkle paths, evaluate constraints at random points, and verify FRI consistency. The verifier is hundreds of lines of code with straightforward control flow and no performance-critical paths.

This asymmetry means the verifier is much easier to audit, much less likely to contain bugs, and much more valuable to the trust model when made public. The prover generates value; the verifier establishes trust. Open-sourcing the verifier maximizes trust. Keeping the prover proprietary protects the investment that makes the system possible.

Independent Audits Fill the Gap

Open-sourcing is not the only way to establish confidence in code quality. H33 subjects its proprietary engines to independent cryptographic audits by third-party firms. These audits review the constraint system for completeness, the FHE implementation for correctness, and the signature pipeline for timing side-channel resistance.

The difference between an audit and open-sourcing is scope and control. An audit is performed by qualified professionals under NDA who have the expertise to evaluate cryptographic code and the context to understand what they are looking at. Open-sourcing exposes code to everyone, including people who lack the expertise to evaluate it but who have the motivation to find exploitable flaws.

For the verifier, broad public review is appropriate because verification code is simple enough for a wide audience to review. For the prover, focused expert review is appropriate because the prover's complexity requires specialized expertise and the attack surface implications of public exposure are significant.

The Business Reality

H33 has invested years of engineering effort into five proprietary cryptographic engines. Six patents are pending with over 250 claims. The performance we have achieved—2,209,429 authentications per second with zero external FHE or ZK dependencies—is the result of deep optimization work that represents our competitive moat.

If we open-sourced everything, competitors could replicate our pipeline without the R&D investment. The value would be commoditized. There would be no sustainable business model to fund continued development, ultimately harming customers who depend on the platform.

The open-source verifier model shares the trust-establishing component (benefiting everyone) while protecting the value-generating component (funding continued development). Customers get independently verifiable outputs. H33 gets a viable business model.

Industry Precedents

H33 is not alone. Intel SGX publishes the attestation verification protocol but not the microcode. Apple's Secure Enclave publishes the verification protocol for biometric attestations but not the secure element implementation. Google's Certificate Transparency logs publish the Merkle tree verification algorithm but not the log server implementation.

In every case, the trust model is the same: publish the verification, keep the engine proprietary. It works because mathematical verification does not depend on implementation details. A valid proof is valid regardless of how it was generated.

When Full Open Source Makes Sense

We want to be honest about cases where our approach is not the right one. If you are building a system where the threat model includes the proving party being malicious (a decentralized protocol where any participant can be a prover), then the prover should be open-source so all participants can verify each other's implementations.

H33 operates a different model. We are the prover. Our customers are the verifiers. The threat model is not "can H33 cheat?" (the open-source verifier prevents that) but "can an external attacker forge H33 outputs?" (the closed-source prover makes this harder). In our threat model, open-source verification plus closed-source proving is the optimal combination.

Conclusion

Open-sourcing the verifier and keeping the engine proprietary is not a compromise. It is a deliberate trust architecture that maximizes both security and sustainability. The verifier establishes trust through public, deterministic mathematical verification. The engine generates value through optimized, patented cryptographic computation. Both roles are essential, and each is best served by its respective distribution model.

Download the verifier from our GitHub (github.com/H33ai-postquantum). Trust the math, not the marketing.