[ { "slug": "clean", "name": "Clean", "tagline": "Lean 4 framework for ZK circuits with machine-checked soundness and completeness", "title": "Clean (zkSecurity): Lean 4 formal verification framework for ZK circuits, sound and complete", "maintainer": "zkSecurity (hosted under Verified-zkEVM)", "url": "https://clean.zksecurity.xyz", "repo": "https://github.com/Verified-zkEVM/clean", "category": "zk-circuits", "targets": [ "AIR", "PLONK", "R1CS", "zkVM chips", "Plonky3-style tables" ], "approach": "Embedded Lean 4 DSL; proof assistant; soundness and completeness theorems per gadget, composed without re-proving", "license": "Open source (MIT)", "status": "Active, funded by an Ethereum Foundation Verified zkEVM grant", "since": "2025-03-27 (public introduction)", "summary": "Clean is an embedded Lean 4 language for writing zero-knowledge circuits in which every gadget carries a machine-checked proof of both soundness (any satisfying witness meets the specification) and completeness (every valid input has a satisfying witness). Created and maintained by zkSecurity, it targets AIR-style tables with lookups, PLONK and R1CS, composes verified gadgets into larger verified circuits, and since June 2026 models cross-table interactions so that whole multi-table systems such as zkVMs can be proved sound.", "details": [ "A Clean circuit is built from four operations: Witness (allocate a cell), Assert (add a constraint), Lookup (table membership) and Subcircuit (call a previously verified gadget). A `FormalCircuit` bundles input and output shapes, assumptions, a specification, a soundness proof and a completeness proof. Because the specification is stated over ordinary Lean values rather than field elements, a proof that a SHA-256 gadget is sound is a statement about the real SHA-256 function from Mathlib-style definitions, not about a re-encoding of it.", "Requiring completeness as well as soundness is the design decision that separates Clean from most other circuit frameworks. Soundness alone is satisfied by an unsatisfiable circuit, so a soundness-only proof does not tell you the circuit works. The pairing is what makes it safe to accept circuits written by untrusted parties, including LLM agents, which is the model behind [zk.golf](/frameworks/zk-golf/).", "Verified gadgets published by zkSecurity include Keccak-f, SHA-256, BLAKE3, circomlib's Poseidon (arity 1, sound and complete, with BN254 primality discharged by a Pratt certificate in CompPoly), U32 and U64 arithmetic, and a Fibonacci VM ensemble demonstrating the multi-table `Channel` primitive announced at ZKProof 8 in June 2026. Succinct's sp1-lean expresses SP1 Hypercube's RISC-V chip constraints in Clean and proves them against the Sail RISC-V model. The roadmap lists a Plonky3 backend with Rust code generation, LLZK integration for a Circom frontend, Stwo and Binius backends and custom-gate PLONK." ], "strengths": [ "Only circuit framework on this index whose default deliverable is both soundness and completeness for every gadget.", "Compositional: verified gadgets are reused as subcircuits without re-proving, so large circuits and multi-table zkVMs are tractable.", "Active ecosystem: sp1-lean, zk.golf, published verified hash gadgets, and a documented agent workflow for LLM-assisted proving." ], "limits": [ "Circuits are written in Clean; verifying an existing Circom or Halo2 codebase means porting, modelling or waiting for the LLZK frontend.", "Backend code generation (Plonky3 Rust) is on the roadmap; until it ships, the correspondence between the Lean circuit and the deployed constraints is a review item.", "Proof engineering in Lean 4 has a learning curve; zkSecurity's own comparison rates the Lean frameworks as the most sophisticated but heaviest on tactics." ], "fit": [ "Choose Clean when you are writing new circuits or a zkVM instruction set and want a verified artifact you can keep extending, when completeness matters (a wallet or bridge that must never reject a valid proof), or when you plan to let AI agents optimise circuits under a fixed specification. The maintainer, [zkSecurity](/firms/zksecurity/), takes verification engagements built on it." ], "references": [ [ "Clean documentation", "https://clean.zksecurity.xyz" ], [ "Introducing clean, a formal verification DSL for ZK circuits in Lean 4 (2025-03-27)", "https://blog.zksecurity.xyz/posts/clean/" ], [ "Clean: from verified circuits to verified zkVMs (2026-06-05)", "https://blog.zksecurity.xyz/posts/clean-verified-zkvms/" ], [ "Verifying Poseidon in Clean (2026-05-04)", "https://blog.zksecurity.xyz/posts/poseidon-clean/" ], [ "Comparison of formal verification frameworks for arithmetic circuits (2025-11-19)", "https://blog.zksecurity.xyz/posts/formal-verification-arithmetic-circuits/" ] ], "page": "https://sorryfree.com/frameworks/clean/" }, { "slug": "sp1-lean", "name": "sp1-lean", "tagline": "Lean verification of SP1 Hypercube's RISC-V chips, built on Clean", "maintainer": "Succinct, with Nethermind", "url": "https://github.com/succinctlabs/sp1-lean", "repo": "https://github.com/succinctlabs/sp1-lean", "category": "zk-circuits", "targets": [ "SP1 Hypercube", "RISC-V (RV64) chips", "AIR" ], "approach": "Lean 4 on Clean; chip constraints proved sound against the Sail RISC-V model", "license": "Open source (MIT / Apache-2.0)", "status": "Active", "since": "2025-10-09 (announcement)", "summary": "sp1-lean is Succinct's Lean 4 project, developed with Nethermind, that expresses the constraints of SP1 Hypercube's RISC-V chips in Clean and proves them sound against the Sail RISC-V reference model. As of the Ethereum Foundation's May 2026 review, 51 of 62 opcodes were fully proven; completeness is deferred for five chips.", "details": [ "The project is the most visible zkVM verification effort in public. Each RISC-V chip's AIR constraints are restated as a Clean circuit whose specification is the Sail semantics of the instruction, and soundness is proved 'axiom-clean' (no additional axioms beyond Lean's core).", "It is also the public case study in specification gaps. In May 2026 the Ethereum Foundation disclosed a JALR bug in SP1 Hypercube whose theorem assumed a 4-byte-aligned jump target, so the proof was valid but excluded legitimate programs. The disclosure and the accompanying audit of sp1-lean are required reading before trusting any zkVM proof claim." ], "strengths": [ "Real, deployed zkVM constraints proved against an independent ISA model rather than a hand-written spec.", "Built on Clean, so proofs compose with other Clean gadgets and benefit from the Channel work for multi-table soundness.", "Openly reviewed by a third party (the EF Formal Verification team), with gaps published." ], "limits": [ "Specific to SP1 Hypercube; not a general framework.", "Completeness deferred for several chips and some opcodes still unproven at last public review.", "Correspondence between the Lean restatement and the Rust constraints is a manual step (a Plonky3 codegen backend for Clean would close it)." ], "fit": [ "Read sp1-lean when you deploy on SP1 or want a template for verifying your own zkVM's chips in Clean." ], "references": [ [ "Nethermind and Succinct: Lean verification of SP1 Hypercube core chips (2025-10-09)", "https://blog.succinct.xyz/nethermind-lean/" ], [ "Ethereum Foundation: SP1 JALR bug and sp1-lean audit (2026-05-20)", "https://zkevm.ethereum.foundation/blog/sp1-fv" ] ], "page": "https://sorryfree.com/frameworks/sp1-lean/" }, { "slug": "zklean", "name": "zkLean", "tagline": "Galois's Lean 4 framework for R1CS and lookup-based circuits, Jolt-style", "maintainer": "Galois", "url": "https://github.com/GaloisInc/zk-lean", "repo": "https://github.com/GaloisInc/zk-lean", "category": "zk-circuits", "targets": [ "R1CS", "Lookups", "MLE lookups", "RAM (Jolt-style)" ], "approach": "Lean 4, Hoare-triple style via Std.Do; soundness of extracted circuits", "license": "Open source (BSD-3)", "status": "Active, Ethereum Foundation funded", "summary": "zkLean is Galois's Lean 4 framework for stating and proving soundness of extracted circuits, with native support for R1CS, lookups, multilinear-extension lookups and RAM in the style of the Jolt zkVM. It ships a SHA-3 example and a Jolt extractor, and is one of the proof backends LLZK lowers to.", "details": [ "Where Clean asks you to write the circuit in Lean, zkLean is designed around extraction: constraints are pulled out of an existing implementation (the Jolt extractor is the reference) and proved sound in a Hoare-logic style built on Lean's Std.Do monadic reasoning library. That makes it a natural fit for lookup-heavy designs where the 'circuit' is mostly table lookups and memory checking.", "Galois pairs zkLean with its Cryptol/SAW lineage and with LLZK, so Circom and Halo2 frontends can reach it through the shared IR." ], "strengths": [ "First-class lookups, MLE lookups and RAM, matching Jolt-era zkVM designs.", "Extraction-oriented, so existing code can be verified without rewriting.", "Maintained by a firm with two decades of verification delivery." ], "limits": [ "Primarily soundness; check the completeness story per project.", "Younger than Clean on published verified gadgets.", "Hoare-style proofs require familiarity with Std.Do." ], "fit": [ "Choose zkLean for Jolt-style or lookup-centric systems, or when Galois is your verification partner and you want their Cryptol/SAW and zkLean work in one engagement." ], "references": [ [ "zk-lean repository", "https://github.com/GaloisInc/zk-lean" ], [ "zkSecurity comparison including zk-lean (2025-11-19)", "https://blog.zksecurity.xyz/posts/formal-verification-arithmetic-circuits/" ] ], "page": "https://sorryfree.com/frameworks/zklean/" }, { "slug": "halva", "name": "Halva", "tagline": "Nethermind's Lean 4 verification of Halo2 circuits", "maintainer": "Nethermind", "url": "https://github.com/NethermindEth/Halva", "repo": "https://github.com/NethermindEth/Halva", "category": "zk-circuits", "targets": [ "Halo2", "PLONKish" ], "approach": "Extract gates, copy, permutation and lookup constraints at synthesis time; soundness proofs in Lean 4", "license": "Open source", "status": "Active, Ethereum Foundation grant", "summary": "Halva extracts the gate, copy, permutation and lookup constraints of a Halo2 circuit at synthesis time and lets engineers prove soundness in Lean 4. In July 2025 Nethermind used it to find a critical soundness bug in Scroll's deprecated Keccak-256 circuit.", "details": [ "Halo2 circuits are notoriously hard to review because constraints are spread across configure and synthesize code. Halva instruments synthesis so the exact constraint system reaches Lean, where the specification is stated and the soundness theorem proved. The Scroll Keccak result is the clearest public example of a proof-assistant framework finding a real, critical circuit bug." ], "strengths": [ "Works on real Halo2 code without rewriting it.", "Public critical finding in a production-grade circuit.", "Same team maintains CertiPlonk (Plonky3) and Lean EVM work, so zkEVM stacks can be covered end to end." ], "limits": [ "Halo2 only.", "Soundness-focused; completeness is a separate exercise.", "Extraction is a trusted step; review it." ], "fit": [ "Choose Halva for any Halo2 or PLONKish circuit you cannot rewrite, particularly zkEVM components." ], "references": [ [ "Formal verification of Halo2 circuits in Lean (Nethermind, 2025-07-02)", "https://www.nethermind.io/blog/formal-verification-of-halo2-circuits-in-lean" ], [ "Halva repository", "https://github.com/NethermindEth/Halva" ] ], "page": "https://sorryfree.com/frameworks/halva/" }, { "slug": "picus", "name": "Picus", "tagline": "Automatic SMT-based underconstraint detection for Circom, R1CS, gnark and LLZK", "maintainer": "Veridise", "url": "https://github.com/Veridise/Picus", "repo": "https://github.com/Veridise/Picus", "category": "zk-circuits", "targets": [ "Circom", "R1CS", "gnark", "Halo2 (via LLZK)", "Plonky3 (via LLZK)" ], "approach": "SMT (cvc5, Z3 with finite-field theory) uniqueness checking; fully automatic, no proofs to write", "license": "Open source (MIT); newer versions ship in Veridise AuditHub", "status": "Maintained; the Circom version is documented as legacy, LLZK-based Picus is current", "since": "2022", "summary": "Picus checks whether every output signal of a circuit is uniquely determined by its inputs, which is the automatic, specification-free way to detect underconstrained circuits. It runs on Circom, R1CS and gnark directly and on Halo2 and Plonky3 through LLZK, and Veridise has used it with LLZK to verify SP1 core operations and RISC Zero circuits.", "details": [ "The uniqueness property (sometimes called determinism or weak safety) is weaker than soundness: a circuit can be deterministic and still compute the wrong function. But it needs no specification, catches the dominant bug class, and finishes in minutes on many real circuits, which makes it the standard first pass in ZK audits.", "Picus can return 'unknown' when the solver times out, and proving uniqueness of non-deterministic-by-design gadgets requires annotation. Veridise's LLZK IR extended it beyond Circom in 2026." ], "strengths": [ "No specification, no proof engineering, fast on small and medium circuits.", "Broad frontend coverage through LLZK.", "Widely used and cited; the reference tool for its property." ], "limits": [ "Proves uniqueness, not functional correctness.", "Timeouts and 'unknown' results on large circuits.", "Cutting-edge features are in the commercial AuditHub version." ], "fit": [ "Run Picus on every Circom, gnark, Halo2 or Plonky3 circuit before an audit, and treat a clean result as necessary, not sufficient." ], "references": [ [ "Picus repository", "https://github.com/Veridise/Picus" ], [ "LLZK v1.0 announcement (2026-04-08)", "https://veridise.com/blog/veridise-announcements/llzk-v1-0-a-new-phase-for-zk-shared-infrastructure/" ] ], "page": "https://sorryfree.com/frameworks/picus/" }, { "slug": "llzk", "name": "LLZK", "tagline": "MLIR-based intermediate representation connecting ZK frontends to verification backends", "maintainer": "Veridise (Ethereum Foundation grant)", "url": "https://github.com/project-llzk", "repo": "https://github.com/project-llzk", "category": "zk-circuits", "targets": [ "Circom", "Halo2", "Plonky3", "Noir (in progress)" ], "approach": "Shared MLIR dialect; lowers to Picus, zkLean, R1CS and Rocq (via Formal Land's rocq-of-llzk)", "license": "Open source", "status": "Active, v1.0 released 2026-04-08", "summary": "LLZK is a shared intermediate representation for ZK circuits built on MLIR. Frontends for Circom, Halo2 and Plonky3 (Noir in progress) lower into it, and backends emit Picus queries, zkLean models, R1CS and Rocq via Formal Land's rocq-of-llzk, so one circuit can be checked automatically and then proved.", "details": [ "LLZK's value is interoperability: a team can start with Picus, then hand the same IR to zkLean or Rocq when a specification exists. Clean's roadmap lists LLZK integration for a Circom frontend, which would extend the same path to sound-and-complete proofs." ], "strengths": [ "Decouples frontend language from verification backend.", "Backed by an EF grant and adopted by Galois and Formal Land backends.", "Makes SP1 and RISC Zero style verification repeatable." ], "limits": [ "Infrastructure rather than a verifier; you still need a backend and a spec.", "Noir frontend incomplete at v1.0.", "Adds a translation step to the trusted computing base." ], "fit": [ "Adopt LLZK when you maintain circuits in more than one language or want to move from automatic checks to proofs without re-modelling." ], "references": [ [ "LLZK v1.0 announcement", "https://veridise.com/blog/veridise-announcements/llzk-v1-0-a-new-phase-for-zk-shared-infrastructure/" ], [ "project-llzk on GitHub", "https://github.com/project-llzk" ] ], "page": "https://sorryfree.com/frameworks/llzk/" }, { "slug": "garden", "name": "Garden", "tagline": "Formal Land's Rocq framework for Circom, Plonky3 and LLZK circuits", "maintainer": "Formal Land", "url": "https://github.com/formal-land/garden", "repo": "https://github.com/formal-land/garden", "category": "zk-circuits", "targets": [ "Circom", "Plonky3", "LLZK" ], "approach": "Rocq (Coq) proofs of determinism, functional correctness and completeness", "license": "Open source", "status": "Active", "summary": "Garden is Formal Land's Rocq framework for proving determinism, functional correctness and completeness of circuits written in Circom or Plonky3, and of anything lowered through LLZK via rocq-of-llzk.", "details": [ "Garden is the Rocq counterpart to the Lean frameworks: the same properties, a different prover and a team that also maintains rocq-of-rust and rocq-of-solidity, so a client can verify the circuit, the Rust prover code and the Solidity verifier in one ecosystem." ], "strengths": [ "States completeness explicitly.", "Same ecosystem as rocq-of-rust and rocq-of-solidity.", "LLZK backend gives it Halo2 reach." ], "limits": [ "Smaller public gadget library than Clean.", "Rocq talent pool is narrower than Lean's in ZK.", "Frontend coverage depends on LLZK for non-Circom inputs." ], "fit": [ "Choose Garden when your team or partner is Rocq-native or when you want Rust and Solidity verified alongside the circuit." ], "references": [ [ "Garden repository", "https://github.com/formal-land/garden" ], [ "Formal Land", "https://formal.land" ] ], "page": "https://sorryfree.com/frameworks/garden/" }, { "slug": "lampe", "name": "Lampe", "tagline": "Reilabs' Noir-to-Lean semantics extraction", "maintainer": "Reilabs", "url": "https://github.com/reilabs/lampe", "repo": "https://github.com/reilabs/lampe", "category": "zk-circuits", "targets": [ "Noir", "ACIR" ], "approach": "Semantics-first extraction of Noir programs into Lean 4, then property proofs", "license": "Open source", "status": "Active", "summary": "Lampe extracts the semantics of Noir programs into Lean 4 so that properties of Aztec-ecosystem circuits can be stated and proved. It is the main proof-assistant route for Noir; NAVe is the automatic alternative.", "details": [ "Reilabs previously built proven-zk and the gnark-lean-extractor, used to verify Worldcoin's Semaphore Merkle tree batcher. Lampe applies the same semantics-first approach to Noir's higher-level language." ], "strengths": [ "Only maintained proof-assistant path for Noir.", "Team has shipped verified production circuits (Worldcoin).", "Lean 4, so interoperable with the rest of the ecosystem." ], "limits": [ "Noir only.", "Semantics extraction is part of the TCB.", "Public examples still growing." ], "fit": [ "Choose Lampe for Noir or Aztec circuits that need proofs rather than automatic checks." ], "references": [ [ "Lampe repository", "https://github.com/reilabs/lampe" ], [ "Reilabs", "https://reilabs.io" ] ], "page": "https://sorryfree.com/frameworks/lampe/" }, { "slug": "proven-zk", "name": "proven-zk and gnark-lean-extractor", "tagline": "Lean 4 verification of gnark circuits", "maintainer": "Reilabs", "url": "https://github.com/reilabs/proven-zk", "repo": "https://github.com/reilabs/proven-zk", "category": "zk-circuits", "targets": [ "gnark", "R1CS" ], "approach": "Extract gnark circuits to Lean 4; prove properties with the proven-zk library", "license": "Open source", "status": "Maintained", "summary": "proven-zk is a Lean 4 library, with a companion gnark extractor, used by Reilabs to verify Worldcoin's Semaphore Merkle tree batcher circuits. The work surfaced a comparison bug in gnark itself.", "details": [ "The gnark-lean-extractor turns a Go gnark circuit into Lean definitions; proven-zk supplies lemmas for Poseidon, Merkle trees and bit decomposition so the resulting goals are provable. It is the reference example of verifying a deployed gnark circuit." ], "strengths": [ "Production track record (Worldcoin).", "Found a real bug in the underlying framework.", "Reusable lemma library for common gadgets." ], "limits": [ "gnark only.", "Extractor coverage of gnark APIs is partial.", "Less active than Lampe." ], "fit": [ "Choose it for gnark circuits, especially Merkle and Poseidon heavy ones." ], "references": [ [ "proven-zk repository", "https://github.com/reilabs/proven-zk" ] ], "page": "https://sorryfree.com/frameworks/proven-zk/" }, { "slug": "civer", "name": "CIVER", "tagline": "Modular SMT verification integrated in a Circom fork", "maintainer": "COSTA group, Universidad Complutense de Madrid (Albert Rubio et al.)", "url": "https://github.com/costa-group/circom_civer", "repo": "https://github.com/costa-group/circom_civer", "category": "zk-circuits", "targets": [ "Circom 2.1.6" ], "approach": "Z3-backed weak safety (determinism), tag specifications, pre- and post-conditions, verified bottom-up per template", "license": "Open source (GPL)", "status": "Research, maintained; R1CS, PLONK and ACIR support planned", "summary": "CIVER is a verifier built into a fork of the Circom compiler by the team behind Circom's own maintainers' academic group. It checks weak safety (every output determined by inputs), tag specifications and user-written pre- and post-conditions template by template, reusing results bottom-up so large circomlib-style codebases scale.", "details": [ "Because it runs inside the compiler, CIVER sees the circuit exactly as compiled, avoiding the extraction gap. Its post-condition mode is a lightweight route to functional properties without a proof assistant." ], "strengths": [ "No extraction step; verifies what the compiler emits.", "Modular, so circomlib-scale codebases are feasible.", "Supports functional pre- and post-conditions, not just determinism." ], "limits": [ "Circom only, pinned to a compiler version.", "SMT limits: timeouts on nonlinear-heavy templates.", "Academic maintenance cadence." ], "fit": [ "Run CIVER alongside Picus on Circom; use its post-conditions to state the properties an audit cares about." ], "references": [ [ "circom_civer repository", "https://github.com/costa-group/circom_civer" ] ], "page": "https://sorryfree.com/frameworks/civer/" }, { "slug": "circomspect", "name": "Circomspect", "tagline": "Trail of Bits' static analyzer and linter for Circom", "maintainer": "Trail of Bits", "url": "https://github.com/trailofbits/circomspect", "repo": "https://github.com/trailofbits/circomspect", "category": "zk-circuits", "targets": [ "Circom" ], "approach": "Static analysis of Circom source for unconstrained signals and unsafe patterns; SARIF output", "license": "Open source (GPL-3.0)", "status": "Maintained", "since": "2022", "summary": "Circomspect is a static analyzer for Circom that flags unconstrained signals, unused or shadowed variables, unsafe `<--` assignments and other patterns behind known circuit bugs. It is a linter, not a verifier: fast, easy to add to CI, and blind to bugs that do not match a pattern.", "details": [ "Circomspect belongs at the start of every Circom pipeline. It takes seconds, integrates with editors via SARIF, and catches the classes of mistake that dominate public ZK bug trackers. Treat its silence as the absence of known patterns, not the absence of bugs." ], "strengths": [ "Zero setup, runs in CI.", "Built by an audit firm from real findings.", "Good developer ergonomics." ], "limits": [ "Pattern-based; no semantic guarantee.", "Circom only.", "No completeness or soundness statement of any kind." ], "fit": [ "Use it always, before Picus, before an audit, before anything else." ], "references": [ [ "Circomspect repository", "https://github.com/trailofbits/circomspect" ] ], "page": "https://sorryfree.com/frameworks/circomspect/" }, { "slug": "zkfuzz", "name": "zkFuzz", "tagline": "Fuzzer for trace-constraint inconsistencies in Circom", "maintainer": "Hideaki Takahashi (Koukyosyumei)", "url": "https://github.com/Koukyosyumei/zkFuzz", "repo": "https://github.com/Koukyosyumei/zkFuzz", "category": "zk-circuits", "targets": [ "Circom" ], "approach": "Fuzzing for trace-constraint consistency (TCCT) violations between witness generation and constraints", "license": "Open source", "status": "Active research (IEEE S&P 2026)", "summary": "zkFuzz fuzzes Circom programs for disagreements between what witness generation computes and what the constraints enforce, the root of most underconstraint bugs. Its paper reports 66 bugs across 354 circuits.", "details": [ "Fuzzing complements SMT and proofs: it needs no specification, scales to circuits that time out solvers, and produces concrete counterexamples. It cannot prove absence of bugs." ], "strengths": [ "Concrete exploits, not warnings.", "Scales where solvers do not.", "Strong published results." ], "limits": [ "No guarantee on a clean run.", "Circom only.", "Single-maintainer research project." ], "fit": [ "Add zkFuzz when Picus times out or a circuit has heavy non-linear logic." ], "references": [ [ "zkFuzz repository", "https://github.com/Koukyosyumei/zkFuzz" ] ], "page": "https://sorryfree.com/frameworks/zkfuzz/" }, { "slug": "coda", "name": "Coda", "tagline": "Certified circuits via refinement types in Coq", "maintainer": "Junrui Liu, Işıl Dillig et al. (UT Austin, Veridise)", "url": "https://eprint.iacr.org/2023/547", "category": "zk-circuits", "targets": [ "Circom-style circuits reimplemented in Coda" ], "approach": "Refinement-typed circuit language generating Coq proof obligations", "license": "Research artifact", "status": "Research (2023), not actively developed", "summary": "Coda is a research language in which circuits carry refinement types; the type checker generates Coq lemmas whose proofs establish functional correctness. Its authors found six bugs in circomlib-derived circuits with it.", "details": [ "Coda is historically important: it showed that functional correctness of circomlib-style gadgets is provable with modest effort. Its ideas live on in Veridise's tooling and in the Lean frameworks." ], "strengths": [ "Clear methodology paper.", "Found real bugs.", "Refinement types keep specs close to code." ], "limits": [ "Requires rewriting circuits in Coda.", "No active maintenance.", "Coq only." ], "fit": [ "Read the paper for the methodology; use Clean, Garden or zkLean for new work." ], "references": [ [ "Certifying Zero-Knowledge Circuits with Refinement Types (ePrint 2023/547)", "https://eprint.iacr.org/2023/547" ] ], "page": "https://sorryfree.com/frameworks/coda/" }, { "slug": "ecne", "name": "Ecne", "tagline": "Early R1CS uniqueness checker in Julia", "maintainer": "Franklyn Wang (0xPARC)", "url": "https://github.com/franklynwang/EcneProject", "repo": "https://github.com/franklynwang/EcneProject", "category": "zk-circuits", "targets": [ "R1CS" ], "approach": "Rule-based propagation to prove output uniqueness of R1CS constraint sets", "license": "Open source (GPL-3.0)", "status": "Low activity research tool", "summary": "Ecne was the first widely used tool for proving that an R1CS constraint set uniquely determines its outputs, the property later automated with SMT by Picus. It remains useful as a lightweight second opinion on small R1CS systems.", "details": [ "Ecne propagates uniqueness through constraints with a set of rules rather than a solver, so it is fast but incomplete: a failure to prove uniqueness is not a bug report." ], "strengths": [ "Simple, fast, historically significant.", "Works directly on R1CS output of any compiler." ], "limits": [ "Incomplete rule set; many false negatives.", "Julia dependency; little maintenance.", "No functional properties." ], "fit": [ "Only as a cross-check; prefer Picus or CIVER." ], "references": [ [ "EcneProject repository", "https://github.com/franklynwang/EcneProject" ] ], "page": "https://sorryfree.com/frameworks/ecne/" }, { "slug": "nave", "name": "NAVe", "tagline": "Automatic proper-constrainedness checking for Noir", "maintainer": "Pedro Antonino, Namrata Jain", "url": "https://arxiv.org/abs/2601.09372", "category": "zk-circuits", "targets": [ "Noir", "ACIR" ], "approach": "cvc5 with finite-field SMT-LIB theories", "license": "Research", "status": "Research (January 2026)", "summary": "NAVe checks Noir programs for proper constrainedness using cvc5's finite-field theory, giving the Noir ecosystem an automatic underconstraint detector comparable to Picus for Circom.", "details": [ "Noir compiles to ACIR, which NAVe analyses directly. It is the automatic complement to Lampe's proof-assistant route." ], "strengths": [ "Automatic, no spec required.", "Targets Noir directly." ], "limits": [ "Young research tool.", "Solver limits on large programs.", "Determinism, not correctness." ], "fit": [ "Run it on Noir circuits as the first pass, then Lampe for proofs." ], "references": [ [ "NAVe paper (arXiv 2601.09372)", "https://arxiv.org/abs/2601.09372" ] ], "page": "https://sorryfree.com/frameworks/nave/" }, { "slug": "verified-cairo", "name": "Verified Cairo AIR (Stone and S-two)", "tagline": "StarkWare's Lean 4 soundness proofs of the Cairo VM AIR", "maintainer": "StarkWare with Jeremy Avigad and Yoav Seginer", "url": "https://arxiv.org/abs/2606.04311", "category": "zk-circuits", "targets": [ "Cairo VM AIR", "Stone", "S-two" ], "approach": "Lean 4 proofs that AIR satisfiability implies a correct Cairo execution; Sierra-to-CASM building blocks", "license": "Open source", "status": "Active (paper June 2026); in-house at StarkWare, not a service", "summary": "StarkWare, with Jeremy Avigad and Yoav Seginer, has proved in Lean 4 that satisfying the Cairo VM's AIR (for both the Stone and S-two provers) implies a correct Cairo execution, and in July 2026 used the same methodology to verify the STRK20 privacy pool with more than 230 theorems.", "details": [ "This is the longest-running production zkVM verification effort and the model for 'AIR soundness' work elsewhere. Nethermind's Horus, which verified Cairo 0 contracts with SMT, was archived on 2026-09-09; the Lean route is now the only maintained one for Cairo." ], "strengths": [ "Whole-VM soundness statement for a deployed prover.", "Long track record and academic rigour.", "Extended to an application (STRK20)." ], "limits": [ "Cairo specific and in-house.", "Not packaged as a reusable framework.", "Completeness is not the headline property." ], "fit": [ "If you build on Starknet, read the papers to understand what is and is not covered by StarkWare's proofs." ], "references": [ [ "Lean 4 soundness of the S-two Cairo AIR (arXiv 2606.04311)", "https://arxiv.org/abs/2606.04311" ], [ "STRK20 formal verification (2026-07-23)", "https://starkware.co/blog/strk20-formal-verification/" ], [ "Horus archived (2026-09-09)", "https://github.com/NethermindEth/horus-checker" ] ], "page": "https://sorryfree.com/frameworks/verified-cairo/" }, { "slug": "arklib", "name": "ArkLib", "tagline": "Lean 4 library for verifying SNARK components: IORs, sum-check, FRI, STIR, WHIR, Fiat-Shamir", "maintainer": "Verified-zkEVM (Quang Dao et al., Ethereum Foundation)", "url": "https://github.com/Verified-zkEVM/ArkLib", "repo": "https://github.com/Verified-zkEVM/ArkLib", "category": "proof-systems", "targets": [ "Interactive oracle reductions", "Sum-check", "Polynomial commitments", "FRI / STIR / WHIR", "Fiat-Shamir", "BCS" ], "approach": "Lean 4 with VCV-io for probabilistic reasoning; completeness and soundness of proof-system components", "license": "Open source", "status": "Active; Nethermind maintains an ArkLibFri fork", "summary": "ArkLib formalizes the building blocks of modern SNARKs in Lean 4: interactive oracle reductions and their composition, sum-check, polynomial commitment schemes, the FRI, STIR and WHIR proximity protocols, Fiat-Shamir and the BCS transform, with completeness and soundness theorems. It is the proof-system half of the Verified zkEVM program.", "details": [ "The Ethereum Foundation's December 2025 roadmap requires a formal soundness argument for recursion by the end of 2026; ArkLib is the vehicle. Its FRI work is also where the better.codes proximity bound feeds in, since the provable soundness of hash-based SNARKs depends on Reed-Solomon proximity results." ], "strengths": [ "Only library formalizing the actual proof-system components used in production zkEVMs.", "Lean 4, composable with Clean and other circuit proofs.", "Backed by the EF and Nethermind." ], "limits": [ "Research-shaped; APIs and coverage change quickly.", "Requires deep familiarity with both Lean and proof-system theory.", "Not a tool you point at a codebase." ], "fit": [ "Engage with ArkLib if you build a proof system or need a machine-checked soundness bound for recursion or a proximity protocol." ], "references": [ [ "ArkLib repository", "https://github.com/Verified-zkEVM/ArkLib" ], [ "EF zkEVM security roadmap (2025-12-18)", "https://blog.ethereum.org/2025/12/18/zkevm-security-foundations" ], [ "Verified zkEVM program", "https://verified-zkevm.org" ] ], "page": "https://sorryfree.com/frameworks/arklib/" }, { "slug": "easycrypt", "name": "EasyCrypt", "tagline": "Computational security proofs with relational Hoare logic", "maintainer": "Formosa Crypto (MPI-SP, Inria, Boston University, TU/e, Porto, Radboud)", "url": "https://easycrypt.info", "category": "proof-systems", "targets": [ "KEMs and signatures (ML-KEM, X-Wing)", "Hash functions (SHA-3)", "Curve arithmetic (X25519)", "ZK verifiers" ], "approach": "Interactive prover for game-based, code-based security proofs over probabilistic programs; paired with Jasmin for verified implementations", "license": "Open source", "status": "Active, mature", "summary": "EasyCrypt is the reference tool for machine-checked computational security proofs: game-based reductions expressed over probabilistic programs with a relational Hoare logic. It underpins the verified ML-KEM, X-Wing, SHA-3 and X25519 implementations in libjade, and Nethermind used it for the first honesty proof of a production ZK verifier (ZKsync).", "details": [ "EasyCrypt proofs mirror the structure of cryptographers' pen-and-paper arguments, which is both its strength (specialists can read and write them) and its cost (they are labour intensive). Its pairing with Jasmin is the most complete verified pipeline from security proof to constant-time assembly that exists." ], "strengths": [ "Proofs match how cryptographers reason.", "End-to-end with Jasmin: proof, spec and assembly agree.", "Post-quantum track record: ML-KEM and X-Wing." ], "limits": [ "Steep learning curve; small pool of practitioners.", "Proofs do not transfer automatically to code outside Jasmin.", "Not a circuit tool." ], "fit": [ "Choose EasyCrypt for a primitive or protocol that needs a computational proof reviewers will trust, or when shipping libjade-verified code." ], "references": [ [ "EasyCrypt", "https://easycrypt.info" ], [ "Formosa Crypto", "https://formosa-crypto.org" ] ], "page": "https://sorryfree.com/frameworks/easycrypt/" }, { "slug": "cryptoverif", "name": "CryptoVerif", "tagline": "Automatic game sequences in the computational model", "maintainer": "Bruno Blanchet, Inria (Prosecco)", "url": "https://bblanche.gitlabpages.inria.fr/CryptoVerif/", "category": "proof-systems", "targets": [ "Protocols: TLS 1.3, Signal, WireGuard", "Key exchange", "Authenticated encryption compositions" ], "approach": "Automatic and guided sequences of games with concrete security bounds", "license": "Open source", "status": "Active, mature", "summary": "CryptoVerif automates game-hopping proofs in the computational model, producing concrete security bounds for protocols. It has been applied to TLS 1.3, Signal and WireGuard and is the computational counterpart to ProVerif.", "details": [ "Where EasyCrypt is interactive and expressive, CryptoVerif is more automatic and best on protocol compositions. Many analyses run both a symbolic (ProVerif or Tamarin) and a computational (CryptoVerif) model of the same protocol." ], "strengths": [ "Automation reduces proof effort.", "Concrete bounds, not just yes/no.", "Long record on major protocols." ], "limits": [ "Less flexible than EasyCrypt for novel primitives.", "Modelling effort still significant.", "Small user community." ], "fit": [ "Choose CryptoVerif for protocol-level computational guarantees, especially hybrid post-quantum handshakes." ], "references": [ [ "CryptoVerif", "https://bblanche.gitlabpages.inria.fr/CryptoVerif/" ] ], "page": "https://sorryfree.com/frameworks/cryptoverif/" }, { "slug": "ssprove", "name": "SSProve", "tagline": "State-separating modular game-based proofs in Rocq", "maintainer": "Aarhus University, MPI-SP and others", "url": "https://github.com/SSProve/ssprove", "repo": "https://github.com/SSProve/ssprove", "category": "proof-systems", "targets": [ "Primitives and protocols in the computational model" ], "approach": "Rocq framework for state-separating proofs; hax backend available", "license": "Open source", "status": "Active research", "summary": "SSProve brings state-separating, modular game-based proofs to Rocq, letting large cryptographic proofs be assembled from packages. hax can target it from Rust, connecting implementations to proofs.", "details": [ "SSProve is the natural choice for teams already in Rocq who need computational proofs, and its hax backend is a bridge from production Rust." ], "strengths": [ "Modular proof structure scales.", "Rocq ecosystem and hax bridge.", "Foundationally rigorous." ], "limits": [ "Research maturity.", "Fewer worked examples than EasyCrypt.", "Requires Rocq expertise." ], "fit": [ "Choose SSProve when your verification stack is Rocq and you need computational proofs, not just implementation correctness." ], "references": [ [ "SSProve repository", "https://github.com/SSProve/ssprove" ] ], "page": "https://sorryfree.com/frameworks/ssprove/" }, { "slug": "prooffrog", "name": "ProofFrog", "tagline": "Checker for game-hopping proofs in provable security", "maintainer": "Ross Evans, Douglas Stebila (University of Waterloo)", "url": "https://github.com/ProofFrog/ProofFrog", "repo": "https://github.com/ProofFrog/ProofFrog", "category": "proof-systems", "targets": [ "Game-based security proofs (papers)" ], "approach": "Custom language (FrogLang) and checker for game transitions; MCP server for AI assistants", "license": "Open source", "status": "Research (2025)", "summary": "ProofFrog checks that the game transitions in a provable-security proof are valid, giving paper authors and reviewers a mechanical check on the skeleton of a reduction. It ships an MCP server so AI assistants can drive it.", "details": [ "It is lighter than EasyCrypt: it verifies the structure of the proof rather than the full semantics, which makes it fast to adopt for paper-style arguments." ], "strengths": [ "Low barrier for cryptographers.", "AI-assistant integration.", "Catches structural proof errors early." ], "limits": [ "Not a full computational prover.", "Research project.", "Limited primitive library." ], "fit": [ "Use ProofFrog while writing or reviewing a paper proof; move to EasyCrypt for a full mechanisation." ], "references": [ [ "ProofFrog repository", "https://github.com/ProofFrog/ProofFrog" ] ], "page": "https://sorryfree.com/frameworks/prooffrog/" }, { "slug": "squirrel", "name": "Squirrel", "tagline": "Computationally sound symbolic proofs", "maintainer": "Inria (Bana-Comon logic)", "url": "https://squirrel-prover.github.io", "category": "proof-systems", "targets": [ "Protocols" ], "approach": "Interactive prover in the computationally complete symbolic attacker model", "license": "Open source", "status": "Active research", "summary": "Squirrel proves protocol security in a symbolic-looking logic whose results are computationally sound, bridging the gap between Tamarin-style automation and EasyCrypt-style guarantees.", "details": [ "It remains a research tool, but it is the most promising route to computational guarantees with symbolic effort." ], "strengths": [ "Computational soundness with symbolic ergonomics.", "Interactive control." ], "limits": [ "Research maturity.", "Small community.", "Limited primitives." ], "fit": [ "Consider for protocol proofs where both automation and computational meaning matter." ], "references": [ [ "Squirrel prover", "https://squirrel-prover.github.io" ] ], "page": "https://sorryfree.com/frameworks/squirrel/" }, { "slug": "tamarin", "name": "Tamarin", "tagline": "Symbolic protocol verification with multiset rewriting", "maintainer": "ETH Zürich, CISPA, University of Oxford", "url": "https://tamarin-prover.com", "category": "symbolic-protocols", "targets": [ "TLS 1.3", "5G AKA", "WPA2", "Noise", "EMV", "Messaging protocols" ], "approach": "Symbolic (Dolev-Yao) analysis over unbounded sessions with user-guided lemmas", "license": "Open source", "status": "Active, mature", "summary": "Tamarin is the most widely used symbolic protocol verifier for stateful, multi-role protocols. It has analysed TLS 1.3, 5G authentication, WPA2, the Noise framework and EMV, and supports interactive guidance when automation stalls.", "details": [ "Tamarin models protocols as multiset rewriting rules and proves or refutes trace properties and observational equivalence. It handles loops, mutable state and Diffie-Hellman equational theories, which is why it dominates for real-world protocols." ], "strengths": [ "Most expressive of the automatic symbolic tools.", "Interactive mode for hard proofs.", "Largest record of real protocol findings." ], "limits": [ "Modelling skill required; non-termination is possible.", "Symbolic abstraction misses cryptographic weaknesses.", "No code connection." ], "fit": [ "Choose Tamarin for any protocol with state, multiple roles or Diffie-Hellman." ], "references": [ [ "Tamarin prover", "https://tamarin-prover.com" ] ], "page": "https://sorryfree.com/frameworks/tamarin/" }, { "slug": "proverif", "name": "ProVerif", "tagline": "Automatic symbolic analysis in the applied pi-calculus", "maintainer": "Bruno Blanchet, Inria (Prosecco)", "url": "https://bblanche.gitlabpages.inria.fr/proverif/", "category": "symbolic-protocols", "targets": [ "Protocols", "hax models extracted from Rust" ], "approach": "Symbolic analysis of applied pi-calculus models, unbounded sessions, largely automatic", "license": "Open source", "status": "Active, mature", "summary": "ProVerif automatically analyses protocol models in the applied pi-calculus for secrecy, authentication and equivalence properties over unbounded sessions. It has a large model base and is a target of hax, so Rust implementations can be analysed symbolically.", "details": [ "ProVerif is faster and more automatic than Tamarin at the cost of expressiveness for stateful protocols. The hax backend makes it the easiest symbolic tool to attach to a Rust codebase." ], "strengths": [ "High automation.", "hax backend from Rust.", "Decades of published models." ], "limits": [ "Weaker on global mutable state.", "Symbolic model only.", "May not terminate on some models." ], "fit": [ "Choose ProVerif for stateless or lightly stateful protocols and for Rust code via hax." ], "references": [ [ "ProVerif", "https://bblanche.gitlabpages.inria.fr/proverif/" ] ], "page": "https://sorryfree.com/frameworks/proverif/" }, { "slug": "verifpal", "name": "Verifpal", "tagline": "Developer-friendly symbolic protocol analysis", "maintainer": "Symbolic Software (Nadim Kobeissi)", "url": "https://verifpal.com", "category": "symbolic-protocols", "targets": [ "Protocols" ], "approach": "Symbolic analysis with an intentionally simple modelling language", "license": "Open source", "status": "Maintained", "summary": "Verifpal is a symbolic protocol analyser designed for engineers rather than formal-methods specialists. Its modelling language is deliberately simple, which limits expressiveness relative to Tamarin and ProVerif but lowers the barrier to a first model.", "details": [ "Verifpal is a good on-ramp; models often graduate to Tamarin or ProVerif when the protocol grows." ], "strengths": [ "Readable models.", "Fast feedback.", "Good documentation." ], "limits": [ "Less expressive.", "Fewer guarantees than the mature tools.", "Smaller community." ], "fit": [ "Use for first models and for teaching." ], "references": [ [ "Verifpal", "https://verifpal.com" ] ], "page": "https://sorryfree.com/frameworks/verifpal/" }, { "slug": "dystar", "name": "DY*", "tagline": "Symbolic protocol verification embedded in F* for executable code", "maintainer": "Inria, CISPA, University of Stuttgart", "url": "https://github.com/REPROSEC/dolev-yao-star", "repo": "https://github.com/REPROSEC/dolev-yao-star", "category": "symbolic-protocols", "targets": [ "Protocol implementations in F* (Signal, ACME)" ], "approach": "Dolev-Yao reasoning inside the F* proof assistant, over executable protocol code", "license": "Open source", "status": "Research, active", "summary": "DY* verifies protocol implementations written in F* against symbolic security properties, so the analysed model is the executable code. It has been applied to Signal and ACME and is the successor to ProScript.", "details": [ "DY* trades automation for precision: the properties hold of the code you run, not a hand-drawn model." ], "strengths": [ "No model-code gap.", "Composable with HACL* verified primitives." ], "limits": [ "F* implementation required.", "Research maturity.", "Manual proof effort." ], "fit": [ "Choose DY* when the implementation itself is in F* or can be." ], "references": [ [ "DY* repository", "https://github.com/REPROSEC/dolev-yao-star" ] ], "page": "https://sorryfree.com/frameworks/dystar/" }, { "slug": "jasmin", "name": "Jasmin and libjade", "tagline": "Verified high-speed assembly with constant-time guarantees", "maintainer": "Formosa Crypto", "url": "https://github.com/jasmin-lang/jasmin", "repo": "https://github.com/formosa-crypto/libjade", "category": "implementations", "targets": [ "ML-KEM (incl. AVX2)", "ML-DSA", "X-Wing", "Keccak / SHA-3", "X25519", "x86-64 assembly" ], "approach": "Verified compiler from a low-level language to assembly; correctness proved in EasyCrypt; constant-time checked", "license": "Open source", "status": "Active (Jasmin 2026.03.2 released July 2026)", "summary": "Jasmin is a language and verified compiler for writing cryptographic assembly whose functional correctness is proved in EasyCrypt and whose constant-time behaviour is checked by the compiler. libjade is the resulting library of verified implementations, including ML-KEM with AVX2 rejection sampling, ML-DSA, X-Wing, SHA-3 and X25519.", "details": [ "Jasmin is the only pipeline where the security proof (EasyCrypt), the functional spec and the shipped assembly are all connected by machine-checked steps. The mlkem-libjade AVX2 work was published at IEEE S&P 2025." ], "strengths": [ "Strongest end-to-end story: proof to assembly.", "Post-quantum coverage.", "Performance competitive with hand-written assembly." ], "limits": [ "Assembly must be written in Jasmin.", "x86-64 focus.", "Expertise concentrated in a few groups." ], "fit": [ "Choose Jasmin/libjade when you ship a primitive and want the verified implementation itself, not a proof about someone else's code." ], "references": [ [ "Jasmin repository", "https://github.com/jasmin-lang/jasmin" ], [ "libjade", "https://github.com/formosa-crypto/libjade" ], [ "Formosa Crypto", "https://formosa-crypto.org" ] ], "page": "https://sorryfree.com/frameworks/jasmin/" }, { "slug": "hax", "name": "hax", "tagline": "Rust to F*, Rocq, Lean, ProVerif, SSProve and EasyCrypt", "maintainer": "Cryspen", "url": "https://github.com/cryspen/hax", "repo": "https://github.com/cryspen/hax", "category": "implementations", "targets": [ "Rust", "libcrux ML-KEM and ML-DSA", "Protocol models (ProVerif)" ], "approach": "Translation of a large Rust subset into proof assistants; properties proved on the extracted model", "license": "Open source", "status": "Active; Lean backend under development with EF funding", "summary": "hax translates a large subset of Rust into F*, Rocq, ProVerif, SSProve and EasyCrypt, with a Lean backend in development. Cryspen used it to verify libcrux's ML-KEM (portable and AVX2 field arithmetic, NTT and serialization) in F*; libcrux ML-KEM ships in Mozilla and Signal.", "details": [ "hax keeps the Rust readable and moves the proof burden to the backend of your choice. It is also the tool at the centre of the February 2026 Verification Theatre paper, which found 13 vulnerabilities in libcrux and hpke-rs, four inside verified ML-KEM and ML-DSA code, all outside what the specifications stated. The lesson is not that hax failed but that the verification boundary must be published with the proof." ], "strengths": [ "Production Rust stays production Rust.", "Many backends, including symbolic (ProVerif).", "Shipped verified post-quantum code at scale." ], "limits": [ "Rust subset restrictions.", "Properties are only as good as the specification (Verification Theatre).", "Lean backend not yet complete." ], "fit": [ "Choose hax for Rust cryptographic libraries and ZK prover code where you want proofs without rewriting." ], "references": [ [ "hax repository", "https://github.com/cryspen/hax" ], [ "Cryspen: ML-KEM verification", "https://cryspen.com/post/ml-kem-verification/" ], [ "Verification Theatre (ePrint 2026/192)", "https://eprint.iacr.org/2026/192" ] ], "page": "https://sorryfree.com/frameworks/hax/" }, { "slug": "cryptol-saw", "name": "Cryptol and SAW", "tagline": "Specifications in Cryptol, equivalence proofs of C, LLVM, Java and x86 in SAW", "maintainer": "Galois", "url": "https://github.com/GaloisInc/saw-script", "repo": "https://github.com/GaloisInc/saw-script", "category": "implementations", "targets": [ "C / LLVM", "Java", "x86-64", "AWS-LC and s2n", "BLST", "Soroban (Formal Verso)" ], "approach": "Executable specifications in Cryptol; SAW proves implementations equivalent via SMT and symbolic simulation", "license": "Open source (BSD-3)", "status": "Active (SAW 1.4, Cryptol 3.4 in 2025)", "summary": "Cryptol is a specification language for cryptographic algorithms and SAW proves that C, LLVM, Java or x86 implementations match those specifications. Galois has used the pair on AWS s2n and AWS-LC (with NSym for AArch64), the BLST BLS library, Apple corecrypto and Stellar's Soroban.", "details": [ "SAW is the workhorse of industrial cryptographic verification in the United States. Its equivalence-checking style suits hand-optimised code that already exists; you write the spec, not the code." ], "strengths": [ "Verifies existing optimised code.", "Deep industrial track record (AWS, Apple).", "Executable specs double as test oracles." ], "limits": [ "SMT-bounded reasoning; loops and large state need care.", "Specification effort in Cryptol.", "Not a circuit tool (Galois's zkLean covers that)." ], "fit": [ "Choose Cryptol/SAW to verify existing C or assembly primitives against a spec, particularly in AWS-style environments." ], "references": [ [ "SAW", "https://github.com/GaloisInc/saw-script" ], [ "Cryptol", "https://tools.galois.com/cryptol" ], [ "AWS-LC verification", "https://github.com/awslabs/aws-lc-verification" ] ], "page": "https://sorryfree.com/frameworks/cryptol-saw/" }, { "slug": "fiat-crypto", "name": "Fiat-Crypto", "tagline": "Rocq-verified generation of field arithmetic", "maintainer": "MIT PLV", "url": "https://github.com/mit-plv/fiat-crypto", "repo": "https://github.com/mit-plv/fiat-crypto", "category": "implementations", "targets": [ "Finite-field arithmetic", "Curve25519", "P-256", "Custom primes" ], "approach": "Correct-by-construction code generation from Rocq proofs", "license": "Open source", "status": "Active, mature; deployed in BoringSSL and Go", "summary": "Fiat-Crypto generates field-arithmetic code (C, Rust, Go, Zig and more) from parameters with a Rocq proof that the output is correct. Its Curve25519 and P-256 code ships in BoringSSL and Go's standard library.", "details": [ "It is the clearest success of correct-by-construction cryptography: no one verifies the generated code because the generator is proved. It does not cover ML-KEM style polynomial arithmetic." ], "strengths": [ "Proved generator, no per-output proof needed.", "Massive deployment.", "Any prime, several languages." ], "limits": [ "Field arithmetic only.", "Performance below the best hand-written assembly.", "No post-quantum coverage." ], "fit": [ "Use it for any new curve or prime-field arithmetic, including ZK-friendly fields." ], "references": [ [ "Fiat-Crypto repository", "https://github.com/mit-plv/fiat-crypto" ] ], "page": "https://sorryfree.com/frameworks/fiat-crypto/" }, { "slug": "hacl-star", "name": "HACL*, Vale and EverCrypt", "tagline": "Project Everest's verified cryptographic library in F* and Vale", "maintainer": "Project Everest (Inria Prosecco, Microsoft Research, CMU)", "url": "https://hacl-star.github.io", "repo": "https://github.com/hacl-star/hacl-star", "category": "implementations", "targets": [ "C and assembly primitives", "Firefox NSS", "Linux kernel", "mbedTLS", "WireGuard" ], "approach": "Verified C extracted from F* (HACL*) and verified assembly (Vale), unified in EverCrypt", "license": "Open source", "status": "Maintained; post-quantum work moved to libcrux/hax", "summary": "HACL* is a library of cryptographic primitives verified in F* for memory safety, functional correctness and secret independence, with Vale providing verified assembly and EverCrypt a unified API. Its code runs in Firefox, the Linux kernel, mbedTLS and WireGuard.", "details": [ "HACL* proved that verified cryptography can be deployed at internet scale. Its lineage continues in libcrux and hax for post-quantum algorithms." ], "strengths": [ "Broadest deployment of any verified library.", "Memory safety, correctness and constant-time in one framework.", "Agile multiplexing in EverCrypt." ], "limits": [ "Classical primitives; post-quantum lives in libcrux.", "F* expertise required to extend.", "Extraction toolchain is complex." ], "fit": [ "Use HACL* when you need verified classical primitives as a library; use hax/libcrux for post-quantum." ], "references": [ [ "HACL*", "https://hacl-star.github.io" ] ], "page": "https://sorryfree.com/frameworks/hacl-star/" }, { "slug": "aeneas", "name": "Aeneas", "tagline": "Rust to Lean, F* and Rocq translation via Charon", "maintainer": "Inria (Son Ho) and AeneasVerif", "url": "https://github.com/AeneasVerif/aeneas", "repo": "https://github.com/AeneasVerif/aeneas", "category": "implementations", "targets": [ "Rust", "Plonky3 and RISC Zero code (2026 pipeline paper)" ], "approach": "Functional translation of Rust into pure models for Lean, F* or Rocq", "license": "Open source", "status": "Active", "summary": "Aeneas translates Rust into pure functional models for Lean, F* or Rocq through the Charon frontend. A May 2026 pipeline paper used it with hax, ArkLib and CompPoly, plus AI provers, to verify Plonky3 FRI folding and field arithmetic and RISC Zero Merkle checks.", "details": [ "Aeneas is the Lean-native route from Rust prover code to the same ecosystem as Clean and ArkLib, which makes it central to verifying the Rust that implements ZK proof systems." ], "strengths": [ "Lean-first, integrates with ArkLib and Clean.", "Demonstrated on real prover code.", "Handles ownership-heavy Rust well." ], "limits": [ "Rust subset limitations.", "Translation is in the TCB.", "Younger than hax in production use." ], "fit": [ "Choose Aeneas for Rust proof-system code that you want to verify in Lean alongside circuits." ], "references": [ [ "Aeneas repository", "https://github.com/AeneasVerif/aeneas" ], [ "Rust-to-Lean pipeline paper (arXiv 2605.30106)", "https://arxiv.org/abs/2605.30106" ] ], "page": "https://sorryfree.com/frameworks/aeneas/" }, { "slug": "kani", "name": "Kani", "tagline": "Bounded model checker for Rust", "maintainer": "AWS", "url": "https://github.com/model-checking/kani", "repo": "https://github.com/model-checking/kani", "category": "implementations", "targets": [ "Rust", "Rust standard library verification challenge", "AWS Rust libraries" ], "approach": "Bounded model checking (CBMC backend) for panics, memory safety and user assertions", "license": "Open source (Apache-2.0 / MIT)", "status": "Active", "summary": "Kani is AWS's bounded model checker for Rust. It proves absence of panics, undefined behaviour and violated assertions within loop bounds, with no specification language to learn, and is used across AWS's Rust libraries and the Rust standard library verification challenge.", "details": [ "Kani is the cheapest meaningful verification for Rust ZK and cryptographic code: unsafe blocks, arithmetic overflow and indexing errors are exactly what it catches." ], "strengths": [ "Low effort, high value on unsafe and arithmetic code.", "Concrete counterexamples.", "AWS-backed, well maintained." ], "limits": [ "Bounded: no guarantee beyond the unwinding depth.", "No functional correctness against a cryptographic spec.", "Struggles with large state spaces." ], "fit": [ "Run Kani on every Rust crate in a prover or library; pair with hax or Aeneas for correctness." ], "references": [ [ "Kani repository", "https://github.com/model-checking/kani" ] ], "page": "https://sorryfree.com/frameworks/kani/" }, { "slug": "cbmc", "name": "CBMC", "tagline": "Bounded model checker for C, used on mlkem-native and s2n", "maintainer": "Diffblue, AWS and community", "url": "https://github.com/diffblue/cbmc", "repo": "https://github.com/diffblue/cbmc", "category": "implementations", "targets": [ "C", "mlkem-native", "s2n" ], "approach": "Bounded model checking for memory safety and assertions", "license": "Open source (BSD-4)", "status": "Active, mature", "summary": "CBMC is the bounded model checker behind Kani and the memory-safety proofs of mlkem-native and AWS s2n. It proves absence of memory errors and assertion failures in C within loop bounds.", "details": [ "mlkem-native pairs CBMC memory-safety proofs with s2n-bignum functional proofs, a pragmatic model for post-quantum C libraries." ], "strengths": [ "Mature and widely deployed.", "Concrete counterexamples.", "No spec needed for memory safety." ], "limits": [ "Bounded.", "No functional correctness.", "Modelling effort for harnesses." ], "fit": [ "Use CBMC on C cryptographic code for memory safety before any deeper verification." ], "references": [ [ "CBMC repository", "https://github.com/diffblue/cbmc" ] ], "page": "https://sorryfree.com/frameworks/cbmc/" }, { "slug": "cryptoline", "name": "CryptoLine", "tagline": "Verification of low-level arithmetic assembly", "maintainer": "Academia Sinica (Bow-Yaw Wang)", "url": "https://github.com/fmlab-iis/cryptoline", "repo": "https://github.com/fmlab-iis/cryptoline", "category": "implementations", "targets": [ "Bignum and NTT assembly", "OpenSSL", "BoringSSL", "wolfSSL", "PQC NTTs" ], "approach": "Algebraic and range reasoning on straight-line arithmetic code", "license": "Open source", "status": "Active research", "summary": "CryptoLine verifies straight-line arithmetic assembly such as bignum multiplication and NTT butterflies, and has been applied to OpenSSL, BoringSSL, wolfSSL and post-quantum NTT implementations.", "details": [ "Its algebraic approach scales to code where SMT alone struggles, which is why it is used on the hot loops of production libraries." ], "strengths": [ "Handles large arithmetic kernels.", "Applied to production libraries.", "Complements SAW-style equivalence." ], "limits": [ "Straight-line code only.", "Specialist tool.", "Academic maintenance." ], "fit": [ "Use CryptoLine for the arithmetic kernels of a classical or post-quantum library." ], "references": [ [ "CryptoLine repository", "https://github.com/fmlab-iis/cryptoline" ] ], "page": "https://sorryfree.com/frameworks/cryptoline/" }, { "slug": "verus", "name": "Verus", "tagline": "SMT-based verifier for Rust", "maintainer": "CMU, Microsoft and community", "url": "https://github.com/verus-lang/verus", "repo": "https://github.com/verus-lang/verus", "category": "implementations", "targets": [ "Rust (systems and some cryptographic code)" ], "approach": "Ghost specifications and SMT-discharged proofs in Rust itself", "license": "Open source (MIT)", "status": "Active", "summary": "Verus lets developers write specifications and proofs inside Rust and discharges them with an SMT solver, giving full functional correctness without a separate proof assistant.", "details": [ "Verus is strongest on systems code; cryptographic use is growing. It is an option for teams that want proofs in the same language as the implementation." ], "strengths": [ "Specs and code in one language.", "High automation.", "Active community." ], "limits": [ "SMT limits on nonlinear field arithmetic.", "Requires writing Verus-flavoured Rust.", "Less cryptographic precedent than hax." ], "fit": [ "Consider Verus for new Rust components where the team wants in-language verification." ], "references": [ [ "Verus repository", "https://github.com/verus-lang/verus" ] ], "page": "https://sorryfree.com/frameworks/verus/" }, { "slug": "lean4", "name": "Lean 4 and Mathlib", "tagline": "The proof assistant the ZK verification ecosystem has standardised on", "maintainer": "Lean FRO and the Mathlib community", "url": "https://lean-lang.org", "category": "provers", "targets": [ "Clean", "zkLean", "Halva", "ArkLib", "sp1-lean", "Lampe", "EvmYul", "Cairo AIR proofs" ], "approach": "Interactive theorem prover with a small trusted kernel, a large mathematics library and a growing AI-prover ecosystem", "license": "Open source (Apache-2.0)", "status": "Active", "summary": "Lean 4 is the proof assistant behind nearly every ZK verification project funded in 2025 and 2026: Clean, zkLean, Halva, ArkLib, sp1-lean, Lampe, proven-zk, Nethermind's EVM model and StarkWare's Cairo proofs. Mathlib supplies the finite-field and polynomial mathematics, and AI proving tools now target it.", "details": [ "Choosing Lean fixes the hiring pool, the reusable libraries and the interoperability with everything else on this index. The kernel is small; the axioms a project uses (and whether it relies on `native_decide`) are the things to check when reading a Lean result, which is why zk.golf enforces an axiom allowlist." ], "strengths": [ "De facto standard for ZK proofs.", "Mathlib depth for field and polynomial arithmetic.", "Best AI-assistant support of any prover." ], "limits": [ "Proof engineering cost.", "Fast-moving toolchain; pin versions.", "Trusted axioms must be audited per project." ], "fit": [ "Default choice for any new circuit or proof-system verification." ], "references": [ [ "Lean", "https://lean-lang.org" ], [ "Introduction to interactive theorem provers (zkSecurity, 2025-02-04)", "https://blog.zksecurity.xyz/posts/introduction-to-interactive-theorem-provers/" ] ], "page": "https://sorryfree.com/frameworks/lean4/" }, { "slug": "rocq", "name": "Rocq (formerly Coq)", "tagline": "Proof assistant behind Fiat-Crypto, SSProve, Garden and rocq-of-rust", "maintainer": "Inria and the Rocq community", "url": "https://rocq-prover.org", "category": "provers", "targets": [ "Fiat-Crypto", "SSProve", "Garden", "rocq-of-rust", "rocq-of-solidity" ], "approach": "Interactive theorem prover based on the calculus of inductive constructions", "license": "Open source (LGPL)", "status": "Active", "summary": "Rocq, the renamed Coq, underpins Fiat-Crypto's verified field arithmetic, SSProve's computational proofs, Formal Land's Garden circuit framework and its rocq-of-rust and rocq-of-solidity translators. It is the main alternative to Lean for cryptographic verification.", "details": [ "Rocq's strength in cryptography is its implementation-verification lineage. CertiCrypt, the ancestor of EasyCrypt, was built on it." ], "strengths": [ "Mature, stable, well documented.", "Strong extraction to executable code.", "Formal Land's Rust and Solidity translators." ], "limits": [ "ZK ecosystem momentum is with Lean.", "Steeper syntax for newcomers.", "Fewer circuit-specific libraries." ], "fit": [ "Choose Rocq when your team or partner is Rocq-native, or to reuse Fiat-Crypto and rocq-of-rust." ], "references": [ [ "Rocq", "https://rocq-prover.org" ] ], "page": "https://sorryfree.com/frameworks/rocq/" }, { "slug": "isabelle", "name": "Isabelle/HOL", "tagline": "Proof assistant used by Apple to verify corecrypto ML-KEM and ML-DSA", "maintainer": "TU München and University of Cambridge", "url": "https://isabelle.in.tum.de", "category": "provers", "targets": [ "C and ARM64 via AutoCorres2", "Apple corecrypto" ], "approach": "Higher-order logic with strong automation; refinement via AutoCorres2", "license": "Open source (BSD)", "status": "Active", "summary": "Isabelle/HOL is the prover Apple used with AutoCorres2, SAW and Cryptol to verify the ML-KEM and ML-DSA implementations in corecrypto (published 2026). It offers strong automation and a refinement methodology for C.", "details": [ "Apple's corecrypto work is the largest public post-quantum verification effort by a device vendor and a reference for refinement-based methodology." ], "strengths": [ "Powerful automation (sledgehammer).", "AutoCorres2 for C refinement.", "Industrial precedent (seL4, corecrypto)." ], "limits": [ "Little ZK ecosystem presence.", "Different culture and libraries from Lean/Rocq.", "Refinement setups are heavyweight." ], "fit": [ "Choose Isabelle for C or ARM64 refinement proofs in the seL4 tradition." ], "references": [ [ "Apple corecrypto", "https://github.com/apple/corecrypto" ], [ "Isabelle", "https://isabelle.in.tum.de" ] ], "page": "https://sorryfree.com/frameworks/isabelle/" }, { "slug": "fstar", "name": "F*", "tagline": "Dependently typed language behind HACL*, hax and DY*", "maintainer": "Microsoft Research and Inria", "url": "https://fstar-lang.org", "category": "provers", "targets": [ "HACL*", "hax (main backend)", "DY*", "libcrux" ], "approach": "Dependently typed effectful programming with SMT automation; extraction to C and OCaml", "license": "Open source (Apache-2.0)", "status": "Active", "summary": "F* is the dependently typed language in which HACL* and libcrux proofs are written and the primary backend of hax. It combines proof-assistant expressiveness with SMT automation and extracts to C.", "details": [ "Most shipped verified cryptography (Firefox, Signal, Linux) was proved in F*. Its SMT-heavy style can make proofs brittle across versions, which projects mitigate with careful lemma hints." ], "strengths": [ "Largest body of deployed verified crypto.", "Automation via Z3.", "Extraction to C." ], "limits": [ "Proof brittleness under solver changes.", "Smaller community than Lean.", "Not used for circuits." ], "fit": [ "Choose F* when building on HACL* or verifying Rust via hax's default backend." ], "references": [ [ "F*", "https://fstar-lang.org" ] ], "page": "https://sorryfree.com/frameworks/fstar/" }, { "slug": "acl2", "name": "ACL2 (R1CS and PFCS books)", "tagline": "Mature prime-field constraint verification with light tactics", "maintainer": "ACL2 community (Kestrel Institute)", "url": "https://www.cs.utexas.edu/~moore/acl2/", "category": "provers", "targets": [ "R1CS", "Prime-field constraint systems", "acl2-jolt" ], "approach": "First-order logic with strong automation; R1CS and PFCS libraries; acl2-jolt for Jolt circuits", "license": "Open source (BSD)", "status": "Mature, niche", "summary": "ACL2 has a mature library for R1CS and prime-field constraint systems and an acl2-jolt project. zkSecurity's 2025 comparison found it the lightest on tactic effort among circuit frameworks, at the cost of a smaller ecosystem.", "details": [ "ACL2's automation suits repetitive constraint proofs; its niche status limits hiring and library reuse." ], "strengths": [ "Least proof effort per gadget in published comparisons.", "Long history in hardware verification." ], "limits": [ "Small ZK community.", "First-order logic limits expressiveness.", "Less interoperability with Lean projects." ], "fit": [ "Consider ACL2 if you have ACL2 expertise or need to verify many similar constraint templates." ], "references": [ [ "zkSecurity comparison (2025-11-19)", "https://blog.zksecurity.xyz/posts/formal-verification-arithmetic-circuits/" ] ], "page": "https://sorryfree.com/frameworks/acl2/" }, { "slug": "k-framework", "name": "K framework and KEVM", "tagline": "Executable semantics for the EVM and zkVM equivalence work", "maintainer": "Runtime Verification", "url": "https://kframework.org", "category": "provers", "targets": [ "EVM (KEVM)", "zkevm-harness", "Lean backend for K" ], "approach": "Rewriting-based semantics from which interpreters, symbolic executors and provers are derived", "license": "Open source", "status": "Active, mature", "summary": "K is a semantics framework in which KEVM defines the EVM executably. Runtime Verification uses it in the Verified zkEVM program for the zkevm-harness and for proving equivalence between KEVM and Nethermind's Lean EvmYul model.", "details": [ "For zkEVMs, the K semantics is the reference against which circuit behaviour is compared, making it part of the specification layer rather than the proof layer." ], "strengths": [ "Executable and provable from one definition.", "KEVM is battle tested.", "Lean backend bridges to the ZK ecosystem." ], "limits": [ "Specialist tooling.", "Not a circuit verifier.", "Heavy for small projects." ], "fit": [ "Use K when you need an executable, provable ISA or VM specification." ], "references": [ [ "K framework", "https://kframework.org" ], [ "Verified zkEVM overview", "https://github.com/Verified-zkEVM/Overview" ] ], "page": "https://sorryfree.com/frameworks/k-framework/" }, { "slug": "certora-prover", "name": "Certora Prover", "tagline": "SMT-based verification of smart contracts, including ZK verifier contracts", "maintainer": "Certora", "url": "https://github.com/Certora/CertoraProver", "repo": "https://github.com/Certora/CertoraProver", "category": "provers", "targets": [ "Solidity", "Vyper", "Solana (Rust)", "Move", "Soroban" ], "approach": "Rule-based specification (CVL) discharged by SMT over bytecode", "license": "Open source (2025)", "status": "Active", "summary": "Certora Prover verifies smart contracts against rules written in CVL, on EVM, Solana, Move and Soroban. It is the tool to verify the on-chain verifier and bridge logic around a ZK system; it does not verify circuits.", "details": [ "Open-sourced in 2025, it is the most used contract-level prover. Halmos and hevm are lighter symbolic alternatives." ], "strengths": [ "Production usage across DeFi.", "Multi-chain.", "Open source with commercial support." ], "limits": [ "Not cryptography-specific.", "SMT timeouts on complex invariants.", "Rules must be written and reviewed." ], "fit": [ "Use it for the verifier contract, bridge and upgrade logic of a ZK deployment." ], "references": [ [ "CertoraProver repository", "https://github.com/Certora/CertoraProver" ] ], "page": "https://sorryfree.com/frameworks/certora-prover/" }, { "slug": "zk-golf", "name": "zk.golf", "tagline": "Competition for the cheapest ZK circuits proven sound and complete in Lean 4", "title": "zk.golf: circuit optimisation challenges with Lean 4 proofs of soundness and completeness", "maintainer": "zkSecurity", "url": "https://zk.golf", "repo": "https://github.com/zksecurity/zk-golf-challenges", "category": "challenges", "targets": [ "R1CS over BN254", "GF(2) hash compression track", "Clean circuits" ], "approach": "Fixed Lean interface and specification per challenge; submissions are Clean circuits plus kernel-checked proofs; score = allocations + constraints", "license": "Open challenge; challenges repository public", "status": "Active (launched 2026-07-02)", "since": "2026-07-02", "summary": "zk.golf is zkSecurity's competition to build the cheapest zero-knowledge circuits that are proven correct in Lean 4. Each challenge fixes a Lean specification; a submission is a Clean circuit plus a proof that it is sound and complete against it, kernel-checked in a sandbox (20-minute timeout, no native_decide, axiom allowlist). Challenges include SHA-256, Keccak-f[1600], RSA PKCS#1 v1.5 verification, secp256k1 scalar multiplication and GF(2) BLAKE3 and KangarooTwelve compression.", "details": [ "Because completeness is required alongside soundness, the specification pins the circuit down exactly, so aggressive optimisation, including by LLM agents (an agent API is documented at zk.golf/llms.txt), cannot silently break correctness. Score is allocations plus constraints, lower is better, and each challenge lists comparison points against existing libraries such as circomlib, zk-email, gnark and circom-ecdsa.", "For a team considering formal verification, zk.golf is the fastest way to see what a sound-and-complete deliverable looks like and how much circuit cost verified optimisation can remove. A challenge submission establishes only the challenge's required properties, not the security of any surrounding system." ], "strengths": [ "Every leaderboard entry is a kernel-checked proof, not a claim.", "Realistic targets: SHA-256, Keccak, RSA, secp256k1.", "Designed for AI-agent participation under a fixed spec." ], "limits": [ "Challenge scope only; not an audit of your code.", "Clean and Lean 4 required.", "Young platform (July 2026)." ], "fit": [ "Use zk.golf to learn Clean, benchmark a gadget, or recruit verified-circuit engineers. The operator, [zkSecurity](/firms/zksecurity/), runs it alongside its verification practice." ], "references": [ [ "zk.golf", "https://zk.golf" ], [ "Announcing zk.golf (2026-07-02)", "https://blog.zksecurity.xyz/posts/zkgolf/" ], [ "Challenge registry", "https://github.com/zksecurity/zk-golf-challenges" ] ], "page": "https://sorryfree.com/frameworks/zk-golf/" }, { "slug": "better-codes", "name": "better.codes", "tagline": "Open autoresearch challenge to raise a Lean-checked Reed-Solomon proximity soundness bound", "title": "better.codes: the Proximity Prize soundness challenge with Lean 4 checked submissions", "maintainer": "Ethereum Foundation Formal Verification team, Yukon and zkSecurity", "url": "https://better.codes", "category": "challenges", "targets": [ "koalaIRS12 proximity problem", "FRI / STIR / WHIR soundness", "Lean 4" ], "approach": "A formalised open problem from the Proximity Prize; solvers point AI agents at improving the machine-checked lower bound; every submission is kernel-checked and promoted proofs are credited", "license": "Open challenge; program terms on the site", "status": "Active (launched 2026-08-20)", "since": "2026-08-20", "summary": "better.codes is an open autoresearch challenge built by the Ethereum Foundation Formal Verification team with Yukon and zkSecurity. A self-contained problem from the Proximity Prize (koalaIRS12, a Reed-Solomon proximity question that governs the provable soundness of hash-based SNARKs such as FRI, STIR and WHIR) is formalised in Lean 4, and solvers direct AI agents at raising the proven soundness lower bound. As of 2026-09-13 the bound stood at 68.07 bits against a 128-bit target, up from a 64-bit literature baseline, with 74 promoted submissions from 22 solvers.", "details": [ "Every submission is checked by the Lean kernel; promoted proofs are upstreamed and credited to the solver and the model used. The attack (upper) bound on the same problem is 116.13 bits, so the gap between what is proven and what is believed is the object of the challenge.", "The Proximity Prize is a $1M Ethereum Foundation research fund for list-decoding and correlated-agreement bounds for Reed-Solomon codes; Yukon is an autoresearch platform operated by Eigen Labs. better.codes matters to this index because it is the first public venue where AI-driven proving on a cryptographic bound is measured with a kernel rather than a leaderboard of claims." ], "strengths": [ "Machine-checked progress on a bound that decides real SNARK security levels.", "Public, dated, attributed results.", "Demonstrates AI-assisted proving under kernel discipline." ], "limits": [ "A single problem, not a general tool.", "Requires Lean 4 and proximity-testing expertise to contribute meaningfully.", "Bound remains far from the 128-bit target." ], "fit": [ "Follow better.codes if your security argument depends on FRI, STIR or WHIR soundness, or if you want to see how AI provers perform on real cryptography." ], "references": [ [ "better.codes", "https://better.codes" ], [ "Ethereum Foundation announcement (2026-08-20)", "https://blog.ethereum.org/en/2026/08/20/better-codes-challenge" ], [ "Proximity Prize", "https://proximityprize.org" ], [ "Yukon", "https://www.yukon.org" ] ], "page": "https://sorryfree.com/frameworks/better-codes/" }, { "slug": "verified-zkevm", "name": "Verified zkEVM program", "tagline": "The Ethereum Foundation program funding Lean verification of zkVMs and their proof systems", "maintainer": "Ethereum Foundation", "url": "https://verified-zkevm.org", "repo": "https://github.com/Verified-zkEVM/Overview", "category": "challenges", "targets": [ "Clean", "zkLean", "Halva", "ArkLib", "LLZK", "Sail RISC-V Lean", "KEVM equivalence", "hax Lean backend" ], "approach": "Grants and coordination for a formally verified, bug-free zk(E)VM stack, targeted for 2027", "license": "Program; individual projects are open source", "status": "Active", "summary": "The Verified zkEVM program is the Ethereum Foundation initiative that funds and coordinates most of the ZK verification tooling on this index: Clean (zkSecurity), zkLean (Galois), Halva (Nethermind), ArkLib, LLZK (Veridise), the Sail RISC-V Lean model, KEVM equivalence work (Runtime Verification), VCV-io and hax's Lean backend (Cryspen), with a stated goal of formally verified zk(E)VMs by 2027.", "details": [ "The program's December 2025 security roadmap sets dated targets: soundcalc integration by February 2026, 100-bit provable security by May 2026, 128-bit security and a formal soundness argument for recursion by the end of 2026. Its Overview repository is the best single map of who verifies what." ], "strengths": [ "Single source of truth for funded, interoperable projects.", "Dated public milestones.", "Independent reviews (for example of sp1-lean) published openly." ], "limits": [ "Ethereum-centric scope.", "Program, not a tool.", "Milestones can slip; check dates." ], "fit": [ "Read the Overview before choosing a framework; alignment with the program is the strongest predictor of maintenance and interoperability." ], "references": [ [ "Verified zkEVM", "https://verified-zkevm.org" ], [ "Overview repository", "https://github.com/Verified-zkEVM/Overview" ], [ "EF zkEVM security roadmap (2025-12-18)", "https://blog.ethereum.org/2025/12/18/zkevm-security-foundations" ] ], "page": "https://sorryfree.com/frameworks/verified-zkevm/" } ]