AIR
Proof Lab
StartEcosystem
Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
Technical Architecture — Cross-Engine Documentation

Three Engines. One API.
Every Computation Attested.

The H33 Encrypted Compute Platform routes every operation to the right FHE engine automatically, measures real cost before execution, and attests every result with three independent post-quantum signature families. This is the architecture documentation.

Get API Key Back to Docs Benchmarks

What This Platform Is

The H33 Encrypted Compute Platform computes on encrypted data using fully homomorphic encryption (FHE): operations run on ciphertext and the plaintext is never exposed during processing. This is distinct from ZK (proving a fact is true without revealing it), from H33-Key (controlling how a stored secret is used), and from H33-74 (producing a portable, independently-auditable proof that an operation happened). Here the value is the computation itself, on data that stays encrypted end to end.

When to use FHE here: you need to run matching, inference, statistics, or comparisons on data you are not allowed to decrypt (biometrics, health, financial records, model inputs). When another component fits better: if you only need to prove a claim without disclosing the underlying data, use ZK; if you need to protect API keys and signing material at point of use, use H33-Key; if you need a small, portable, verifiable attestation of what ran, that role is filled by the H33-74 substrate described below.

Engine Overview

Three fully homomorphic encryption engines, each purpose-built for a distinct computation class. One API surface. The FHE-IQ router selects the engine; the caller never chooses manually.

2.2M
auth/sec sustained

BFV — Exact Integer

Polynomial arithmetic over encrypted integers. Batch biometric matching, inner products, scoring. N=4096 (fast) or N=32768 (deep). Zero approximation error. The workhorse engine for high-throughput authentication and encrypted search.

1,574
TPS · approximate real

CKKS — Approximate Real

Fixed-point arithmetic on encrypted real-number vectors. ML inference, signal processing, statistical analysis. N=8192, RNS-native. Full bootstrapping via Chebyshev polynomial evaluation. Five tuned execution profiles.

768
TPS · 8-bit comparison

TFHE — Boolean Gates

Encrypted comparisons, equality tests, and threshold decisions. The only engine that can branch, sort, and match. Linear scaling: every width doubling halves throughput. 96-channel parallelism on commodity ARM CPUs.

EngineAlgebraThroughputRing DegreePrimary UseNoise Model
BFVExact integer2.2M auth/secN=4096 / 32768Biometric matching, inner product, scoringDiscrete, bounded
CKKSApproximate real1,574 TPSN=8192ML inference, statistics, signal processingRescale-controlled
TFHEBoolean gates768 TPS (8-bit)N=1024Comparisons, equality, threshold decisionsBootstrapped per gate

FHE-IQ Routing

The FHE-IQ router inspects the operation type, data shape, and precision requirements, then selects the optimal engine with measured latency cost models. Routing overhead is under 500 nanoseconds.

FHE-IQ Decision Tree

Is the input a polynomial integer operation (add, multiply, inner product)?
   BFV    2.2M auth/sec    42 µs per auth

Is the input a real-number vector (ML features, embeddings, statistics)?
   CKKS    1,574 TPS    profile-dependent latency

Is the operation a comparison, threshold, or equality test?
   TFHE    768 TPS (8-bit)    125 ms per decision

Routing overhead: <500 ns · Measured cost models (not static) · 142 routing tests · 100 realistic scenarios

Measured, not static. FHE-IQ cost models are calibrated against actual latency measurements on the target hardware. When a new engine version deploys, cost tables update automatically. The router never guesses — it measures.

CKKS Execution Profiles

Five tuned profiles for CKKS operations. The router selects the profile based on the workload shape. Each profile adjusts modulus chain depth, rotation key pre-computation, memory allocation, and relin scheduling.

Fast
Shallow circuits, lowest latency
Batched
High slot utilization, throughput
RotationHeavy
Many rotations, hoisted keys
Precision
Deep chains, max accuracy
LowMemory
Constrained environments

CKKS Architecture Deep Dive

The CKKS engine is built for encrypted real-number computation at scale. Every design decision optimizes for throughput on ARM hardware while preserving precision invariants.

