A Compiler Built for Cryptography

Build cryptographic applications in Python. Compile them into highly optimized execution for modern hardware.

Awesome Zorch

Why Cryptography Needs a Domain-Specific Compiler

General-purpose compiler optimizations weren't designed for finite fields, polynomial arithmetic, or proof systems.

General-purpose compilers can't see the math

To GCC, a * b % p is three integer instructions. C and Rust give you no way to say that p is a prime modulus, and no analysis recovers what the language could not express.

  • gcc
  • rustc
  • clang

ML compilers see math a different math

XLA reshapes whole programs around tensor algebra over floats. Nothing in it can say "this u32 is a field element," so an optimization like lazy reduction never comes up.

  • xla
  • tvm
  • triton

Hand-written kernels, one kernel at a time

A hand-tuned kernel knows the math, but couples one operation, whether MSM, NTT, or a hash, to one GPU. Research moves fast and hardware faster, so that code rarely lives long enough to reuse.

  • icicle
  • sppark

Won't AI just optimize it?

AI is good at local, profiling-guided tuning. But lazy reduction and fusion are global decisions across the whole computation graph, which it does not see. A compiler optimizes the graph, not the snippet.

  • claude
  • codex
gccrustcclangxlatvmtritoniciclespparkAI codingagentszorch
Field-aware semanticsfinite fields, not integers
Whole-graph optimizationlazy reduction, fusion
Hardware portabilitysame source, next GPU
Math-level sourcereads like the paper, not tuned CUDA
Algorithm agilitynew scheme, no new kernels

The Verifiable Difference a Compiler Makes

Explore real-time benchmark data on compilation throughput, compute cost reduction, and verification latency compared with manual optimization.

  • sp1_zerocheckvs SP1
    3.09× the speed of SP1
  • sp1_trace_genvs SP1
    2.20× the speed of SP1
  • sp1_checkpoint_genvs SP1
    1.86× the speed of SP1
  • ntt_koalabear(224)vs ICICLE
    1.59× the speed of ICICLE
  • groth16_prove(224)vs ICICLE
    1.50× the speed of ICICLE
  • ntt_gf2_32(224)vs Binius
    1.30× the speed of Binius
  • msm_bn254_g1(224)vs ICICLE
    1.09× the speed of ICICLE
  • sp1_jagged_evalsvs SP1
    1.09× the speed of SP1
  • msm_bn254_g2(224)vs ICICLE
    1.06× the speed of ICICLE
  • sp1_logup_gkrvs SP1
    0.98× the speed of SP1
  • sp1_trace_commitvs SP1
    0.94× the speed of SP1

From Python to the Hardware

One pipeline: a Python framework for SNARKs, lowered through StableHLO and optimized all the way down to CPU and GPU kernels.

  1. Zorch
  2. FRX
  3. StableHLO
  4. XLA
  5. PrimeIR
  6. CPU · GPU

Frontend framework

Build a SNARK in Python: define your IOP rounds and compose them. You write the protocol, and never touch the kernels.

FRX

A JAX-based runtime that traces your Python into a graph and lowers it to StableHLO, carrying field types, not floats.

XLA

Runs a full optimization pipeline over the whole graph, from fusion and layout to lazy reduction, treating it as one program.

PrimeIR

An MLIR layer that lowers the optimized graph into kernels and tunes the generated code for each CPU and GPU target.