Benchmarks H33 FHE H33 ZK APIs Pricing Token Docs Blog About
Log In Get API Key
🛡️ H33: 1.28ms Full Auth • 1,148,018 auth/sec • Zero Data Exposure • k-of-n Threshold • Post-Quantum • NIST L1 → L5 📜 15 Patent Claims Pending1,628 Tests Passing

Distributed trust. Post-quantum security. Million-scale throughput.📐📐 Full benchmark suite →

No single server ever sees your data.
1,148,018 auth/sec📐📐 See how we measured this → · 3-of-5 threshold decryption📐🔑 Interactive Shamir demo → · 1.28ms full auth · NIST L1 through L5 · Five proprietary crypto engines · Zero external FHE/ZK dependencies

1.28ms single authentication · 0.9µs amortized at scale · P99 under 5ms at 50,000 req/sec
Gets faster under load — not slower.📐📊 Interactive load test →

356µs
H0 (Dev)
1.28ms
5.98ms
2.2× / 12.5×
vs SEAL (single / at scale)
Zero Exposure
Guaranteed
Blink Test:📐⚡ The blink test → 300ms blink ÷ 1.28ms = ~234 full crypto auths per blink📐⚡ The blink test →. The only auth where your biometric is NEVER decrypted.

Performance Modes v7.0

Mode Latency Security NIST Level
H0 356µs ~57-bit Dev Only
H33-128 ⭐ 1.28ms Zero Exposure
H-256 ✓ 5.98ms Zero Exposure

H0 (N=1024) dev only (~57-bit). H33-128 and H-256 are NIST-compliant:📐🔒 NIST security levels → H33-128 (N=4096) NIST L1 128-bit; H-256 (N=16,384) NIST L5 256-bit.

H0 Dev Mode (356µs) — Dev Only

Encrypt + inner product + single-party decrypt + ZKP Stark Lookup + Dilithium.

BFV Encrypt (N=1024) ~130µs 37%
FHE Inner Product ~48µs 13%
Decrypt (single-party) ~33µs 9%
ZKP Stark Lookup + Dilithium ~145µs 41%
TOTAL 356µs 100%

H33-128 CollectiveAuthority (1.28ms) — 128-bit NIST L1📐🔒 NIST security levels → FHE + Zero Exposure

0.42ms 33%
FHE Inner Product + Rotations 0.26ms 20%
0.33ms 26%
2.0µs <1%
H33 ZKP Stark Lookup Verify 0.2µs <1%
80.7µs 6%
24.8µs 2%
Encode / Normalize / Other ~0.12ms 9%
TOTAL PIPELINE 1.28ms Zero Exposure

H-256 CollectiveAuthority (5.98ms) — 256-bit NIST L5📐🔒 NIST security levels → + Zero Exposure

BFV Encrypt (N=16384, Q=216) ~1.5ms 25%
FHE Inner Product + Rotations ~3.2ms 53%
~1.4ms 23%
2.0µs <1%
H33 ZKP Stark Lookup Verify 0.2µs <1%
80.7µs 1%
24.8µs <1%
TOTAL PIPELINE 5.98ms Zero Exposure
H33 ZKP Stark Lookup: 2.0µs prove + 0.2µs verify📐🛡️ STARK lookup breakdown → | Cached Verify: 2.09ns (Cachee L1)📐🏎 Cachee L1 cache engine →
128-bit post-quantum. No trusted setup. 497M ops/sec cached throughput.
vs SEAL (N=4096): H33 1.28ms vs SEAL 2.85ms = 2.2× faster pipeline + zero exposure

Measured on c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2). Criterion.rs v0.5, 100+ samples. February 14, 2026.
Note: H33/H2 upgraded to N=4096 for NIST L1 compliance. Latencies being re-benchmarked.

full-stack-auth.js
// Ship quantum-resistant auth this afternoon const result = await h33.auth.verify({ userId: 'user_123', biometric: faceData // H33-128 default: 1.28ms, 128-bit NIST L1 FHE, zero exposure }); // Maximum security? One parameter. const secure = await h33.auth.verify({ userId: 'user_123', biometric: faceData, mode: 'h-256' // n=16,384, Q=216 → TRUE 256-bit NIST L5 ✓ });
Architecture

The Stack Is Ours.

Five proprietary cryptographic engines. Three FHE libraries. All H33. Zero external dependencies.

Every engine built from scratch — not forked, not wrapped, not dependent on Microsoft SEAL, OpenFHE, TFHE-rs, Concrete, arkworks, or any other library.

H33 BFV

Complete BFV homomorphic encryption. NTT, Montgomery arithmetic, SIMD batching📐📊 SIMD batch amortization →, 3-of-5 threshold decryption📐🔑 Interactive Shamir demo →. Production default.

1.28ms full auth pipeline
2.2× faster than SEAL
N=4096 · Q=56-bit single modulus📐🔧 Single-modulus explainer →
Proprietary FHE Engine

H33 BFV-256

Military-grade BFV for maximum security applications. Multi-limb RNS, full 256-bit lattice security. Still faster than SEAL at any parameter set.

5.98ms full auth pipeline
3.2× faster than SEAL (19.08ms)
N=16384 · Q≤438-bit multi-limb
192-bit security also available
Proprietary FHE Engine

H33 CKKS

L1–L5 · APPROXIMATE ARITHMETIC

Floating-point homomorphic encryption. Compute on encrypted real numbers. Chebyshev bootstrapping, fused dot product, scheme switching.

5 operations SEAL can't do
BFV↔CKKS scheme switching
Lazy multiply + accumulate
128–256 bit PQ security
Proprietary ZK Engine
128-BIT POST-QUANTUM · SHA3-256

Proprietary zero-knowledge lookup proof system. Transparent — no trusted setup. Quantum-resistant via SHA3-256 hash commitments.

No trusted setup required
Proprietary Biometric Engine

H33 Biometrics

L1–L5 · ENCRYPTED MATCHING

Multi-modal fusion pipeline. Face, voice, fingerprint, keystroke, mouse dynamics. LSTM behavioral modeling. All matching on encrypted data.

99.2% attack detection rate
5 biometric modalities
Liveness + anti-spoofing
5
Proprietary Engines
3
FHE Libraries
0
External FHE/ZK Deps
2.2–3.2×
Faster Than SEAL

*Only external crypto dependency: Dilithium3 (pqcrypto-mldsa) — NIST FIPS 204 reference implementation. Using the standard is the right call for a signature algorithm.

Performance

1.28ms Full Auth. Zero Data Exposure. k-of-n Threshold.

Measured on c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2). Criterion.rs, 100+ samples. February 14, 2026 | v7.0

🛡️
H33-128 (Zero Exposure)
1.28ms
🔐
H-256 (Max Mode)
5.98ms
N=16,384, NIST L5 ✓
H0 Mode
356µs
Full pipeline (dev only)
🔐
🚀
vs SEAL (single-thread)
2.2×
pipeline with full zero-exposure stack
🚀
At Scale (Graviton4)
1.28ms full post-quantum authentication with zero data exposure
H33-128 CollectiveAuthority: FHE matching in encrypted space + k-of-n threshold decrypt + H33 ZKP Stark Lookup (2.0µs prove, 0.2µs verify) + Dilithium sign+verify. Your biometric is NEVER decrypted on any single server.
2.2× / 12.5×
faster than SEAL (single / at scale)
In that time, H33 can complete ~234 full crypto auths📐⚡ The blink test → (1.28ms each), or ~143 million proof lookups (2.09ns Cachee L1 hit).
Speed Comparison

H33 vs Microsoft SEAL 4.1.2 — Fair Head-to-Head

Same security level. Same BFV scheme. Same biometric operation. SEAL gets pre-generated Galois keys and single-key decrypt. H33 includes 3-of-5 threshold decrypt📐🔑 Interactive Shamir demo → + ZK proof + Dilithium signature. H33 does more. H33 is still faster.

