Skip to content

How ProveKit compares

There is no single “best” ZK proof system, choices depend on the frontend you want, the verification target, audit posture, and operational tooling. This page summarizes how ProveKit positions itself against the most common alternatives.

DimensionProveKitHalo2 (PSE / zcash)Plonky2Circom + SnarkJS / RapidSnarkRISC Zero
FrontendNoirRust DSL (in-circuit Region/Gate API)Rust DSLCircomRust binary (zkVM)
Proof systemWHIR + Spartan-style sumcheckPlonkish + IPA / KZGFRI-based PLONKGroth16 (default)STARK + Groth16 wrap
Trusted setup (base proof)NoneNone (IPA) / per-circuit (KZG)NonePer-circuit ceremonyNone
Post-quantum secure (base proof)Yes (hash-based WHIR)No (IPA = discrete log; KZG = pairings)Yes (FRI / hash-based)No (pairings)Yes (FRI-based STARK)
Post-quantum secure (on-chain wrap)No (Groth16 over BN254)KZG: no; direct IPA verification not standard on EthereumNo (Groth16 wrap)NoNo (Groth16 wrap)
FieldBN254BN254 / PastaGoldilocksBN254 / BLS12-381Baby Bear → BN254 wrap
On-chain targetGroth16 wrap via Go/gnarkDirect on Ethereum (KZG mode)Wrap to Groth16Direct on EthereumGroth16 wrap
Native host supportCLI, Rust, WASM, FFI, HTTP server, recursiveRustRustJS/WASM, native binaryRust, WASM
Mobile pathFirst-class (Swift + Kotlin SDKs via FFI)DIYDIYDIYExperimental
Recursive verificationVia gnark Groth16 wrapperNativeNative (fast)LimitedNative (zkVM-style)
Audit statusv1 branch auditedMultiple auditsAudited (Polygon)Multiple auditsMultiple audits
LicenseMITMIT / Apache-2Apache-2 / MITGPL-3 / MIT componentsApache-2
Best whenYou want Noir + production-shaped runtime + cheap EVM verificationYou want maximum control inside Ethereum toolingYou want fast recursion in pure RustYou’re already invested in Circom or need legacy EVM verifiersYou want to prove arbitrary Rust without writing a circuit
  • Noir frontend. Higher-level than Halo2’s in-circuit API, less constrained than Circom’s signal-based model, type-checked unlike most circuit DSLs.
  • Cross-host runtime out of the box. CLI, Rust, WASM, FFI, mobile, and recursive paths from one codebase. Most alternatives leave host integration to you.
  • No trusted setup for the base proof. WHIR’s commitment scheme avoids per-circuit ceremonies; only the optional Groth16 outer wrap involves one.
  • Production-shaped tooling. Versioned artifacts, hash-choice control, public-input inspection, memory configuration on mobile, and a verifier service with concurrency controls.
  • Audit maturity. The v1 branch is audited (single audit); Halo2, Plonky2, and Circom-based stacks have multiple audits behind them across longer histories.
  • Recursive verification. Native recursion isn’t yet a first-class operation, the path goes through gnark Groth16 wrapping. Plonky2 and RISC Zero have direct recursion built in.
  • Established benchmarks. WHIR is newer than PLONK and FRI families; published numbers from competing systems are not directly comparable yet.
  • Ecosystem. Noir’s ecosystem is younger than Circom’s. Reusable libraries (signatures, primitives) are growing but smaller in scope.
If your priority is…Consider
Ship a credential or attestation app across web + mobileProveKit. The integration story is the differentiator.
Verify directly on Ethereum without a wrapperHalo2 (KZG mode) or Circom + SnarkJS. Mature on-chain verifiers exist.
Prove arbitrary Rust binaries without a circuitRISC Zero. zkVM approach trades constraint efficiency for developer ergonomics.
Maximize recursion throughputPlonky2. Native fast recursion is the headline feature.
Battle-tested + Ethereum-nativeHalo2. Most production Ethereum ZK stacks lean on it.
Audit-mature signature schemesCircom ecosystem. The largest catalog of audited primitives.

For any proof system, validate these before building on top:

  1. Run your real circuit through it. Synthetic benchmarks rarely predict your workload.
  2. Confirm the verification target. Where does the verifier run? On-chain? In a phone? In a browser?
  3. Check audit status. Has the proof system, the frontend, and the recursive verifier been independently reviewed?
  4. Test the deployment story. Versioning, artifact distribution, key management, these are where most ZK projects struggle, regardless of the proof system underneath.