Precision contract. Every CKKS operation carries a tracked precision estimate. If accumulated approximation error would exceed the caller's declared tolerance, the operation fails explicitly rather than returning silently degraded results.

H33-74 Attestation

Every computation — regardless of engine — produces a 74-byte attestation committed to the H33-74 substrate. Three independent post-quantum signature families. The routing decision itself is included in the attestation.

ML-DSA

Module-lattice digital signature (FIPS 204). Lattice-based. Fast signing and verification. Primary attestation signature.

FALCON (FN-DSA)

NTRU-lattice signature, standardized as FN-DSA under FIPS 206 (draft). Independent mathematical hardness assumption from ML-DSA. Compact signatures.

SLH-DSA

Stateless hash-based signature (FIPS 205). Zero algebraic structure. Survives even if all lattice assumptions break simultaneously.

Attestation Flow

1. FHE-IQ routes operation to engine (BFV / CKKS / TFHE)
2. Engine executes encrypted computation
3. Routing decision + computation digest → SHA3-256 hash
4. Three-family signature bundle: ML-DSA + FALCON + SLH-DSA
5. Compressed to 74 bytes (32 on-chain + 42 Cachee)
6. Committed to H33-74 substrate (permanent, verifiable)

Patent pending — H33 substrate Claims 124-125 (batched Merkle response attestation)

Three independent mathematical bets. An attacker must break MLWE lattices, NTRU lattices, AND stateless hash functions simultaneously. Three independent hardness assumptions. Compromise of any single family does not affect the other two.

Security Posture

Measured, tested, and validated against NIST standards. Not aspirational — operational.

FIPS 203 / 204 / 205

All NIST KATs Passed

Known Answer Tests for ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). Every test vector validated. No exceptions.

FIPS 140-3

Self-Tests Operational

Power-on self-tests verify cryptographic module integrity at every startup. Continuous health checks during operation.

20,000+

Total Tests

Across all engines, routing logic, attestation, key management, and protocol layers. Correctness verified before every benchmark run.

HE Std v1.1

Compliant Parameters

All FHE parameter sets conform to the Homomorphic Encryption Standard v1.1. Ring degrees, modulus sizes, and noise budgets meet or exceed published security levels.

StandardStatusScope
FIPS 203 (ML-KEM)All KATs passedKey encapsulation for all engines
FIPS 204 (ML-DSA)All KATs passedPrimary attestation signature
FIPS 205 (SLH-DSA)All KATs passedHash-based attestation signature
FIPS 140-3Self-tests operationalModule integrity, continuous health
HE Standard v1.1CompliantBFV, CKKS, TFHE parameter sets

Developer FAQ

What does the Encrypted Compute Platform do?

It runs computations (BFV integer arithmetic, CKKS real-number arithmetic, TFHE boolean gates) directly on encrypted data. The FHE-IQ router selects the engine per operation; results are attested to the H33-74 substrate. You never hand the platform plaintext.

Which engine do I pick?

You don't — FHE-IQ routes automatically. Integer add/multiply/inner-product goes to BFV, real-number vectors to CKKS, and comparisons/equality/thresholds to TFHE. Only TFHE can branch, sort, and match on encrypted values.

What doesn't it do?

It does not prove statements without revealing data (use ZK), it does not manage secret keys at point of use (use H33-Key), and CKKS is approximate — it tracks precision and fails explicitly rather than returning silently degraded results.

How is this different from ZK?

FHE computes on ciphertext and returns an encrypted result the key-holder decrypts; ZK produces a proof that a statement is true without revealing the underlying data. Use FHE when you need the computed value on protected data; use ZK when you only need to convince a verifier of a fact.

Is the result verifiable by a third party?

Every computation, including the routing decision, is hashed (SHA3-256) and signed with three independent post-quantum families (ML-DSA, FALCON/FN-DSA, SLH-DSA), then committed as a 74-byte attestation to the H33-74 substrate. See Verification for how attestations are independently validated.

What are the compliance and maturity claims?

Parameter sets conform to HE Standard v1.1, and NIST KATs pass for FIPS 203/204/205. FALCON is standardized as FN-DSA under FIPS 206, which is still in draft. Treat compliance claims as scoped to the standards and tests listed on this page.

Verify It Yourself