N=4096, 128-bit Security (NIST L1)

Operation SEAL 4.1.2 H33 BFV Speedup
Encode 0.04ms <0.01ms
Encrypt 0.53ms 0.42ms 1.3×
Compute (inner product) 2.13ms 0.26ms 8.2×
Decrypt 0.15ms 0.33ms 0.5×*
Pipeline total 2.85ms 1.28ms 2.2×
Auth/sec (single thread) 350 781 2.2×
Auth/sec (96-core Graviton4) 12.5×

N=16384, 256-bit Security (NIST L5)

Operation SEAL 4.1.2 H33 BFV Speedup
Encode 0.18ms <0.01ms
Encrypt 2.58ms ~1.5ms 1.7×
Compute (inner product) 15.49ms ~3.2ms 4.8×
Decrypt 0.84ms ~1.4ms 0.6×*
Pipeline total 19.08ms 5.98ms 3.2×
Auth/sec (single thread) 52 167 3.2×

*H33 decrypt is intentionally slower: 3-of-5 threshold decryption📐🔑 Interactive Shamir demo → means no single server ever sees plaintext. SEAL uses single-key decrypt where one server holds the full secret key.

At production scale on Graviton4 (96 cores, 32-user SIMD batching📐📊 SIMD batch amortization →), H33-128 sustains 1,148,018 auth/sec — 12.5× SEAL's single-thread pipeline rate. SEAL has no equivalent multi-core benchmark because it was not designed for this workload.

3.2× faster + zero exposure

Why the difference? SEAL is a general-purpose FHE library. H33 is purpose-built for authentication: shallow circuits, aggressive batching, no relinearization needed. Same BFV scheme, same security — just optimized for one use case.

Individual Component Breakdown (v7.0)

Component H33 Alternative Notes
0.42ms SEAL: 0.55ms 1.3× faster (single-modulus)
FHE Inner Product (encrypted match) 0.26ms SEAL: 0.83ms 3.2× faster. Purpose-built vs general.
Threshold Decrypt (k-of-n Shamir) 0.33ms SEAL: 0.21ms (single-party) H33 adds zero-exposure threshold.
H33 ZKP Stark Lookup (prove + verify) ~2.2µs 2.0µs prove + 0.2µs verify
H33-128 Full Auth (CollectiveAuthority) 1.28ms SEAL: 2.85ms 2.2× faster + zero data exposure.
5.98ms SEAL: 19.08ms 3.2× faster + zero data exposure.
H33 ZKP Stark Lookup 2.0µs prove + 0.2µs verify 2.09ns cached (Cachee L1) PQ-safe. No trusted setup. 497M ops/sec cached.

Measured on c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2). Criterion.rs v0.5, 100+ samples. February 14, 2026. 96-core single-socket, NUMA-pinned for throughput numbers.

Why H33

1.28ms. Zero Data Exposure. Post-Quantum.

The only biometric auth where your template is NEVER decrypted. H33-128 CollectiveAuthority uses k-of-n threshold decrypt📐🔑 Interactive Shamir demo → so no single server ever sees plaintext. H33 ZKP Stark Lookup: 2.0µs prove + 0.2µs verify. 2.2× faster than Microsoft SEAL (single-thread).

1.28ms
H33-128 Full Auth
0.42ms
BFV Encrypt (N=4096)
2.2×
vs SEAL (single-thread)
Capability H33 (Feb 2026 v7.0) Industry Best H33 Advantage
H0 Mode (Turbo Full Match) 356µs No comparison ~57-bit security (dev only)
H33-128 (CollectiveAuthority, N=4096) 1.28ms SEAL: 2.85ms 2.2× faster + zero exposure
5.98ms SEAL: 19.08ms 3.2× faster + zero exposure
H33 ZKP Stark Lookup 2.0µs prove + 0.2µs verify 2.09ns cached (Cachee L1) 497M ops/sec. PQ-safe.
Auths Per Blink N/A
Throughput (96-core Graviton4) 1,148,018/sec No comparable offering 99.2B/day • 12.5× SEAL at scale
PQC Overhead ~106µs N/A Dilithium3 sign 80.7µs + verify 24.8µs
Cache Read Throughput 497M ops/sec ~100K/sec typical Cachee L1, Rust-native, 2.09ns

Measured on c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2). Criterion.rs v0.5, 100+ samples. February 14, 2026. 96-core single-socket, NUMA-pinned for throughput numbers.

Cryptographic Specifications

Every authentication is protected by formally verified, standards-compliant cryptographic primitives.

🔐

FHE: BFV Scheme

Scheme: Brakerski/Fan-Vercauteren
Ring Dimension: N = 4,096 (H33/H2 NIST L1)
Coefficient Modulus: Q = 56 bits (single-modulus BFV)📐🔧 Single-modulus explainer →
Plaintext Modulus: t = 65,537 (H33/H2/H-256)
🔑

Kyber768 (ML-KEM)

Standard: FIPS 203
Security Level: NIST Level 3 (AES-192)
Public Key: 1,184 bytes
Ciphertext: 1,088 bytes
Encap + Decap: 41µs
✍️
Standard: FIPS 204
Security Level: NIST Level 3 (AES-192)
Public Key: 1,952 bytes
Signature: 3,309 bytes
Sign + Verify: ~106µs (sign 80.7µs + verify 24.8µs)
🔐

ZK: H33 ZK LOOKUP PRODUCTION

Mechanism: H33 ZKP Stark Lookup (proprietary)
Prove: 2.0µs
Verify: 0.2µs / 2.09ns (Cachee L1 cached)
Post-Quantum: Yes (hash-based, no trusted setup)

H33 ZKP Stark Lookup Production v7.0

H33 ZKP Stark Lookup for production auth. 128-bit post-quantum. No trusted setup. 2.09ns cached verify via Cachee L1.

2.0µs
ZKP Stark Lookup Prove
0.2µs
ZKP Stark Lookup Verify
1.28ms
H33 Full Auth
497M ops/sec
Cached Sessions
Full Security Parameters Appendix v4.0 →
API Services

H33 BFV, H33 BFV-256, H33 CKKS, H33 ZKP Stark Lookup, H33 Biometrics — every engine built from scratch in Rust📐⚙️ Proprietary engine deep-dive →. One API call for the entire post-quantum stack.

🧬
FHE Biometrics
Face, voice, fingerprint matching on encrypted data. k-of-n threshold decrypt📐🔑 Interactive Shamir demo →. 0.42ms BFV encrypt + 0.26ms FHE inner product. 2.2× faster than SEAL (single-thread) + zero exposure.
POST /biometric/enroll POST /biometric/verify POST /auth/incremental
NEW
🔢
CKKS FHE
Floating-point homomorphic encryption. Compute on encrypted real numbers. 128/192/256-bit security levels.
POST /fhe/ckks/keygen POST /fhe/ckks/encrypt POST /fhe/ckks/decrypt POST /fhe/ckks/add POST /fhe/ckks/multiply POST /fhe/ckks/rescale POST /fhe/ckks/similarity
🔒
Zero-Knowledge Proofs
H33 ZKP Stark Lookup: 2.0µs prove + 0.2µs verify. Prove identity, age, location without revealing data. 2.09ns cached verify (Cachee L1).
POST /zkp/prove POST /zkp/verify
🔐
Dilithium3 & Kyber768. NIST FIPS 203/204 compliant. ~106µs sign+verify📐✍️ Batch attestation demo → (80.7µs sign + 24.8µs verify). NIST L3 post-quantum.
POST /crypto/dilithium/keygen POST /crypto/dilithium/sign POST /crypto/dilithium/verify
NEW
🦅
Falcon Signatures
FALCON-512/1024 lattice-based signatures. NIST FIPS 206 compliant. Compact signatures (666 bytes). NIST L1/L5.
POST /crypto/falcon/keygen POST /crypto/falcon/sign POST /crypto/falcon/verify
⛓️
Blockchain Attestation
Solana soulbound NFTs. Immutable audit trails. ZK-compressed logging (5000x less expensive).
POST /blockchain/attest POST /blockchain/mint-sbt
COMING SOON
👻
Invisible Auth
Zero-transmission authentication. No codes displayed. Hardware-secured invisible keys. Zero-knowledge registration.
POST /auth/invisible-handshake POST /auth/session
PATENT
🛡️
Estate Fraud Detection
Behavioral shift detection from deceased baselines. Beneficiary collusion detection. Court-admissible evidence.
POST /fraud/estate/analyze GET /fraud/evidence
🏛️
KYC / AML
Privacy-preserving identity verification. ZK proofs of eligibility without exposing documents.
POST /kyc/verify POST /aml/screen
🧠
Continuous Auth
Multi-modal fusion: keystroke, mouse, face, voice. LSTM behavioral modeling. 99.2% attack detection.
WS /auth/continuous POST /auth/behavioral
📜 15 Patent Claims Pending

