[
  {
    "slug": "circuit-soundness",
    "term": "Circuit soundness",
    "tools": [
      "clean",
      "zklean",
      "halva",
      "garden"
    ],
    "definition": "A circuit is sound with respect to a specification if every witness that satisfies its constraints also satisfies the specification, so a malicious prover cannot produce an accepting proof of a false statement.",
    "detail": [
      "Soundness is the property that rules out underconstrained circuits, and it is what most ZK verification efforts prove first. Because the adversary chooses the witness, a soundness argument must consider every satisfying assignment, not only the ones an honest witness generator produces.",
      "Soundness alone is not enough: a circuit with no satisfying assignments is vacuously sound. That is why Clean and zk.golf require completeness alongside it, and why a soundness-only theorem should be read together with tests showing the circuit accepts honest inputs."
    ],
    "page": "https://sorryfree.com/glossary/circuit-soundness/"
  },
  {
    "slug": "circuit-completeness",
    "term": "Circuit completeness",
    "tools": [
      "clean",
      "garden",
      "zk-golf"
    ],
    "definition": "A circuit is complete with respect to a specification if every input the specification allows has a satisfying witness, so an honest prover is never blocked from proving a true statement.",
    "detail": [
      "Completeness failures are availability bugs: a wallet that cannot spend, a bridge that cannot finalise, a rollup that cannot include a legitimate transaction. They are less discussed than soundness bugs because they do not lose funds directly, but they are common when constraints are tightened during a fix.",
      "A sound-and-complete theorem pins the circuit to its specification exactly, which is what allows untrusted optimisation, including by AI agents, without loss of correctness."
    ],
    "page": "https://sorryfree.com/glossary/circuit-completeness/"
  },
  {
    "slug": "underconstrained-circuit",
    "term": "Underconstrained circuit",
    "tools": [
      "picus",
      "civer",
      "circomspect",
      "zkfuzz",
      "nave"
    ],
    "definition": "A circuit whose constraints admit witnesses outside the specification, typically because a value computed during witness generation is never pinned down by a constraint. It is the dominant class of exploitable ZK bug.",
    "detail": [
      "In Circom the classic form is a `<--` assignment without a matching `===` constraint; in Halo2 it is a cell that is assigned but not gated; in any system it is a missing range check, a missing boolean check or a division by a possibly-zero value. Automatic tools (Picus, CIVER, NAVe) detect many instances by checking that outputs are uniquely determined by inputs; a soundness proof rules out all of them."
    ],
    "page": "https://sorryfree.com/glossary/underconstrained-circuit/"
  },
  {
    "slug": "overconstrained-circuit",
    "term": "Overconstrained circuit",
    "definition": "A circuit that rejects inputs the specification allows, so honest provers fail. It is the failure of completeness.",
    "detail": [
      "Overconstraint often appears after a security fix adds a constraint that is stricter than intended, or when a gadget assumes a range the caller does not guarantee. Completeness proofs and honest-path test vectors catch it."
    ],
    "page": "https://sorryfree.com/glossary/overconstrained-circuit/"
  },
  {
    "slug": "symbolic-vs-computational",
    "term": "Symbolic vs computational model",
    "tools": [
      "tamarin",
      "proverif",
      "easycrypt",
      "cryptoverif"
    ],
    "definition": "The symbolic (Dolev-Yao) model treats cryptographic primitives as perfect black boxes and searches for logical attacks automatically; the computational model reasons about probabilistic polynomial-time adversaries and concrete security bounds, matching cryptographers' proofs.",
    "detail": [
      "Symbolic tools (Tamarin, ProVerif, Verifpal) are fast and find protocol-logic flaws over unbounded sessions but cannot see weaknesses inside primitives. Computational tools (EasyCrypt, CryptoVerif, SSProve) give the guarantee a cryptographer expects at far higher effort. Squirrel attempts to combine them. Most serious protocol analyses use one of each."
    ],
    "page": "https://sorryfree.com/glossary/symbolic-vs-computational/"
  },
  {
    "slug": "specification-gap",
    "term": "Specification gap",
    "definition": "A mismatch between the property that was formally proved and the property that was actually needed, so a valid proof fails to cover real behaviour.",
    "detail": [
      "The public example is sp1-lean's JALR theorem, which assumed a 4-byte-aligned jump target and therefore did not cover legitimate programs; the Ethereum Foundation disclosed the bug in May 2026. The Verification Theatre paper documents the same phenomenon in verified ML-KEM code. Reading the theorem statements and assumptions is as important as checking that the proof compiles."
    ],
    "page": "https://sorryfree.com/glossary/specification-gap/"
  },
  {
    "slug": "trusted-computing-base",
    "term": "Trusted computing base and verification boundary",
    "definition": "Everything that must be correct for a proof to mean what it claims: the prover kernel, the axioms used, the extraction or translation from code to model, the specification itself, and any unverified glue code. The edge of that set is the verification boundary.",
    "detail": [
      "A responsible verification deliverable lists its TCB explicitly: which Lean axioms, whether `native_decide` was used, how constraints were extracted from the codebase, and what surrounding code is unverified. zk.golf enforces an axiom allowlist for exactly this reason. Ask every vendor for the boundary in writing."
    ],
    "page": "https://sorryfree.com/glossary/trusted-computing-base/"
  },
  {
    "slug": "proof-assistant-vs-smt",
    "term": "Proof assistant vs SMT-based verifier",
    "tools": [
      "lean4",
      "picus",
      "certora-prover",
      "kani"
    ],
    "definition": "A proof assistant (Lean, Rocq, Isabelle, F*) checks human- or AI-written proofs against a small kernel and can express arbitrary mathematics; an SMT-based verifier (Picus, CIVER, Certora Prover, Kani) discharges properties automatically but only within decidable fragments and may return 'unknown'.",
    "detail": [
      "The practical trade: SMT tools give results in minutes with no proof engineering and no specification (for determinism) but time out on large or nonlinear problems; proof assistants scale to any property and any size at the cost of expert time. Mature pipelines use both: automatic checks first, proofs for what matters most."
    ],
    "page": "https://sorryfree.com/glossary/proof-assistant-vs-smt/"
  },
  {
    "slug": "bounded-model-checking",
    "term": "Bounded model checking",
    "tools": [
      "kani",
      "cbmc"
    ],
    "definition": "Exhaustive exploration of all program executions up to a fixed depth or loop bound, reporting concrete counterexamples; sound only within the bound.",
    "detail": [
      "Kani and CBMC are the cheapest verification most cryptographic Rust and C code will ever get: memory safety, absence of panics and user assertions with no specification language. They are not proofs of correctness against a cryptographic spec."
    ],
    "page": "https://sorryfree.com/glossary/bounded-model-checking/"
  },
  {
    "slug": "equivalence-checking",
    "term": "Equivalence checking",
    "tools": [
      "cryptol-saw",
      "cryptoline",
      "k-framework"
    ],
    "definition": "Proving that two artifacts compute the same function, for example optimised assembly against a Cryptol reference, or the KEVM semantics against a Lean EVM model.",
    "detail": [
      "Equivalence checking is how existing optimised code gets verified without rewriting it. Its limit is that the reference must itself be trusted or verified."
    ],
    "page": "https://sorryfree.com/glossary/equivalence-checking/"
  },
  {
    "slug": "refinement",
    "term": "Refinement",
    "definition": "A relation showing that an implementation's behaviours are a subset of a more abstract specification's behaviours, layered so low-level code refines a high-level model.",
    "detail": [
      "Refinement is the methodology of seL4, AutoCorres2 and Apple's corecrypto proofs, and of Coda's refinement types for circuits. It lets a proof be split into stages that different people can own."
    ],
    "page": "https://sorryfree.com/glossary/refinement/"
  },
  {
    "slug": "constant-time-verification",
    "term": "Constant-time verification",
    "tools": [
      "jasmin",
      "hacl-star"
    ],
    "definition": "Proving that a program's control flow and memory access pattern do not depend on secret data, so timing and cache side channels cannot leak keys.",
    "detail": [
      "Jasmin checks it in the compiler; HACL* proves secret independence in F*; AWS-LC's assembly is verified constant-time. Functional correctness proofs do not imply it: the KyberSlash timing bugs were in code that computed the right answer."
    ],
    "page": "https://sorryfree.com/glossary/constant-time-verification/"
  },
  {
    "slug": "arithmetization",
    "term": "Arithmetization (R1CS, PLONKish, AIR)",
    "definition": "The encoding of a computation as polynomial constraints over a finite field: rank-1 constraint systems (Groth16, gnark), PLONKish gates with copy and lookup constraints (Halo2), or algebraic intermediate representations over execution traces (STARKs, Plonky3, SP1).",
    "detail": [
      "Verification frameworks are tied to arithmetizations: Picus and Ecne to R1CS, Halva to PLONKish, Clean primarily to AIR with PLONK and R1CS support, StarkWare's proofs to the Cairo AIR. Check the framework page for the exact model before assuming coverage."
    ],
    "page": "https://sorryfree.com/glossary/arithmetization/"
  },
  {
    "slug": "extraction",
    "term": "Extraction (code to model)",
    "tools": [
      "halva",
      "hax",
      "aeneas",
      "llzk"
    ],
    "definition": "The step that turns a deployed circuit or program into the object a prover reasons about, whether by instrumenting synthesis (Halva), compiling to an IR (LLZK), or translating source (hax, Aeneas).",
    "detail": [
      "Extraction is part of the trusted computing base unless the extractor is itself verified. Frameworks that avoid it (Clean, where the Lean circuit is the source; CIVER, which runs inside the compiler) trade it for a code-generation or correspondence step instead."
    ],
    "page": "https://sorryfree.com/glossary/extraction/"
  },
  {
    "slug": "witness-generation-vs-constraints",
    "term": "Witness generation vs constraints",
    "definition": "Witness generation is the program that computes a satisfying assignment for honest inputs; constraints are what the verifier actually checks. Bugs arise when the two disagree.",
    "detail": [
      "Most underconstraint bugs are exactly a disagreement: witness generation computes the intended value, constraints fail to enforce it. zkFuzz targets this gap directly; soundness proofs make the constraints authoritative."
    ],
    "page": "https://sorryfree.com/glossary/witness-generation-vs-constraints/"
  }
]