When you visit h33.ai and click "Test It Live," you are not watching a simulation. You are not running a local benchmark. You are triggering 1,000 real post-quantum cryptographic operations on a production server, with every timing measurement returned to your browser in real time.
This post walks through every step of what happens — from the moment you click the button to the moment the results appear on screen. No step is skipped. No detail is abstracted away. If you run the test yourself, this is exactly what your browser and our server are doing.
Before any authentication runs, the system needs to know you are a real person, not a script hammering the endpoint. H33 uses its own BotShield product for this — a proof-of-work challenge that runs entirely in your browser.
When the speed test modal opens, the browser requests a cryptographic challenge from the server. The server returns a random nonce and a difficulty level. Your browser then uses the Web Crypto API to search for a number that, when combined with the nonce, produces a SHA-256 hash with a specific number of leading zero bits. At the default difficulty, this takes one to three seconds on a modern device.
You see the hash count ticking up — "12K hashes... 24K hashes..." — as the browser works through candidates in parallel batches. When it finds a valid solution, it submits it to the server for verification. The server confirms the solution in microseconds and issues a session token.
This is the same technology that powers H33-BotShield, our standalone bot prevention product. No CAPTCHA. No image puzzles. No third-party tracking. The browser proves it did computational work, and that proof is enough. We are making this available as a free product — 10,000 challenges per month at no cost — because we believe every website deserves bot prevention that does not require surveillance.
With the proof of work verified, the browser sends your email address, the solved challenge, and a browser fingerprint to the server. The fingerprint is a hash derived from canvas rendering, WebGL parameters, screen dimensions, and processor count. It does not identify you personally — it identifies your browser session to prevent the same device from running unlimited tests.
The server validates everything, creates a session, and returns two things: a session token and the maximum number of authentications you are authorized to run. For the public speed test, this is 1,000. The session is now established. Your browser holds a token. The server is ready.
This is where the real work happens. Your browser sends a single HTTP POST to the server with the session token and a count of 1,000. One request. Not 1,000 requests — one.
On the server side, this triggers a tight loop in Rust that runs 1,000 complete post-quantum authentication operations in sequence. Each authentication executes the full cryptographic pipeline — the same pipeline that would run for a real user authenticating in a production application. There are no shortcuts, no synthetic workloads, no partial operations.
Each of the 1,000 authentications runs five stages:
Fully homomorphic encryption. A biometric template is encrypted using the BFV scheme. The raw template is never present in plaintext on any single server. The encryption produces a ciphertext that can be computed upon without decryption.
Encrypted matching. The server computes an inner product between the encrypted query template and the encrypted enrolled template. This operation runs entirely on ciphertext. The similarity score is computed without either template ever being decrypted. The result is an encrypted match score.
Zero-knowledge proof. A STARK proof is generated attesting that the computation was performed correctly. This proof is post-quantum — it does not rely on any assumption that quantum computers cannot break. An auditor can verify the proof independently without access to the underlying data or the server that produced it.
Post-quantum signature. A CRYSTALS-Dilithium digital signature is applied to the authentication result. This is a NIST FIPS 204 standardized signature that will remain secure in a post-quantum world. The signature binds the result to the computation that produced it.
Threat intelligence. Three native Rust machine learning agents evaluate the request in real time. One monitors for ciphertext harvesting patterns — attempts to collect encrypted data for future offline attacks. One watches for timing side-channel anomalies that could indicate an attacker probing for information leaks. One monitors the health of the cryptographic operations themselves, watching for noise budget degradation or parameter drift that could indicate a fault injection attack. All three agents run inline on every single authentication. Their combined overhead is a fraction of the total pipeline.
The server measures the timing of each operation in microseconds. When all 1,000 authentications are complete, the server returns a single JSON response containing the complete timing breakdown — per-authentication server times, per-stage breakdowns for encryption, proof generation, and signature, plus aggregate statistics. The response is approximately 5 kilobytes.
Your browser receives the batch response and has all 1,000 timing values. It then animates the results over approximately one second — not because the results take that long to process, but because watching a counter go from zero to 1,000 in a single frame is not satisfying. The progress bar fills. The counter increments. The live statistics update with each tick: current latency, running average, authentication rate.
This is a deliberate design choice. The server completed all 1,000 authentications before the animation starts. The playback is visualization, not computation.
When the animation completes, the final statistics appear. These are not computed from the animation — they are computed directly from the raw timing data returned by the server.
Every number displayed was measured on the server that executed the operations. Nothing is estimated. Nothing is extrapolated. If you run the test from Tokyo, the authentication rate is identical to running it from New York — because the cryptographic operations happen on the server, not in your browser. The only difference is the network overhead line.
After the results are displayed, the browser silently submits the complete timing data to the server for the benchmarks leaderboard. This includes the email address, the city detected from your IP (via ipapi.co), the full timing arrays, and the browser fingerprint. This submission is optional for the user experience — the results are already displayed — but it feeds the aggregate benchmark data published on the site.
The batch design is intentional. If the browser sent 1,000 individual HTTP requests, the results would measure network latency, browser connection limits, TCP handshake overhead, and TLS negotiation — not cryptographic throughput. By sending one request and having the server run the entire batch, we measure exactly one thing: how fast the post-quantum authentication pipeline runs on production hardware.
The browser makes exactly three HTTP requests during the entire test: one to create the session, one to run the batch, and one to submit the report. Everything else happens server-side in a single Rust loop with zero allocations between iterations.
This is what the benchmark measures. This is what the numbers mean. And this is what any developer with an API key can reproduce independently on the same hardware.
1,000 real post-quantum authentications. Your browser, our server. Every number measured, not projected.
Run Speed Test