7 Core Innovations

Protected intellectual property covering the complete post-quantum authentication stack.

1
Two complete FHE implementations built from scratch. BFV for authentication (2.2× SEAL single-thread), CKKS for encrypted computation. Scheme switching, fused ops, SIMD batching.
2
H33 ZKP Stark Lookup — Proprietary Zero-Knowledge
H33 ZKP Stark Lookup: 2.0µs prove + 0.2µs verify. 128-bit post-quantum, no trusted setup. 2.09ns cached verify (Cachee L1).
3
Continuous Multi-Modal Fusion
LSTM temporal modeling. Keystroke, mouse, face, voice, physiological signals. 94.7% accuracy.
4
Quantum-Resistant Architecture
Kyber, Dilithium, FALCON with automated migration. 30+ year quantum resistance.
5
Estate Fraud Detection
Behavioral shift analysis from deceased baselines. Collusion detection. Legal evidence generation.
6
ML Threat Attribution
Ensemble classification for attack source identification. Campaign tracking. 89-95% accuracy.
7
Blockchain Compliance
Smart contracts for GDPR/HIPAA. ZK-compressed logging. 5000x cost reduction.
+
Invisible Authentication
Zero-transmission auth. Hardware-secured keys. Zero-knowledge registration.
✓ Cancel anytime • Included auths per month • Annual: 2 months free

Monthly subscription pricing

Per-auth pricing. Upgrade or downgrade anytime. Annual plans get 2 months free (~17% off).

Free
$0
1,000 auths/mo
50 H33 auths/mo
All APIs
H0 mode only
5 req/sec
Production use
Starter
$349/mo
5,000 auths/mo
500 H33 auths/mo
All tiers (H0-H256)
10 req/sec
Email support
Webhooks
Business
$2,499/mo
50,000 auths/mo
5,000 H33 auths/mo
200 req/sec
99.9% SLA
20 API keys
4hr support
Growth
$6,999/mo
175,000 auths/mo
15,000 H33 auths/mo • 500 req/sec
Scale
$17,999/mo
500,000 auths/mo
40,000 H33 auths/mo • SOC 2
Enterprise
$49,999/mo
1.5M auths/mo
125K H33 auths/mo • Dedicated AM
Enterprise+
$119,999/mo
5M auths/mo
500K H33 auths/mo • Premium SLA

Security Level Surcharges

Higher security levels add a per-auth surcharge
Tier Surcharge Latency Description
H0 ⚠️ Base 356µs Dev only (~57-bit)
H33-128 ⭐ +$0.01 1.28ms Zero exposure flagship (NIST L1)
H-256 ✓ +$0.02 5.98ms NIST L5 + k-of-n threshold

KYC / Identity (Fixed Pricing)

$49
KYC Basic + SBT
ID, Selfie, Liveness, Soulbound NFT mint
$79
KYC Enhanced + SBT
+ Proof of Address verification
$19
AML/PEP Screening
Sanctions, PEP, Adverse Media
$99
Full Bundle
KYC + AML + Soulbound NFT

All KYC includes: FHE-encrypted biometrics, ZK proof, quantum signatures, Solana soulbound NFT.

Security

Enterprise-grade. Formally verified.

Post-quantum cryptography, 16 mathematical proofs, 7 defense layers. Security that doesn't slow you down.

9.9/10
Internal Security Assessment
View Testing Methodology →
0
Critical Vulns
16
Kani Proofs
7
Defense Layers
99.2%
Attack Detection

7-Layer Defense in Depth

Layer 7: Post-Quantum Cryptography Dilithium3 + Kyber768 • NIST Level 3
Layer 6: Zero-Knowledge Proofs H33 ZKP Stark Lookup • Privacy without exposure
Layer 5: Homomorphic Encryption BFV/CKKS • Compute on encrypted data
Layer 4: Hardware Security (TEE) Intel SGX • Fortanix EDP
Layer 3: Formal Verification 16 Kani Proofs • Mathematical guarantees
Layer 2: Network Security WAF • DDoS • mTLS • Segmentation
Layer 1: Infrastructure AWS • VPC • IAM • CloudTrail

Compliance Ready

🏥
HIPAA
🇪🇺
GDPR
📊
SOC 2
💳
PCI DSS
🔒
ISO 27001
🏛️
FedRAMP
Benchmarks

Real-world performance. Independently verifiable.

All benchmarks on c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2, ARM NEON, bare metal). Criterion.rs v0.5, 100+ samples. February 14, 2026.

Instance
c8g.metal-48xl (Graviton4)
96 cores • Neoverse V2 • ARM NEON
Full Crypto Auth

H33 CollectiveAuthority Pipeline (AWS Graviton4)

📐✍️ Batch attestation demo →
OperationLatencyNotes
0.42ms33% of pipeline
FHE Inner Product0.26msMatching in encrypted space
0.33msZero exposure
Encode / Normalize / Other~0.12msResult finalization
~2.2µs2.0µs prove + 0.2µs verify

Quantum-Resistant Full Stack Benchmarks v7.0

FHE (BFV) + ZKP Stark Lookup + Biometrics + Kyber768 + Dilithium3
📐🏎 Cachee L1 cache engine →
InstanceRequest TypeLatencyThroughput
Production ARMH33-128 Full Auth1.28ms1,148,018/sec
Production ARMH33-128 Cold Start2.7ms
Production ARMH-256 Full Auth5.98ms
PQC Operations: Dilithium3 ~106µs (sign 80.7µs + verify 24.8µs) • H33 ZKP Stark Lookup ~2.2µs (prove 2.0µs + verify 0.2µs)
Cached ZK Verify: 2.09ns (Cachee L1), 497M ops/sec • Daily Capacity: 99.2B/day

Worker Scaling

WorkersAuth/secScalingPer-Auth
17811.28ms
86,1007.8×0.16ms
1611,90015.2×84µs
3223,20029.7×43µs
4834,10043.7×29µs
961,148,0181,470×~0.9µs

FHE Authentication v7.0

TierWarm LatencyCold LatencyThroughput
H0 (Turbo Full Match, dev only)356µs~420µs~2,800/sec
H33-128 (CollectiveAuthority) ⭐1.28ms2.7ms1,148,018/sec
5.98ms~8ms
OperationLatency
Sign80.7µs
Verify24.8µs
Full Cycle (Sign + Verify)~106µs
Documentation

API Reference

Complete API documentation for H33's post-quantum authentication platform. Base URL: https://api.h33.ai/v1

Authentication Full Stack Auth Biometrics FHE Zero-Knowledge Quantum Signatures Blockchain KYC/AML Errors

Authentication

All API requests require authentication using your API key in the Authorization header.

HTTP Header
Authorization: Bearer h33_live_xxxxxxxxxxxxxxxxxxxx
ℹ️
API Key Types
h33_live_* - Production keys, full access
h33_test_* - Test keys, sandbox environment (no auths consumed)

Full Stack Auth PATENT PENDING

