[ { "slug": "zk-circuits", "name": "ZK circuit verification", "short": "circuit verification", "title": "ZK circuit formal verification frameworks: Clean, zkLean, Halva, Picus, LLZK and others compared", "summary": "Frameworks that prove or check that a zero-knowledge circuit (R1CS, PLONKish, AIR, Circom, Noir, Halo2, Cairo) does what its specification says. Proof-assistant frameworks (Clean, zkLean, Halva, sp1-lean, Garden, Lampe) produce machine-checked soundness and sometimes completeness theorems; SMT and static tools (Picus, CIVER, Circomspect, zkFuzz) find underconstrained signals automatically but do not prove absence of bugs.", "intro": [ "Almost every exploitable bug found in production ZK systems is a circuit that accepts a witness it should reject. Verification of a circuit therefore centres on one question: does the set of satisfying assignments equal the set of behaviours the specification allows? Frameworks answer it at different strengths. A soundness theorem in Lean or Rocq answers it for all inputs; a uniqueness check from an SMT solver answers a narrower question (is every signal determined by the inputs?) for the circuit as compiled; a linter answers only for known patterns.", "The 2026 landscape has consolidated on Lean 4 for proof-assistant work, largely through the Ethereum Foundation's Verified zkEVM program, which funds Clean, zkLean, Halva, ArkLib, LLZK and several extraction pipelines. Shared infrastructure now exists: LLZK provides a common IR from Circom, Halo2 and Plonky3 frontends into Picus, zkLean and Rocq, and Clean is used as the substrate for Succinct's sp1-lean." ], "choose": [ "Writing a new circuit and want it verified from day one: use **Clean** (AIR, PLONK, R1CS; sound and complete gadgets; Rust codegen on the roadmap) or **zkLean** (R1CS and lookup-based, Jolt-style).", "Verifying an existing Halo2 circuit: **Halva**. An existing Noir program: **Lampe** or **NAVe**. An existing gnark circuit: **proven-zk**. An existing Circom circuit: **Picus** or **CIVER** for automatic checks, **Garden** or **Coda** for proofs.", "Verifying a zkVM instruction set: **sp1-lean** (SP1, on Clean), **Clean Channels** for multi-table systems, or StarkWare's **Verified Cairo AIR** approach.", "Need something automatic today, proofs later: run **Picus** or **zkFuzz** now, feed the same circuits through **LLZK** into a proof backend when the specification is written.", "Require completeness as well as soundness (the circuit must never reject a valid input): only Clean, zk.golf submissions, Garden and CIVER's completeness mode state it explicitly; check the theorem statements of anything else." ], "page": "https://sorryfree.com/categories/zk-circuits/", "tools": [ "clean", "sp1-lean", "zklean", "halva", "picus", "llzk", "garden", "lampe", "proven-zk", "civer", "circomspect", "zkfuzz", "coda", "ecne", "nave", "verified-cairo" ] }, { "slug": "proof-systems", "name": "Proof systems and computational proofs", "short": "proof-system verification", "title": "Formal verification of proof systems and cryptographic security proofs: ArkLib, EasyCrypt, CryptoVerif, SSProve, ProofFrog", "summary": "Frameworks for machine-checking the cryptographic argument itself: knowledge soundness of a polynomial IOP, the security reduction of a KEM, or the game-hopping proof in a paper. These work in the computational model, where the adversary is a probabilistic polynomial-time algorithm and security is a concrete bound, and they are the only tools on this index that verify the proof system rather than the circuit inside it.", "intro": [ "A verified circuit is only as good as the proof system that compiles it. Sum-check, FRI, STIR and WHIR, Fiat-Shamir transforms and polynomial commitment schemes all carry pen-and-paper soundness proofs that have historically contained errors. Two families of tools address this. ArkLib formalizes interactive oracle reductions and their composition in Lean 4, targeting the SNARK components the Ethereum Foundation cares about. EasyCrypt, CryptoVerif and SSProve are general computational provers, used for KEMs, signatures, TLS and, in one production case, a ZK verifier's honesty proof.", "Expect these projects to be slower and more research-shaped than circuit verification. The payoff is that they close the gap between a verified circuit and a verified system, which is why the Ethereum Foundation's 2025 zkEVM security roadmap requires a formal soundness argument for recursion by the end of 2026." ], "choose": [ "Verifying a SNARK component (sum-check, FRI/STIR/WHIR, polynomial commitments, Fiat-Shamir): **ArkLib**, in Lean 4, with VCV-io for probabilistic reasoning.", "Proving a primitive or protocol secure in the computational model with a team that already writes game-based proofs: **EasyCrypt** (paired with Jasmin for verified code) or **SSProve** in Rocq.", "Automating a game sequence for a protocol like TLS, Signal or WireGuard: **CryptoVerif**.", "Checking that a paper's game-hopping proof is well-formed: **ProofFrog**.", "Proving a soundness bound for a Reed-Solomon proximity problem: the **better.codes** challenge is the live venue, with Lean-checked submissions." ], "page": "https://sorryfree.com/categories/proof-systems/", "tools": [ "arklib", "easycrypt", "cryptoverif", "ssprove", "prooffrog", "squirrel" ] }, { "slug": "symbolic-protocols", "name": "Symbolic protocol analysis", "short": "protocol analysis", "title": "Symbolic protocol verification tools: Tamarin, ProVerif, Verifpal, DY* compared", "summary": "Automatic analyzers that model a protocol with perfect (Dolev-Yao) cryptography and search for attacks over unbounded sessions: authentication failures, key-compromise impersonation, downgrade, replay and unknown-key-share. Tamarin and ProVerif are the standard tools; Verifpal trades expressiveness for approachability; DY* embeds the analysis in F* for executable code.", "intro": [ "Symbolic tools do not reason about probabilities or bit-level cryptography. They treat encryption, signatures and hashes as perfect and ask whether the protocol logic itself is broken. That abstraction makes them fast and largely automatic, and it is exactly the level at which most real protocol bugs live: a missing binding of the transcript, an identity that is never authenticated, a state machine that accepts an old message.", "For a ZK or cryptographic product, symbolic analysis is the right first pass for the protocol layer that sits around the proofs: session setup, key exchange, message ordering, and any hybrid post-quantum negotiation. It does not verify the proof system or the circuit." ], "choose": [ "Stateful or complex protocols with many roles (TLS, 5G, Noise, EMV): **Tamarin**, which offers the most control and the best published track record.", "Fast automatic analysis with a large existing model base and unbounded sessions: **ProVerif**.", "A developer team writing its first model: **Verifpal**, then port to Tamarin or ProVerif when the model grows.", "Analysis that must stay attached to the implementation: DY* in F*, or hax's ProVerif backend from Rust." ], "page": "https://sorryfree.com/categories/symbolic-protocols/", "tools": [ "tamarin", "proverif", "verifpal", "dystar" ] }, { "slug": "implementations", "name": "Verified implementations", "short": "implementation verification", "title": "Verified cryptographic implementations: Jasmin, hax, Cryptol/SAW, Fiat-Crypto, HACL*, CryptoLine, Kani compared", "summary": "Frameworks that prove properties of the code that ships: functional correctness against a specification, memory safety, and constant-time behaviour, for C, Rust, assembly and generated field arithmetic. This is where post-quantum verification happens in practice: ML-KEM and ML-DSA implementations in libjade, libcrux, AWS-LC, mlkem-native and Apple corecrypto all carry machine-checked proofs from tools in this category.", "intro": [ "A verified specification is not a verified deployment. Implementation-level tools connect the two, either by generating code from a proof (Fiat-Crypto, Jasmin), by proving hand-written code equivalent to a spec (Cryptol/SAW, CryptoLine, HACL*), or by extracting a model from production Rust into a prover (hax, Aeneas). Bounded model checkers (Kani, CBMC) sit at the cheaper end: they prove memory safety and absence of panics within loop bounds, with no specification needed.", "Two lessons from 2026 shape how to read this category. Verified code has shipped at scale (Firefox, Linux, Go, BoringSSL, Signal, AWS). And verification has a boundary: the February 2026 Verification Theatre paper documented 13 vulnerabilities in verified libraries, four inside code covered by proofs, all caused by properties that were never specified. Ask every implementation-verification vendor to state the boundary." ], "choose": [ "High-speed assembly for a primitive with a matching EasyCrypt proof: **Jasmin** and **libjade**.", "Production Rust that must stay readable: **hax** (to F*, Rocq, Lean, ProVerif) or **Aeneas** (to Lean), with **Kani** for panic and memory-safety proofs on the rest.", "Hand-optimised C or assembly against a reference: **Cryptol and SAW**, **CryptoLine** for bignum and NTT arithmetic, **CBMC** for memory safety.", "Field arithmetic for a new curve or field: **Fiat-Crypto** generates it with a proof.", "A whole verified library rather than a proof of your own code: HACL* / EverCrypt or **libcrux**." ], "page": "https://sorryfree.com/categories/implementations/", "tools": [ "jasmin", "hax", "cryptol-saw", "fiat-crypto", "hacl-star", "aeneas", "kani", "cbmc", "cryptoline", "verus" ] }, { "slug": "provers", "name": "Proof assistants and general verifiers", "short": "proof engineering", "title": "Proof assistants and general verifiers used in cryptography: Lean 4, Rocq, Isabelle, F*, ACL2, K, Certora Prover", "summary": "The foundations underneath the specialised frameworks: interactive proof assistants (Lean 4, Rocq, Isabelle/HOL, F*, ACL2), a semantics framework (K), and SMT-based verifiers for smart contracts (Certora Prover, Halmos, hevm). Choosing one fixes the ecosystem, the available libraries, the hiring pool and, increasingly, which AI proving tools can help.", "intro": [ "In 2026 the ZK ecosystem has largely settled on Lean 4: Clean, zkLean, Halva, ArkLib, sp1-lean, Lampe, proven-zk, Nethermind's EVM model and StarkWare's Cairo proofs are all Lean. Rocq remains strong for implementation verification (Fiat-Crypto, Formal Land's rocq-of-rust and Garden, SSProve), Isabelle appears in Apple's corecrypto proofs, F* underpins HACL* and hax, and ACL2 has a mature but niche prime-field constraint library.", "Smart-contract verifiers are listed here because ZK verifiers deploy on-chain. Certora Prover, Halmos and hevm check the Solidity or bytecode around a verifier contract; none of them verifies the circuit." ], "choose": [ "New ZK verification project in 2026: **Lean 4**. The libraries, the funded projects and the AI provers are there.", "Rust implementation verification with a Rocq team, or reuse of Fiat-Crypto: **Rocq**.", "C and ARM64 code with a refinement-style methodology: **Isabelle/HOL** with AutoCorres2, as Apple did.", "Executable semantics that both runs and proves (EVM, zkVM ISAs): the **K framework**.", "On-chain verifier contract properties: **Certora Prover** for full rule-based verification, **Halmos** or **hevm** for bounded symbolic checks." ], "page": "https://sorryfree.com/categories/provers/", "tools": [ "lean4", "rocq", "isabelle", "fstar", "acl2", "k-framework", "certora-prover" ] }, { "slug": "challenges", "name": "Challenges and programs", "short": "verified-circuit", "title": "Formal verification challenges and programs for ZK: zk.golf, better.codes, Verified zkEVM", "summary": "Live venues where verified artifacts are produced competitively or under a coordinated program: zk.golf (cheapest circuit with a Lean proof of soundness and completeness), better.codes (raise a Lean-checked soundness bound for Reed-Solomon proximity), and the Ethereum Foundation's Verified zkEVM program that funds most of the frameworks on this index.", "intro": [ "Two 2026 launches turned formal verification into a spectator sport. zk.golf scores circuits by allocations plus constraints, but a submission only counts if its Lean proof of soundness and completeness kernel-checks in a sandbox. better.codes hands AI agents a formalised open problem from the Proximity Prize and promotes every proof that improves the machine-checked bound. Both are useful to a team that wants to learn what a verified deliverable looks like before commissioning one.", "The Verified zkEVM program is the funding and coordination layer behind Clean, zkLean, Halva, ArkLib, LLZK, the Sail RISC-V Lean model, KEVM equivalence and hax's Lean backend, with a stated goal of formally verified zk(E)VMs by 2027." ], "choose": [ "Learn how a sound-and-complete circuit proof is structured, or benchmark an optimisation: **zk.golf**.", "Contribute to or watch AI-assisted theorem proving on a real cryptographic bound: **better.codes**.", "Track which frameworks are funded, maintained and interoperable: the **Verified zkEVM** program page and its Overview repository." ], "page": "https://sorryfree.com/categories/challenges/", "tools": [ "zk-golf", "better-codes", "verified-zkevm" ] } ]