Every primitive is independently verifiable, post-quantum attested, and composable with the others. None of them require trusting H33’s narrative about what happened.
RISC Zero's STARK foundation is already largely post-quantum friendly. The remaining quantum-vulnerable surface is the Groth16/BN254 compression layer used for proof shrinking and on-chain verification on Ethereum.
H33 and Cachee replace that dependency with post-quantum attestation, verification-result caching, and reusable STARK verification infrastructure — without re-architecting the zkVM, without changing the prover, and without paying the gas penalty of running raw recursive STARKs on L1.
The STARK core is built on hash-based and algebraic primitives whose security does not reduce to integer factoring or discrete logarithm. Shor's algorithm does not break any of these. Grover's algorithm halves the effective security level of the underlying hash, which is accounted for by choosing 256-bit hash outputs.
The quantum-vulnerable surface in a typical RISC Zero deployment is the optional compression wrapper applied after the recursive STARK. It is there for Ethereum gas economics, not for cryptographic strength. Below is exactly what breaks under a sufficiently large quantum computer.
A raw recursive STARK proof is on the order of 100 KB and verifies in millions of EVM gas. That is fine for off-chain or rollup-internal use. It is not fine for an L1 contract that pays gas for every verification. Groth16 was adopted as a compression layer to fit STARK verification into Ethereum's existing economics, not because the STARK itself was inadequate.
The price was acceptable when L1 verification economics were the binding constraint. As post-quantum migration timelines tighten — NIST FIPS 203/204/205 standards are final, and federal agencies have published 2030 transition deadlines — that price is no longer acceptable for systems whose receipts must remain verifiable for decades.
If the only reason Groth16 exists is to make verification cheap to re-execute, then a different shape of solution becomes available: do the STARK verification once, attest the result, and reuse the attestation. The compression problem becomes a caching problem — and caches do not need pairings.
The verification result becomes the artifact, not the compressed proof. Downstream parties — auditors, regulators, on-chain contracts that accept attested results, other counterparties — verify a 74-byte post-quantum signature bundle instead of a pairing equation. The original STARK is still verifiable from first principles if anyone wants to re-run it; the attestation just means most consumers do not need to.
The pieces below are the concrete substitution for the Groth16/BN254 step. H33 owns the cryptography. Cachee owns the distribution. Together they replace the compression-and-on-chain-verify path with a verification-result caching path that is fully post-quantum.
Three positions on the post-quantum-safety / on-chain-economics tradeoff. Pick the row that matches your verification horizon.
| Mode | Description | PQ Safe |
|---|---|---|
| RISC Zero + Groth16 | Current Ethereum-optimized deployment. ~256-byte on-chain proof, ~250K gas verification. Pairing-based wrapper exposes the verification path to Shor's algorithm. | No |
| Pure recursive STARK | Drop the compression layer entirely. Verify the recursive STARK on-chain. Fully PQ-safe end-to-end. Pays the full L1 gas cost (~10M+ gas per verification) and accepts the ~100 KB proof size. | Yes |
| STARK + Cachee + H33 | Verify the recursive STARK once off-chain through H33's independent verifier. Cache the verification result. Attach a 74-byte PQ attestation. Downstream consumers verify the attestation instead of the STARK or Groth16 wrapper — PQ-safe, with on-chain economics that beat the Groth16 wrapper because no pairing is computed. | Yes |
The components that make Mode 3 deployable today.
The questions that come up most often when teams evaluate Mode 3 against their existing Groth16-on-Ethereum deployment.
cargo install --git https://github.com/H33ai/h33-verifier gives you the h33-verify binary. No network access at verification time. The conformance spec, KAT vector, and threat model are committed in the repo.If your proof is supposed to be verifiable in 2040, the verification path needs to survive a 2030s-era quantum computer. That means no pairings, no BN254, no Shor-vulnerable curve anywhere in the chain of custody. Mode 3 is the cleanest available shape.
Independent verifier: Apache-2.0 · Spec frozen at v1 · Conformance corpus published