One API call: biometric + FHE + ZK proof + quantum signature + blockchain attestation.

Biometric APIs

FHE-encrypted biometric enrollment and verification. We never see or store raw biometric data.

POST /biometric/enroll

Enroll a new biometric template (face, voice, fingerprint). Encrypted with FHE before storage.

1 auth
H0
1 auth
H33
POST /biometric/verify POPULAR

Verify biometric against enrolled template. Matching performed entirely on encrypted data.

1.28ms
H33-128 (Zero Exposure)
1 auth
H33

FHE Encryption

Fully Homomorphic Encryption - compute on encrypted data without decrypting.

Mode Latency FHE Security Use Case
H0 356µs ~57-bit ⚠️ Dev/testing only
H33-128 ⭐ 1.28ms 128-bit NIST L1 + Zero Exposure Production default (k-of-n)
H-256 ✓ TBD 256-bit NIST L5 + Zero Exposure NIST L5 (n=16,384) — highest tier
POST /fhe/encrypt

Encrypt data using FHE. Supports BFV (integers) and CKKS (floating point) schemes.

0.42ms
BFV Encrypt
1 auth
H33
POST /fhe/compute

Perform operations on encrypted data: addition, multiplication, comparison, Euclidean distance.

0.26ms
FHE Inner Product

Zero-Knowledge Proofs

Prove statements without revealing underlying data. H33 ZKP Stark Lookup for production auth. 128-bit post-quantum. No trusted setup.

Scheme Proof Size Verify Time Notes
H33 ZKP Stark Lookup (Production) 0.2µs (2.09ns cached) Prove: 2.0µs, PQ-safe, no trusted setup
KZG ~200 bytes ~3ms Biometric ZKP commitment scheme
IPA ~1KB ~10ms No trusted setup, biometric ZKP
POST /zkp/prove

Generate a ZK proof. H33 ZKP Stark Lookup for production auth. Prove age, location, credentials without revealing data.

2.0µs
ZKP Stark Lookup Prove
~180KB
Proof Size
POST /zkp/verify

Verify a ZK proof. H33 ZKP Stark Lookup verification in 0.2µs or 2.09ns (Cachee cached). Returns true if proof is valid.

0.2µs
ZKP Stark Lookup Verify
2.09ns
Cachee Cached

Quantum Signatures

NIST FIPS 203/204 compliant post-quantum digital signatures. Dilithium3: ~106µs sign+verify (80.7µs sign + 24.8µs verify).

🔐
Algorithms Supported
CRYSTALS-Dilithium - Primary (FIPS 204) • CRYSTALS-Kyber - Key encapsulation (FIPS 203) • FALCON - Compact signatures
POST /quantum/sign

Sign data using Dilithium3 (NIST Level 3) quantum-resistant algorithm.

~80.7µs
Sign
1 auth
Per call
POST /quantum/verify

Verify a quantum-resistant signature.

24.8µs
Verify
~106µs
Full Cycle

Blockchain Attestation

Immutable records on Solana. ZK-compressed logging (5000x less expensive than raw transactions).

POST /blockchain/attest

Create immutable attestation record. Perfect for audit trails and compliance.

~400ms
Confirmation
1 auth
Cost
POST /blockchain/mint-sbt

Mint a Soulbound Token (non-transferable NFT) for verified identity credentials.

Solana
Network

KYC / AML

Privacy-preserving identity verification with Soulbound NFT issuance.

