Sigvex
ZKSecurity2 min read

ZK Verifier Audit

Check a deployed on-chain ZK verifier against the circuit it should accept — scan its bytecode for embedded constants and compare them to the expected verifying-key commitments.

Open ZK Dual-Layer Verifier AuditAll guides
zkverifieraudit

ZK Verifier Audit checks whether a deployed verifier still matches the circuit it is supposed to accept proofs for. It scans the verifier’s bytecode for the constants baked into it and compares them against the verifying-key commitments you expect — so a verifier that was swapped, upgraded, or misconfigured shows up before anyone trusts it.

Why it exists

A verifier is the trust anchor of a ZK system: if the deployed contract accepts proofs from the wrong circuit, every proof it validates is meaningless. That failure is invisible from the outside — the contract still “verifies.” This page makes it visible by reading the commitments embedded in the actual bytecode and holding them against the expected set, so a stale or unknown key is caught at audit time.

Who uses it

  • Auditor — confirms a deployed verifier’s bytecode still matches the expected commitments.
  • Protocol engineer — re-audits a verifier after a proxy upgrade or a redeploy.

How to open it

  1. Sidebar → Cryptography → ZK Verifier Audit.
  2. Direct URL — /zk-verifier.

Running an audit

  1. Pick the deployed verifier contract from the workspace.
  2. Scan bytecode to extract the embedded 32-byte constants.
  3. Enter the expected VK commitments — add a row per commitment, or load a sample scenario (all keys match, a key missing, or no expected keys) to see how each verdict reads.
  4. Read the result: the VK correspondence table shows each expected commitment’s match status, the findings give the overall verdict, and the embedded constants list shows everything pulled from the bytecode.

A missing expected key (“stale”) is the signal to investigate whether the verifier was swapped; no expected keys (“unknown”) just means you haven’t supplied the set to compare against yet.

Limits

  • Requires a signed-in account and audits deployed on-chain verifier bytecode.
  • The audit compares embedded constants to the expected commitments — it confirms the verifier is bound to the keys you expect; it does not re-prove the verifier’s own correctness.
  • Noir Analyzer — the source-level analysis that produces the expected commitments.
  • ZK Studio — the full studio for circuit analysis.
  • Upgrade Simulator — catches the proxy upgrades that could swap a verifier.