{
  "type": "failure-mode",
  "name": "Mistaking a mock prover run for a soundness check",
  "slug": "mistaking-a-mock-prover-run-for-a-soundness-check",
  "section": {
    "id": "audit",
    "number": "03",
    "title": "Auditing a ZK protocol",
    "url": "https://zkpick.com/audit/"
  },
  "url": "https://zkpick.com/audit/failure-modes/mistaking-a-mock-prover-run-for-a-soundness-check/",
  "markdown": "https://zkpick.com/md/audit/failure-modes/mistaking-a-mock-prover-run-for-a-soundness-check.md",
  "detail": "A circuit development framework's mock or simulation prover confirms that the assigned witness satisfies the gates. It does not search for a second satisfying assignment, so it cannot detect underconstraint — yet a passing run is routinely read as evidence the circuit is correct. Related traps in the same family include missing copy constraints between regions and logic masked during key generation when values are unknown.",
  "mitigation": "Understand exactly what your framework's test prover checks, and pair it with negative tests that mutate the witness and assert rejection, plus automated uniqueness analysis. Never treat a green mock prover run as a soundness result.",
  "relatedOptions": [
    {
      "name": "Automated underconstraint detection",
      "url": "https://zkpick.com/audit/automated-underconstraint-detection/"
    }
  ],
  "updated": "2026-09-12",
  "version": "1.3",
  "canonical": "https://zkpick.com/audit/failure-modes/mistaking-a-mock-prover-run-for-a-soundness-check/",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "authors": [
    "MarketComp"
  ]
}