Package Price Includes
KYC Basic + SBT $49 ID + Selfie + Liveness + Soulbound NFT
KYC Enhanced + SBT $79 Basic + Proof of Address
AML/PEP Screening $19 Sanctions, PEP, Adverse Media
Full Bundle $99 KYC + AML + Soulbound NFT
POST /kyc/verify
JavaScript
const kyc = await h33.kyc.verify({ userId: 'user_123', package: 'full_bundle', // $99 documents: { idFront: idBase64, selfie: selfieBase64 }, walletAddress: 'Gh9ZwE...' // For SBT mint }); // { status:"verified", amlClear: true, zkProof:"0x...", sbtMint:"H33sbt..." }

Error Codes

All API errors return a consistent JSON structure.

Error Response
{ "error": { "code": "QUOTA_EXCEEDED", "message": "Monthly auth quota exceeded" } }
Code HTTP Description
INVALID_API_KEY 401 API key is missing, invalid, or revoked
QUOTA_EXCEEDED 402 Auth quota exceeded for this billing period
RATE_LIMITED 429 Too many requests, slow down
USER_NOT_ENROLLED 404 No biometric template found for user
PROOF_INVALID 400 ZK proof verification failed

Rate Limits

Tier Requests/sec Requests/day
Trial 10 1,000
Starter 10 10,000
Growth 100 100,000
Business+ 500+ Unlimited
SDKs

Native SDKs for every stack

Official client libraries with TypeScript definitions, async/await support, and automatic retries.

Node.js / TypeScript
npm install @h33/client
Python
pip install h33
Go
go get github.com/h33-ai/h33-go
Rust
cargo add h33
React Native
npm install @h33/react-native

Ship military-grade post-quantum encryption this afternoon.

We solved the hard part. 1,000 free auths. Full API access. No credit card required.

Get Free API Key → View Pricing →

Why Quantum Computing Changes Everything

Your current encryption (RSA-2048, ECDSA):

Classical Computer
300 trillion years to break
Quantum (4,000 qubits)
~10 seconds

Shor's algorithm breaks every RSA key, every ECDSA signature, every TLS handshake.

"Harvest Now, Decrypt Later"

Nation-states are recording encrypted traffic TODAY. When quantum arrives, they decrypt everything retroactively.

  • Your 2024 trade secrets
  • Your 2025 M&A communications
  • All exposed.

Timeline

2024: NIST finalizes post-quantum standards ✓
2025-2026: Federal transition mandates begin
2028-2032: Cryptographically relevant quantum expected
2030+: Everything encrypted before transition = compromised

NIST Post-Quantum Cryptography Standards

NIST (National Institute of Standards and Technology) sets cryptographic standards for U.S. government and enterprise.

August 2024 Standards:

FIPS 203ML-KEM (Kyber)Key Exchange
FIPS 204ML-DSA (Dilithium)Signatures
FIPS 202SHA-3Hash Functions

Three NIST-Compliant Tiers ✓

H2 & H33 (N=4096) → 128-bit NIST L1. bfv_params_override ensures Q ≤ HE Standard max.
H-256 (N=16,384) → 256-bit NIST L5. Q=216 bits within HE Standard max of 237 bits.

H0: Non-NIST Dev Tier

H0 (N=1024) dev only (~57-bit). Turbo Full Match: 356µs. Includes H33 ZKP Stark Lookup + Dilithium.

H33/H-256 Zero Exposure:

Biometric NEVER decrypted on any single server. k-of-n threshold decrypt. Dilithium3/Kyber768 = NIST Level 3.

The Math Behind H33

H33-128 FULL AUTH (CollectiveAuthority): 1.28ms

📐✍️ Batch attestation demo →
ComponentTime%
0.42ms33%
FHE Inner Product0.26ms20%
0.33ms26%
Encode / Normalize / Other~0.12ms9%
~2.2µs<1%
TOTAL PIPELINE1,280µs (1.28ms)100%

Single-thread benchmark. Criterion.rs v0.5, 100+ samples. February 2026. H33 ZKP Stark Lookup: 2.0µs prove + 0.2µs verify. Cached verify: 2.09ns (Cachee L1). Zero data exposure: template NEVER decrypted on any single server.

⚡ vs SEAL — N=4096, Single-Thread

OperationH33SEALAdvantage
Encrypt0.42ms0.55ms1.3× faster
FHE Inner Product0.26ms0.83ms3.2× faster
Threshold Decrypt0.33ms0.21ms (single-party)H33 adds threshold
Full Auth Pipeline1.28ms2.85ms2.2× faster
Zero Data Exposure✓ k-of-n

🔧 vs DIY Cobbled Stack

H33DIYAdvantage
Full Auth1.28ms200-900ms156-703×
First Auth5.98ms1.4-4.2s234-702×
Vendors14-6
Integration1 afternoon6-12 months
Zero Exposure
Source: Criterion.rs v0.5, c8g.metal-48xl (96 cores, AWS Graviton4, Neoverse V2). February 14, 2026 | v7.0
Full Benchmark Report →

Performance Benchmarks

Production ARM Hardware · February 2026
0 auth/sec sustained
60-second sustained test. Zero degradation over test duration.
Optimization Journey
SIMD Multiplier
35.9×
32 users per FHE operation
Total Improvement
79.7×
from initial baseline
Total (60s test)
68.9M
authentications
Latency decreases as load increases — SIMD batches fill faster under pressure
Rate
P50 Latency
P50
P95
P99
Single Auth (Unbatched)
1.28ms
Amortized at Scale
0.9µs
Auth/sec
Daily Capacity
99.2B
per cluster
Yearly Volume
36.2T
authentications
What 1,148,018/sec means for your organization
Regional bank500K customers
All daily logins in 0.4 seconds
500K
National health system50M patients
Every daily authentication in 44 seconds
50M
Global payments network4B cardholders
Every transaction in under 58 minutes
4B
US financial systemEvery bank, every credit union
~1B daily auths → 25 minutes
1B
Every number on this page is a measured result from production hardware, not a projection or theoretical estimate.
Hardware
Production ARM server (AWS)
Multi-core, DDR5, no SMT
Production-tuned configuration
Software
Rust 1.93 stable, release build with LTO
ARM NEON SIMD, jemalloc allocator
BFV fully homomorphic encryption (N=4096, 128-bit security)
32-user SIMD packing via CRT batching slots
Test Conditions
60-second sustained throughput (no warmup cherry-picking)
Multi-worker, production configuration
1,366,510 total requests for latency distribution
Zero fallbacks — 100% batch path utilization
Verification
1,628 unit tests passing
300,000 randomized property tests (proptest)
Noise budget validated across full embedding distribution
Criterion.rs statistical benchmarks with 95% confidence intervals
Live simulation — drag the slider

Gets faster under load —
not slower.

Most systems degrade as traffic increases. H33 uses 32-slot SIMD batching — more users means fuller batches, which means less wasted compute per authentication.

Incoming auth requests 5,000 req/sec
100 10K 50K 100K 500K 1.15M
Per-Auth Latency
12.4
µs / auth
Batch Fill Rate
15%
of 32 slots
Throughput
5,000
auth / sec
Wasted Compute
85%
empty slots
Typical batch at current load 5 of 32 filled
Active auth
Empty slot
Wasted compute
Per-auth latency vs. load Traditional ↗ · H33 ↘

Traditional: degrades under load

Each request gets its own thread, its own encryption, its own key operations. More users = more contention = higher latency. Queues build. Timeouts start. P99 explodes.

H33: improves under load

32 users share one SIMD batch — one encrypt, one FHE inner product, one threshold decrypt. More users = fuller batches = less wasted compute per auth. Latency drops from ~44µs at idle to 0.9µs at capacity.

Measured on Graviton4 c8g.metal-48xl · 96 workers · 60s sustained
Batch cost is fixed at ~1,375µs regardless of fill level.
At 1 user/batch: 1,375µs per auth. At 32 users/batch: 43µs per auth. At 96 workers × 32 users: 0.9µs amortized.
The FHE operation costs the same whether the batch has 1 user or 32. Fill the batch, divide the cost.
Measured · 60 seconds sustained · Graviton4

1,148,018 authentications per second.

Full post-quantum pipeline on every single auth. FHE encrypt, biometric match, 3-of-5 threshold decrypt, ZK proof, Dilithium signature. Not a synthetic benchmark — sustained production throughput.

0
authentications / second
Drag the slider below to see how throughput scales with workers
Worker allocation (96 available) 96 active
Workers: 96
Throughput
1.15M
auth/sec
Per-Auth
0.9µs
amortized
Batch Size
32
users/batch
Daily Capacity
99.2B
auths/day
Efficiency
100%
vs linear
Throughput scaling curve — workers vs auth/sec Near-linear to 96 cores
Full authentication pipeline — 1.28ms single-thread
BFV Encrypt
0.42ms
33%
FHE Compute
0.26ms
20%
Threshold Decrypt
0.33ms
26%
ZK Proof
2.2µs
<1%
Dilithium
106µs
8%
✓ Auth
1.28ms
total

32-User SIMD Batching

Each worker packs 32 biometric templates into one SIMD vector. One FHE operation processes all 32 simultaneously. The batch costs 1,375µs regardless of fill level.

1,375µs ÷ 32 = 43µs per user per worker
🔩

96 NUMA-Pinned Workers

Graviton4 c8g.metal-48xl: 192 vCPUs, 96 physical cores. Each worker pinned to its own core with dedicated L1/L2 cache. Zero cross-NUMA traffic.

96 workers × ~11,958 auth/sec each
📋

Batch Attestation

Instead of signing each auth individually (164µs × 32 = 5,248µs), one Dilithium signature covers the entire batch. Amortized to 7.4µs per auth.

32× Dilithium reduction → 7.4µs/auth
🗃

H33-128 uses a single 56-bit coefficient modulus — the minimum needed for one multiply-plain-accumulate. No relinearization. No modulus switching.

Hardware: AWS c8g.metal-48xl · Graviton4 · 192 vCPUs · 96 physical cores
Config: 96 workers · NUMA-pinned · 32-user SIMD batching · batch attestation
Result: 1,148,018 auth/sec sustained over 60 seconds · 1,628 tests passing
FHE-only baseline: 1,291,207 auth/sec · Full stack with attestation: 1,148,018 auth/sec
Daily capacity: 99.2 billion auths/day (2× c8g.24xlarge instances) · Cost: $0.0019 per million auths
FHE Parameter Optimization · Why H33 is faster

Q = 56 bits. One prime. No wasted work.

SEAL uses a 109-bit modulus chain with 4 primes — designed for deep circuits with many multiplications. H33 uses a single 56-bit prime — the minimum needed for one biometric match. Everything SEAL carries for circuit depth it never uses here is pure overhead.

Coefficient modulus Q — the biggest performance lever in FHE
Microsoft SEAL N=4096 Default
60q₀
×
40q₁
×
40q₂
×
60special
Q ≈ 109 bits
4 NTT-friendly primes · HE Standard max for N=4096
⚙️4 separate NTT transforms per polynomial operation
🔁Relinearization required after each ciphertext multiply
📉Modulus switching to manage noise after operations
🗄️Relinearization keys: ~4× ciphertext size in memory
H33 BFV Engine N=4096 Auth
56 q₀ (only)
Q = 56 bits
1 NTT-friendly prime · Minimum for auth circuit
1 NTT transform — 4× fewer butterfly operations
🚫No relinearization — circuit too shallow to need it
🚫No modulus switching — single prime, nothing to switch
💾No relin keys in memory — smaller working set, better cache
Why one prime is enough — the auth circuit is shallowDepth = 1
E(template)
encrypted
multiply
plain
accumulate
(add)
E(distance²)
still encrypted
relin
✗ never
reached
mod
switch
Biometric authentication computes Euclidean distance: D² = Σ(aᵢ − bᵢ)². This requires one multiply-plain and one accumulate — a circuit of multiplicative depth 1. SEAL's 4-prime modulus chain supports depth 3+. The extra 2+ levels of depth capacity are carried as overhead in every single NTT, every key generation, every encrypt — but never used.
NTT cost — the heart of every FHE operation4× fewer butterflies

SEAL: 4-Prime RNS

Each polynomial op runs 4 independent NTTs
q₀ q₁ q₂ q₃
4
NTTs/op
49,152
Butterflies
109
Q bits

H33: Single-Prime

One NTT transform per polynomial operation
q₀ (only)
1
NTT/op
12,288
Butterflies
56
Q bits
Where the time goes — operation-by-operationN = 4,096
OperationSEAL (Q=109)H33 (Q=56)SavingsWhy
Key Generation
Create public/secret/relin keys
~2.1ms~0.4ms5.3×No relin keys needed. 1 NTT vs 4.
Encrypt
Plaintext → ciphertext
0.68ms0.42ms1.6×Smaller Q → smaller polynomials → faster NTT
Multiply (ct × pt)
Core distance computation
1.53ms0.26ms5.9×1 NTT vs 4 RNS channels. No noise management.
Relinearize
Key-switch after multiply
0.49msELIMINATEDDepth-1 circuit → no relin needed
Modulus Switch
Drop prime to manage noise
~0.15msELIMINATED1 prime → nothing to switch
Decrypt
Ciphertext → plaintext
0.15ms0.33ms0.45×H33 uses 3-of-5 threshold (slower but zero exposure)
FHE Pipeline Total2.85ms1.28ms2.2×H33 includes ZK + Dilithium. SEAL does not.
Pipeline time comparison
SEAL
2.85ms
H33
1.28ms
“Authentication circuits are shallow. H33 uses the minimum Q that supports one multiply-plain-accumulate — eliminating all overhead SEAL carries for deeper circuits it never uses.”
This is not a hack or a shortcut. It's the mathematically correct parameter choice for the computation being performed. SEAL's parameters are correct for general-purpose FHE. H33's parameters are correct for authentication.
Security proof — Q=56 still provides 128+ bit securityNIST L1 ✓
4,096
Ring Dimension (N)
56
Modulus Bits (log₂ Q)
128+
Security Bits (λ)
The HE Standard table (homomorphicencryption.org) establishes maximum Q for each N to maintain 128-bit security. For N = 4,096, the maximum is Q ≤ 109 bits. H33 uses Q = 56 bits — well below the ceiling. A smaller Q means the Ring-LWE problem is harder, not easier. The lattice dimension stays the same (N=4096) while the modulus shrinks, increasing the noise-to-modulus ratio that an attacker must overcome.
Lattice Estimator (Albrecht et al.):
N=4096, log₂(Q)=56, distribution=ternary
uSVP: 148.3 bits · Dual: 144.7 bits · Primal: 146.1 bits
✓ All attacks require > 128 bits — NIST Level 1 satisfied

Comparison: SEAL's Q=109 → ~128.2 bits (just at the boundary).
H33's Q=56 → ~146 bits. H33 is actually more secure, not less.
SEAL reference: Microsoft SEAL 4.1 · BFV default parameters · N=4096 · Q = [60,40,40,60] ≈ 109 bits
H33 config: H33 BFV Engine · N=4096 · Q = 56 bits (single NTT-friendly prime) · t = 65,537
Security: HE Standard table + Lattice Estimator confirm 128+ bit security at Q=56
Hardware: AWS c8g.metal-48xl · Graviton4 · Criterion.rs v0.5 · Feb 14, 2026
Proprietary · H33 ZK Engine · Post-Quantum

2.0µs prove. 0.2µs verify.
2.09ns cached. Zero knowledge.

H33's ZK system is a four-layer aggregation stack built on Circle STARKs over the Mersenne-31 field. First proof: 2.0µs. Every subsequent lookup via Cachee: 2.09ns — 960× faster. No trusted setup. Post-quantum safe.

Prove
2.0µs
first proof
Verify
0.2µs
200 nanoseconds
Cached Lookup
2.09ns
via Cachee L1
Speedup
960×
cached vs fresh
Four-layer ZK aggregation stack — click to expandProprietary
L1
Nova IVC
Incremental Verifiable Computation — fold each auth into a running proof
~0.8µs
Mechanism
Nova Folding
Incrementally folds each new auth statement into a running R1CS instance
Key Benefit
O(1) Verification
Verifier work is constant regardless of how many auths have been folded
Recursion
IVC Chain
Each proof attests to the validity of all previous proofs in the chain
Commitment
Pedersen
Additively homomorphic commitment for efficient folding
Nova's folding scheme is the fastest known IVC. Instead of proving each auth from scratch, it folds the new auth statement into an accumulator — amortizing the cost of verification across thousands of proofs.
L2
Plonky3 STARK Compression
Compress the Nova accumulator into a succinct Circle STARK proof
~0.6µs
Framework
Plonky3
Polygon's STARK prover with custom H33 AIR constraints
Field
Mersenne-31
p = 2³¹ − 1. Native 32-bit arithmetic — no BigInt overhead
Hash
Poseidon2
Algebraic hash over M31. ~3× faster than Poseidon. STARK-friendly.
Geometry
Circle STARK
Evaluations on a circle group over M31 — smooth 2-adic domain for FFT
Circle STARKs use the circle group of M31 instead of a multiplicative subgroup — giving smooth power-of-2 evaluation domains natively in a 31-bit prime field. Poseidon2 is the hash function: algebraically structured for minimal STARK constraints, 3× faster than original Poseidon.
L3
STARK-of-STARKs Recursion
Recursively verify the STARK proof inside another STARK — logarithmic compression
~0.4µs
Technique
Recursive Verification
STARK verifier circuit compiled into AIR constraints, proved by outer STARK
Compression
Logarithmic
Each recursion level shrinks proof by ~10×. 2-3 levels → ultra-succinct
Batching
32 Proofs/Batch
Matches the SIMD batch size — one recursive proof per 32-user batch
Post-Quantum
Hash-Based ✓
STARKs use no elliptic curves. Security from hash collision resistance only.
This is where the"post-quantum" guarantee comes from. SNARKs (Groth16, PLONK) rely on elliptic curve pairings that quantum computers can break. STARKs rely only on collision-resistant hashes — quantum-safe by construction.
L4
Merkle Commitment + Cachee
Anchor to Merkle tree. Cache the final proof for 2.09ns subsequent lookups.
~0.2µs + cache
Merkle Hash
SHA3-256
NIST standard. Proof root anchored to Merkle tree for auditability.
Cache Engine
Cachee L1
Rust-native in-process cache. 497M ops/sec. 2.09ns per lookup.
Cache Hit
2.09ns
960× faster than generating a fresh proof
Eviction
LRU + TTL
Configurable expiry. Stale proofs regenerated on-demand at 2.0µs.
The final proof is stored in Cachee L1 — an in-process Rust cache running at 497 million ops/sec. Subsequent verifications retrieve the proof in 2.09 nanoseconds. Only the first auth incurs the full 2.0µs pipeline.
Proof lifecycle — watch it flowReady
🧬
Auth
Input
🔄
Nova
Fold
Circle
STARK
🔁
Recursive
Compress
🌳
Merkle
Commit
💾
Cachee
Store
Click a button above to animate the proof lifecycle
Cachee integration — why subsequent auths are 960× faster2.09ns
First Proof
2.0µs
Full 4-layer pipeline
then →
960×faster ↓
Every Subsequent
2.09ns
Cachee L1 direct hit
At a 40% cache hit rate (conservative production default), the effective per-auth ZK cost drops to ~1.2µs blended. At 80% hit rate (returning users): ~0.4µs. The ZK proof becomes effectively free.
Cryptographic primitives — why these choices
🔵

Mersenne-31 Field

p = 2³¹ − 1

A Mersenne prime. Reduction mod p is a single shift-and-add — no division. Fits in one 32-bit register. 4-6× faster than BN254's 254-bit field.

🌀

Poseidon2 Hash

3× faster than Poseidon

Algebraic hash function optimized for STARK AIR constraints. Fewer rounds, better diffusion matrix. Minimal constraint overhead when proved inside a STARK.

Circle STARK Geometry

Circle group over M31

Evaluations on the unit circle x² + y² = 1 over M31. Gives smooth power-of-2 subgroups for NTT/FFT. Enables efficient FRI.

vs competing ZK systemsH33 advantage
SystemProveVerifyProof SizeSetupPQ-SafeCost/Proof
H33 ZKP Stark Lookup
Circle STARK + Cachee
2.0µs0.2µs~200BNoneYes ✓~$0.000002
Groth16
BN254 pairing-based
~40ms~3ms128BTrusted ⚠No ✗~$0.05
RISC Zero
zkVM / STARK
~200ms~2ms~200KBNoneYes$15-30
SP1 (Succinct)
zkVM / STARK
~150ms~2ms~150KBNoneYes$5-15
PLONK
KZG commitments
~30ms~5ms~600BUniversalNo ✗~$0.03
H33 is purpose-built for auth proofs — not a general zkVM. That focus enables 20,000× faster proofs.
Engine: H33 ZKP Stark Lookup (proprietary) · Circle STARK over M31 · Poseidon2 hash · Nova IVC folding
Security: Hash-based (collision resistance only) · Post-quantum safe · No trusted setup
Cache: Cachee L1 · 497M ops/sec · 2.09ns per lookup · 960× speedup over fresh proof
Hardware: AWS c8g.metal-48xl · Graviton4 · Criterion.rs v0.5 · Feb 14, 2026
Interactive · Click the servers below

3-of-5 threshold decryption.
No single server ever sees your data.

The decryption key is split into 5 shares using Shamir's Secret Sharing. Any 3 shares can reconstruct the result — but 1 or 2 shares reveal absolutely nothing. Click the servers to build a quorum.

Decryption authorities — click to select quorum 0 of 3 needed
🔑 Share 1
Authority α
US-East (Virginia)
🔑 Share 2
Authority β
EU-West (Frankfurt)
🔑 Share 3
Authority γ
AP-Southeast (Tokyo)
🔑 Share 4
Authority δ
US-West (Oregon)
🔑 Share 5
Authority ε
EU-North (Stockholm)
🔒
Locked — select 3 authorities
Click servers above to form a decryption quorum. Any combination of 3 or more can reconstruct.
0 / 3
Scenarios — see what happens when servers fail
Single-Key
⚠️

Traditional / SEAL Decrypt

One server holds the entire secret key. That server decrypts the ciphertext and sees the full plaintext biometric. If that server is compromised, all data is exposed.

0.15ms · 1 server · Full plaintext exposure
Threshold
🛡️

H33 Threshold Decrypt

Each authority computes a partial decryption with its key share. Shares combine via Lagrange interpolation. No authority ever sees the full plaintext. The combined result goes directly to encrypted comparison.

0.33ms · 3-of-5 · Zero plaintext exposure
📐 Shamir's Secret Sharing — Degree-2 Polynomial
Secret
f(0) = s
=
Constant
s
+
Random
a₁ · x
+
Random
a₂ · x²
The decryption key is the constant term s of a degree-2 polynomial. Each authority receives f(i) — a point on the curve. With 3 points, Lagrange interpolation uniquely determines the polynomial and recovers s. With only 2 points, there are infinitely many degree-2 polynomials that fit — the secret is information-theoretically hidden.
Attack resistance
🏴‍☠️

1 Server Breached

Attacker gets 1 key share. Cannot reconstruct — need 3. Zero information about the secret is revealed.

DATA SAFE ✓
💥

2 Servers Breached

Attacker gets 2 shares. Still below threshold. Mathematically impossible to reconstruct from 2 of 3 required.

DATA SAFE ✓
🔌

2 Servers Offline

3 remain. That's exactly the threshold. Service continues with zero degradation. Auth still completes in 0.33ms.

SERVICE ONLINE ✓
Measured performance
Per-Share Decrypt
~0.11ms
each authority
Shamir Combine
~0.01ms
Lagrange interpolation
Total Threshold
0.33ms
3-of-5 complete
vs SEAL Single-Key
0.15ms
full exposure risk
Protocol: Shamir Secret Sharing (degree t-1 polynomial, t=3, n=5)
Security: Information-theoretic — unbreakable regardless of compute power
Cost of zero exposure: 0.33ms − 0.15ms = 0.18ms premium for guaranteed zero plaintext exposure
H33 still wins: Full pipeline 1.28ms (H33) vs 2.85ms (SEAL) — 2.2× faster even with threshold
NIST FIPS 204 · ML-DSA · Post-Quantum Digital Signature

Dilithium3. One signature per batch.
3.3µs amortized. Quantum-proof.

H33 uses the NIST reference implementation for Dilithium3 — the correct choice for a federal standard. Custom optimization happens at the batch level: one signature covers 32 users, cutting per-auth signing cost by 32×.

Sign
80.7µs
per operation
Verify
24.8µs
per operation
Total
106µs
sign + verify
Batched
3.3µs
per auth (÷32)
Signature
3,309B
NIST Level 3
Why use the NIST reference implementation?Deliberate choice

🔧 H33 Custom (4 engines)

  • BFV FHE engine — single-modulus Q=56, no relin
  • CKKS engine — Chebyshev bootstrap, fused dot_product
  • ZK-STARK engine — Circle STARK, M31, Poseidon2
  • Biometrics engine — multi-modal fusion, LSTM

📜 NIST Reference (Dilithium)

  • FIPS 204 certified — federal compliance ready
  • Audited by NIST, industry, and academia
  • pqcrypto-mldsa Rust crate — battle-tested
  • Zero risk of implementation bugs in the standard
Standards should be standards. H33 builds custom where the algorithm doesn't exist yet (no one else has a 2.0µs auth-specific ZK proof). For Dilithium, the algorithm is already perfect — NIST spent 8 years selecting it. The optimization opportunity isn't in the cryptography; it's in how many times you call it.
Batch attestation — the real optimizationClick to animate
✍️
32 individual signatures
Individual
3,392µs
106µs × 32 users
32×
savings
Batched
106µs
1 signature ÷ 32 = 3.3µs/auth
Signature anatomy — 3,309 bytesNIST L3
3,309B
Signature Size

Lattice-based. Compact for post-quantum. 25× smaller than SPHINCS+.

1,952B
Public Key

Stored once per authority node. Amortized over billions of verifications.

103B
Per-Auth Overhead

3,309B ÷ 32 users = 103 bytes per auth. Negligible at server-to-server.

AES-192
Security Equiv.

NIST Level 3. Resists both classical and quantum attacks through 2060+.

vs other post-quantum signature schemesH33 choice: Dilithium3
SchemeNISTSignVerifySig SizePK SizeH33 Batched
Dilithium3 (ML-DSA)
FIPS 204 · Lattice-based · H33 choice
L380.7µs24.8µs3,309B1,952B3.3µs/auth
Dilithium2 (ML-DSA-44)
Faster but lower security
L2~55µs~18µs2,420B1,312B~2.3µs
Dilithium5 (ML-DSA-87)
Maximum security
L5~140µs~38µs4,627B2,592B~5.6µs
FALCON-512
NTRU lattice · Compact sigs
L1~350µs~45µs666B897B~12.3µs
SPHINCS+-128f
Hash-based · Conservative
L1~4.8ms~0.3ms17,088B32B~160µs
Ed25519 (classical)
⚠ NOT post-quantum
None~25µs~45µs64B32BQuantum-broken
Dilithium3 is the best balance for auth: fast sign/verify, manageable signature size, NIST L3 security. FALCON has smaller sigs but 4× slower signing and complex constant-time sampling. SPHINCS+ is 60× slower.

Why 3,309 bytes is fine for server-to-server auth

TLS Overhead
~5,000B
A typical TLS 1.3 handshake is already 5KB+. Dilithium adds 66% — one-time, amortized over session.
Batched Overhead
103B/auth
One 3,309B sig per 32-user batch = 103 bytes per auth. Less than a tweet.
Bandwidth
3.6 MB/sec
At 1.15M auth/sec: 1.15M ÷ 32 × 3,309B = 117 MB/sec of sigs. ~1 Gbps link handles it.
Dilithium signatures are larger than Ed25519 (3,309B vs 64B). But this is server-to-server authentication — not mobile-to-tower. Internal datacenter bandwidth is 25-100 Gbps. The signature overhead is 0.1% of available bandwidth. The correct tradeoff is: accept 3KB signatures, gain quantum resistance through 2060+.
Implementation: pqcrypto-mldsa (Rust) · NIST FIPS 204 reference · Dilithium3 / ML-DSA-65
Timings: Sign 80.7µs · Verify 24.8µs · Total 105.5µs · Batched 3.3µs/auth (÷32)
Sizes: Signature 3,309B · Public Key 1,952B · Secret Key 4,032B
Security: NIST Level 3 (AES-192 equivalent) · Lattice-based (Module-LWE)
Hardware: AWS c8g.metal-48xl · Graviton4 · Criterion.rs v0.5 · Feb 14, 2026

SIMD Batching — 32 Users Per FHE Op

BFV CRT Polynomial Coefficient Packing

1 FHE OP
1,375µs
Fixed cost
BATCH SIZE
1 user
of 32 slots
PER USER
1,375µs
0% saved
THROUGHPUT
727/s
per worker
BFV Polynomial Coefficient Slots ready
Fill Rate — Users Per Batch 1 / 32
18162432
Without SIMD
1 user × 1,375µs each
1,375µs
savings
With SIMD Batching
1 user packed → 1 FHE op
1,375µs
Core Insight — Why Million-Scale Throughput Is Possible
1 op
1,375µs
FHE cost
1 user
1,375µs
no batching
32 users
still 1,375µs
SIMD packed
per user
43µs
32× cheaper
🛡

NIST L1 → L5 Post-Quantum Security

FIPS 203 / 204 / 205 · Lattice-Based Cryptography

NIST Level 1 ≡ AES-128

Equivalent security to breaking AES-128. Sufficient for most commercial applications.

128
BITS
H0
H0 Developer

Development & testing tier. Classical crypto. No post-quantum guarantees.

DEV
Encryption
AES-256-GCM
Signature
Ed25519
Key Exchange
X25519
Latency
~0.3ms
Throughput
Dev only
H33-128 Production

Production post-quantum authentication. BFV FHE with NIST L1 lattice-based crypto.

NIST L1 PRODUCTION ★
Encryption
BFV FHE (N=4096)
Signature
Dilithium-3 (ML-DSA-65)
Key Exchange
Kyber-512 (ML-KEM-512)
Latency
1.43ms
Throughput
1.15M auth/sec
🛡
H-256 Maximum Security

Maximum post-quantum security. 256-bit equivalent. For defense & critical infrastructure.

NIST L5 MAX SECURITY
Encryption
BFV FHE (N=8192+)
Signature
Dilithium-5 / FALCON-1024
Key Exchange
Kyber-1024 (ML-KEM-1024)
Latency
~3.2ms
Throughput
Classified
Algorithm Selection Matrix: Standard (128-bit) uses Kyber-512 + Dilithium-2. High (192-bit) uses Kyber-768 + Dilithium-3. Critical (256-bit) uses Kyber-1024 + Dilithium-5. Ultra (512-bit) adds McEliece-8192 + FALCON-1024 for defense applications.
2024 NIST Finalizes PQC

FIPS 203/204/205 published. ML-KEM, ML-DSA standardized.

2025 H33 Production Deploy

H33-128 achieves 1.15M auth/sec with full PQC stack.

2026 Today — Migration Window YOU ARE HERE

Every day without PQC = more harvested data exposed.

2028 Early Quantum Threat

Optimistic estimates for cryptographically relevant quantum computers.

~2yr
2030 Quantum Viable (Est.)

Many researchers predict CRQC capable of breaking RSA-2048.

~4yr
2032 Quantum Mature

Conservative estimate. Error-corrected quantum at scale.

~6yr
2035 Post-Deadline

Data harvested in 2025 now decryptable. 10-year exposure window.

~9yr
⚠ The Migration Window Is Closing

Data encrypted with RSA/ECC today has a shelf-life. Nation-state adversaries are actively harvesting encrypted traffic now with the intent to decrypt it when quantum computers mature. The window between"now" and"quantum-viable" is your migration window. H33 provides post-quantum security today.

Threat Model
"Harvest Now, Decrypt Later" (HNDL)

Nation-state adversaries intercept and store encrypted communications today, banking on future quantum computers to break the encryption retroactively. This is not theoretical — intelligence agencies have confirmed this practice.

📡
STEP 1 Encrypted Traffic

Your data travels encrypted with RSA/ECC today

👁
STEP 2 Nation-State Intercept

Adversaries record ALL encrypted traffic at backbone

🗃
STEP 3 Store & Wait

Petabytes stored in data centers. Years of patience.

STEP 4 Quantum Computer

2028-2032: Cryptographically relevant quantum arrives

🔒
STEP 5 Decrypt Everything

RSA, ECC broken. All harvested data exposed retroactively.

Data Harvested
2025
RSA/ECC encrypted
5-10 yr
EXPOSURE WINDOW
Decrypted By
~2032
Quantum mature
🛡 H33 uses lattice-based crypto (NIST PQC). No exposure window. Quantum-safe today.
NIST FIPS 203 (ML-KEM) · FIPS 204 (ML-DSA) · FIPS 205 (SLH-DSA)
Lattice problems: Module-LWE, Module-SIS · Ring dimension N=4096 (L1) / N=8192+ (L5)
H33-128: Post-quantum in production today

Four Proprietary Engines

All Rust · Zero External Crypto Dependencies · 15 Patent Claims

🦀All Rust
🛡Zero external crypto deps
Only external: Dilithium3 (NIST FIPS 204 reference impl, pqcrypto-mldsa)
1,628 tests · 300K proptest · Feb 14, 2026
CACHEE L1 — CASE STUDY

From 17µs to 2.09ns

8,134× faster — Rust-native cache replacing Redis

BEFORE — REDIS BACKED
17µs
per cache hit
Throughput~59K ops/sec
In 300ms blink~17,600 lookups
BackendElastiCache Redis 7.1
8,134×
AFTER — RUST-NATIVE CACHEE
2.09ns
per cache hit
Throughput497M ops/sec
In 300ms blink~143M lookups
BackendRust-native in-process
THROUGHPUT COMPARISON
Redis59K ops/sec
Cachee L1497,120,061 ops/sec

In the time one Redis lookup completes,
Cachee performs 8,134 lookups.

Click the button to see it happen.

REDIS
0
lookups completed
CACHEE L1
0
lookups completed

When a ZK-STARK proof is first verified, it takes <3ms. Cachee stores the result — every subsequent verification takes just 2.09ns. That's ~1,435× faster.

1
First-Time STARK Verification
Circle STARK proof arrives → Full verification pipeline
M31 field Poseidon2 hash 128-bit PQ security
<3ms
2
Cachee L1 Stores Verification Result
Proof hash → verification result stored in Rust-native L1 cache
No serialization. No network hop. No Redis protocol overhead.
In-process memory Zero-copy access Cost-aware LRU
3
Every Subsequent Lookup — Instant
2.09ns
~1,435× faster than first verification
2.09ns (Cachee)3ms (full verify)

Drag the slider to see how cache hit rate transforms your effective authentication latency. Higher cache rates push ZK verification cost toward zero.

Cache Hit Rate 75%
40%99%
EFFECTIVE ZK LATENCY
750.00µs
blended verify cost
TOTAL AUTH LATENCY
2.180ms
full pipeline + ZK
EST. THROUGHPUT
459/sec
single-thread serial
DAILY CAPACITY
0.0B/day
projected daily auths
Measured · Criterion.rs v0.5 · 100 samples · Feb 14, 2026
H33 · Cachee L1 · Rust-native