What Is RiscZero?
RiscZero is a zero-knowledge startup that raised $40M in Series A funding in 2023 to build a zero-knowledge virtual machine (zkVM) based on the RISC-V instruction set architecture. The core proposition is compelling: write normal Rust or C code, compile it to RISC-V, and RiscZero's proving system automatically generates a zero-knowledge proof that the computation executed correctly — without revealing the inputs.
Their flagship product, Bonsai, is a cloud-based proving service that offloads proof generation to dedicated infrastructure. The target use cases are blockchain bridges, ZK rollups, verifiable ML inference, and any scenario where you need to prove arbitrary computation was performed correctly. RiscZero uses STARK-based proofs, which are post-quantum compatible at the proof layer.
RiscZero's zkVM is a genuine innovation in developer experience. The ability to write standard Rust, compile to RISC-V, and get zero-knowledge proofs without learning circuit languages like Circom or writing R1CS constraints is a meaningful contribution to the ZK ecosystem. The question is whether a general-purpose VM is the right tool for authentication.
The trade-off is performance. Running code inside a zkVM introduces a 10,000x to 100,000x slowdown compared to native execution. Every RISC-V instruction must be arithmetized into a constraint system and then proved. For blockchain applications where proof generation can happen asynchronously and latency is measured in blocks (12+ seconds on Ethereum), this overhead is acceptable. For real-time authentication at enterprise scale, it is not.
Where RiscZero Falls Short for Enterprise Authentication
The fundamental mismatch is architectural. RiscZero is a general-purpose verifiable computation engine. It has no opinion on what you compute — it just proves you computed it. Enterprise authentication requires specific, purpose-built cryptographic primitives working in concert: fully homomorphic encryption for biometric matching on ciphertext, ZK proofs for credential verification, and post-quantum signatures for attestation.
RiscZero provides none of these out of the box. You could theoretically implement FHE inside a zkVM guest program, but the compounding overhead would be catastrophic: a 967-microsecond FHE operation running inside a 10,000x-overhead VM becomes nearly 10 seconds per batch. That is five orders of magnitude slower than what H33 delivers natively.
The gaps extend beyond raw performance:
- No FHE engine — RiscZero cannot perform encrypted biometric matching. There is no BFV or CKKS implementation. Biometric templates would need to be decrypted before processing, eliminating the zero-knowledge property for the most sensitive data.
- No SIMD batching — H33 packs 32 users into a single BFV ciphertext (4,096 slots / 128 dimensions) and processes the entire batch in one FHE operation. RiscZero's guest programs run sequentially in a constrained VM environment with no equivalent batching primitive.
- No post-quantum signatures beyond STARKs — While RiscZero's STARK proofs are quantum-resistant, the system lacks CRYSTALS-Dilithium or CRYSTALS-Kyber for key exchange and attestation. H33 implements NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) natively.
- No authentication pipeline — RiscZero provides a proving system, not an auth system. Enrollment, template storage, key management, session tokens, rate limiting, and audit logging all must be built from scratch.
- No key management — Enterprise authentication requires HSM integration, key rotation, and secure key derivation. RiscZero's scope ends at proof generation.
H33's Approach: Purpose-Built ZK for Authentication
H33 does not attempt to be a general-purpose proving system. Instead, it fuses three cryptographic layers — FHE, ZK proofs, and post-quantum signatures — into a single API call optimized specifically for identity verification. The architecture eliminates the abstraction layers that make general-purpose systems flexible but slow.
The ZKP component uses an in-process DashMap cache that resolves proof lookups in 0.062 microseconds — not seconds, not milliseconds, but 62 nanoseconds. This is possible because H33's ZK system is not running inside a virtual machine. The proofs are pre-computed STARK-based lookups stored in lock-free concurrent hash maps, accessible from 96 parallel worker threads without serialization overhead.
One H33 API call executes three stages: BFV fully homomorphic encryption for encrypted biometric matching (967µs for 32 users), STARK-based ZKP lookup via DashMap (0.062µs), and Dilithium attestation signing and verification (191µs). Total: approximately 1,160µs for 32 users, or 36µs per authentication. Every stage is post-quantum secure.
The production deployment on AWS Graviton4 (c8g.metal-48xl, 192 vCPUs) sustains 1,714,496 authentications per second over 120-second runs, with a 30-second peak of 2,154,351 auth/sec. These numbers come from Criterion.rs benchmarks, not theoretical projections, validated across 2,227 tests with 108 patent claims covering the fused pipeline architecture.
Head-to-Head Comparison
| Dimension | H33 | RiscZero |
|---|---|---|
| Primary Purpose | Post-quantum authentication pipeline | General-purpose verifiable computation |
| ZK Proof Latency | 0.062µs (DashMap lookup) | Seconds to minutes (proof generation) |
| VM Overhead | None — native Rust | 10,000–100,000x slowdown |
| FHE Support | BFV + CKKS (32 users/ciphertext) | None |
| Biometric Auth | Encrypted matching on ciphertext | Not supported |
| PQ Signatures | FIPS 203 + 204 (Kyber + Dilithium) | STARK proofs only |
| Throughput | 2.15M auth/sec (96 workers) | Application-dependent |
| Developer Model | Single API call (REST/gRPC) | Write Rust/C, compile to RISC-V guest |
The table reflects a difference in kind, not degree. RiscZero's strength is universality: any program that compiles to RISC-V can be proved. H33's strength is specificity: the authentication pipeline is optimized down to the NTT butterfly operations, Montgomery reduction chains, and NEON-accelerated Galois rotations that make sub-millisecond FHE possible.
When to Use Each
Choose RiscZero When:
- General verifiable computation — You need to prove that an arbitrary program executed correctly without revealing its inputs. This is RiscZero's core strength.
- Blockchain bridges and rollups — Cross-chain verification where proof generation happens asynchronously and latency budgets are measured in seconds or blocks.
- Verifiable ML inference — Proving that a machine learning model produced a specific output from specific inputs, where minutes of proving time is acceptable.
- Developer experience is paramount — Writing standard Rust instead of learning circuit DSLs is a genuine advantage for teams without ZK expertise.
Choose H33 When:
- Real-time authentication — Any scenario where verification must complete in microseconds, not seconds. Login flows, API gating, continuous authentication.
- Biometric identity verification — Encrypted biometric matching that never exposes raw templates. FHE is required, and running FHE inside a zkVM is impractical.
- Post-quantum compliance — NIST FIPS 203/204 compliance with Dilithium attestation, Kyber key exchange, and lattice-based FHE — not just quantum-resistant proofs.
- Enterprise scale — Sustained throughput above one million auth/sec with sub-millisecond latency per batch. Financial services, healthcare, government identity systems.
- Regulatory audit trails — Built-in attestation with Dilithium signatures producing cryptographic proof of every verification event.
These systems can coexist. An enterprise might use H33 for real-time authentication at the edge and RiscZero's Bonsai service to generate verifiable proofs of aggregate compliance reports asynchronously. The correct framing is not "which is better" but "which is right for this specific workload."
The Architectural Lesson
The ZK ecosystem in 2026 is bifurcating along a clear axis: general-purpose versus purpose-built. RiscZero, along with projects like SP1 and Jolt, is pushing the frontier of universal verifiable computation. H33, along with specialized identity and financial infrastructure providers, is building domain-specific cryptographic pipelines where every microsecond of overhead is engineered out.
General-purpose zkVMs accept a 10,000x+ performance penalty in exchange for universality. That trade-off makes perfect sense for blockchain infrastructure where proofs are verified on-chain and generation happens off-chain with generous time budgets. It makes no sense for authentication, where a user is waiting for a login to complete and the latency budget is measured in single-digit milliseconds.
H33 chose the opposite trade-off: sacrifice generality entirely in exchange for a fused pipeline that delivers 36 microseconds per authentication with full post-quantum security across every stage. The FHE engine, ZKP cache, and Dilithium attestation layer are not modular components that can be swapped out — they are a single optimized pipeline where the output of each stage feeds directly into the next, with zero serialization overhead and zero VM abstraction cost.
Both approaches have merit. But if your requirement is enterprise-grade identity verification at scale, the choice is unambiguous: purpose-built infrastructure will outperform a general-purpose VM by five to seven orders of magnitude on the workloads that matter.