How H33 achieves 2.29 million authentications per second.

The number

2,293,766 authentications per second. Sustained.

The headline metric on Benchmark v12 is not a peak. It is the P50 of fifteen back-to-back five-minute runs on a single AWS c7g.16xlarge instance, with a 10-second warmup, a workload mix of 5% enroll + 90% verify + 5% revoke, and a 512-thread work-stealing runtime. The full methodology sits on /benchmark/ — this article explains the decisions that produced the number.

Everything that matters is in three places: the biometric match, the concurrency model, and the honest workload. The signature (ML-DSA-65) is fast — it isn't the bottleneck. The STARK proof of biometric match is fast — it isn't the bottleneck either. The bottleneck is the FHE match itself. So the entire architecture is designed around a single question: how do you keep 512 worker threads maximally busy on the FHE math?

1 · Why FHE at all

The biometric template never decrypts.

The classical shortcut for biometric authentication is: decrypt the template, run a similarity function against a live scan, encrypt whatever you want to keep. The security failure mode is obvious — decryption happens in memory the operator controls. Every breach story where biometric templates leaked traces to a decryption moment.

Fully Homomorphic Encryption lets the match happen without a decryption moment. The similarity function is evaluated against the ciphertext. The output is a ciphertext of the similarity score. Only then, a threshold check produces a boolean — was this a match — and only that boolean crosses the trust boundary.

The classical objection to FHE is speed. Historically FHE match runtimes were measured in hundreds of milliseconds — nothing you'd put in a hot path. Benchmark v12 measures the match at approximately 8 microseconds median. That's not because H33 invented new cryptography. It's because the entire scheme is chosen — leveled, not fully bootstrapped, with parameters tuned specifically to the arithmetic circuit of the similarity function. Nothing is general-purpose. Everything is single-purpose.

2 · The concurrency model

512 workers, zero contention.

The obvious mistake with a high-throughput cryptographic service is to protect the cryptographic state with a lock. Every worker fights for the lock. Throughput becomes a function of lock hold time, not compute. Adding cores makes it worse.

H33's runtime is tokio 1.38 configured with 512 workers, one per hardware thread across the two Graviton3 sockets. Each worker owns its own set of cryptographic scratch buffers. There is no shared cryptographic state on the hot path. The audit log receives writes through a bounded MPSC channel with backpressure at 10k messages; when the channel backs up, the worker's send becomes a cooperative yield, not a lock wait.

This detail matters because most published cryptographic benchmarks are single-threaded microbenchmarks scaled up by dividing wall-clock time by core count. That kind of "throughput" collapses the moment there's real cross-worker coordination. H33's number is a system-level measurement: 512 workers running the full lifecycle concurrently, with audit emission, receipt signing, and workload mix all included.

3 · The honest workload

90% verify, 5% enroll, 5% revoke.

A common way to make a number look bigger is to benchmark the fast path only. In authentication, that's usually the verify hot path — no biometric enrollment, no revocation. A production traffic distribution looks different. Enrollment is rare but expensive (new templates, new signing keys). Revocation is rare but latency-critical.

Benchmark v12's workload mix is 5% enroll, 90% verify, 5% revoke, sampled per request. That means every one in twenty requests triggers a full new-template flow, and every one in twenty triggers a session revocation that touches shared state. The 2,293,766/sec number includes those slower paths. If we benchmarked the verify-only fast path, the number would be higher — but it wouldn't match production traffic.

4 · The signature

ML-DSA-65 · fast enough not to be the bottleneck.

Session tokens are signed with ML-DSA-65 (Dilithium, NIST FIPS 204). The sign operation is approximately 3 microseconds per token on the Graviton3, and verify is approximately 1 microsecond. At 2.29M ops/sec across 512 workers, that's roughly 4.5 microseconds of signing work per worker per second — a small fraction of the workload.

The important thing about ML-DSA-65 isn't its speed. It's that it produces a quantum-safe signature at speeds competitive with classical ECDSA (which is ~1 microsecond on the same hardware). The post-quantum signature is not the tax it used to be. That has nothing to do with H33 — it's the state of the art in 2026 lattice cryptography. It means we can ship PQ from day one without a performance excuse.

5 · Audit emission on the hot path

Object-Locked writes without blocking.

Every authenticated session emits a receipt to an S3 bucket with Object Lock Compliance retention. Object Lock means the object cannot be deleted, even by root, for the retention period. It's a hard prerequisite for the audit-first architecture.

The naive way to write to S3 from a hot path is to await the PUT. That's a network round-trip on every authentication, which would collapse the throughput number by two orders of magnitude. Benchmark v12's audit emission runs through a per-worker MPSC channel to a dedicated flush task that batches writes at 5ms intervals or 128 receipts, whichever comes first. The worker's write is a channel send — approximately 100 nanoseconds — and the batch commit to S3 happens in the background.

There's a durability question in that pattern: what if the process dies before the batch flushes? The answer is that the worker also writes to a local NVMe append-log before returning success to the caller. Loss of the process without flush means the batch is reconstructed from the append-log on restart. Zero receipt loss. Zero hot-path network round-trips. That single decision is worth a factor of ~50 in throughput.

6 · What this number does not include

Honest disclosures.

Benchmark v12 measures the authentication service. It does not measure end-to-end user experience latency — TLS handshake, WebAuthn browser round-trip, and other layers add their own microseconds. In practice, real customer-facing latency for a passwordless login is dominated by biometric prompt UI and network to the relying party, not by H33's service.

The 2.29M/sec number also does not include Solana anchoring. On-chain notarization for selected artifact classes runs off the hot path via the same batched-emission pattern. Anchoring is bounded by Solana's own throughput, which is ~4,000 TPS · we anchor selective artifacts, not every session. The audit trail's cryptographic integrity is guaranteed by the Object-Locked receipt log; the on-chain anchor is a third-party time proof, not a durability layer.

7 · Reproducibility

You should be able to check this.

Benchmark v12 ships with a Dockerfile (Rust 1.79-slim on debian:bookworm) and a 220-line run-benchmark.sh. Test vectors use deterministic seeds. Anyone with an AWS account can rent a c7g.16xlarge, pull the image, run the script, and see whether they land within variance (±0.24%).

This is not a "trust us" number. Reproducibility is why we published the workload mix and the compiler flags. It's why we noted that we're on ARM64 Graviton3, not x86, and that the Graviton3's NEON extensions carry a meaningful chunk of the FHE inner loop. Every decision that changes the number is documented. If you reproduce it on x86 and get a lower number, that's the compiler emitting NEON we don't get. If you reproduce it on an ARM64 Ampere and get within ±5%, that would be a useful independent data point.

The whole point of publishing a benchmark is that the reader can decide whether they believe the number. Everything above is what we did to make believing it easier.

What comes next

Benchmark v13.

v13 will land when one of three things changes: (a) we add end-to-end WebAuthn round-trip to the measurement, so real user-facing latency has a published number too; (b) the FHE match runtime drops meaningfully — there are lattice-parameter improvements in flight; or (c) the runtime supports multi-instance sharding, which would push the sustained number well past 10M/sec on a small cluster. When any of those ships, v13 is the report.

In the meantime, v12's number is the published claim. Everything on this site that cites throughput cites this article. Everything that cites methodology cites the benchmark page. Everything that cites cryptographic soundness cites the algorithms named above (Dilithium, Kyber, FHE with tuned lattice parameters — all NIST-standardized or peer-reviewed).