The confidential and verifiable computing layer.
We build, optimize, and operate production systems, transforming trust-based digital systems into cryptographically verifiable infrastructure.
We bring confidential and verifiable systems to production, from architecture and implementation to optimization and operations.
Today, getting confidential and verifiable systems into production means cryptography, security, compiler, GPU and infrastructure specialists working in separate silos, months of manual integration and tuning, and starting over for every new scheme or hardware target. We replace that with one compiler that optimizes and generates execution code, a runtime that handles execution and memory, and orchestration that scales the same workload across CPU, GPU, TPU and FPGA.
Build cryptographic applications in Python. Compile them into highly optimized execution for modern hardware.
Zorch: Build a SNARK in Python, defining your IOP rounds and composing them. You write the protocol, and never touch the kernels. The blocks it gives you (hashing, Merkle commitment, Reed–Solomon LDE, transcript) hold no scheme-specific knowledge by rule, so a new prover adds only its own glue on top.
FRX: Fractalyze's fork of JAX. Traces your Python into a graph and lowers it to StableHLO, carrying field types, not floats. Finite fields are a native dtype here rather than a convention layered over u32, so the graph that reaches the compiler still knows it is doing modular arithmetic.
XLA: Runs a full optimization pipeline over the whole graph, from fusion and layout to lazy reduction, treating it as one program. Stock XLA reshapes programs around tensor algebra over floats and has no way to say that a u32 is a field element; ours is a fork that can, which is what puts an optimization like lazy reduction on the table at all.
PrimeIR: Prime Intermediate Representation, an intermediate language based on MLIR (Multi-Level Intermediate Representation), dedicated to cryptographic optimization for ZK proofs. It is the level at which a * b % p is one field operation instead of three integer instructions, which a general-purpose backend cannot recover, because the language never let you say it.
Provers and proving systems built on this stack:
- sp1-zorch: A lean SP1 prover on Zorch's blocks, adding only SP1's own commitment and prove glue: SMCS, the shard prover, and the FFI.
- openvm-zorch: A SWIRL prover and verifier, byte-matched against OpenVM's stark-backend.
- zisk-zorch: A ZisK prover carrying pil2-stark's Poseidon2–Goldilocks parameters and transcript, with the stage-1 trace commitment byte-matched against pil2-proofman.
- pico-zorch: A Pico prover, a Plonky3-style univariate STARK, FRI over KoalaBear with Poseidon2, byte-matched against the reference prover.
- groth16-zorch: A Groth16 prover written in Python on Zorch.
- bellman-zorch: A GPU Groth16 prover for bellman (BN256/alt_bn128): the h-FFT and all five MSMs in a single fused call, byte-identical to
groth16::create_proof. - flock-zorch: A GPU prover for flock's binary-field R1CS PIOP (eprint 2026/1329), authored once in Python and compiled to both CPU and GPU from the same source.
- accumulation-zorch: A GPU accumulation prover over Pasta: arkworks'
r1cs_nark_as+hp_asprove path as one fused kernel, byte-identical to the reference.
Our speed as a multiple of the baseline's, measured against ICICLE, SP1 and Binius, with parity at 1, including the two workloads where we are still behind.
Read the blog and the docs, or see the whole picture at fractalyze.io.