1. The Third Stop for Trust: From "Trust the Operator" to "Trust a Piece of Math"

The second piece in this series noted that model inference's non-reproducibility ultimately degrades verification into "trusting the operator's self-attestation" — it says the model judged this way, and you just have to believe it. zkML tries to break that deadlock: it expresses a model's inference process — matrix multiplications, activation functions, the data flow between layers — as an arithmetic circuit, then uses a zero-knowledge proof system (SNARK- or STARK-based, for example) to produce a proof claiming "this specific input, run through this specific model (identified by a hash or commitment to its weights), did in fact produce this specific output." Anyone holding the verification key can then check that proof on-chain, at a small fraction of the compute cost of re-running the whole model, and confirm it holds. This is another shift in where trust lands — from "trust that a centralized operator isn't cheating" to "trust that the cryptographic assumptions and implementation behind the zero-knowledge proof system have no flaws."

Where's the value in this shift? It turns verification from a process that requires re-running expensive computation and trusting an execution environment, into something anyone can complete cheaply and deterministically — in theory, once a proof passes, you no longer need to trust that whoever submitted it was honest. But researchers need to be clear-eyed: this only moves trust from one place to another, it doesn't eliminate trust itself. The cryptographic assumptions of the proof system, the correctness of the circuit's implementation, the trusted setup used to generate the proof — these are new trust objects that equally need scrutiny, and they're often more opaque and require more specialized expertise to audit than the simpler question of "is the operator honest."

  • zkML compiles model inference into a zero-knowledge circuit, producing a cryptographic proof verifiable cheaply on-chain that a specific input did produce a specific output through a specific model.
  • Trust shifts from "is the operator honest" to "are the proof system's cryptographic assumptions and circuit implementation correct" — it is relocated, not eliminated.
  • The starting point for verification is recognizing this shift itself, not treating "uses zero-knowledge proofs" as equivalent to "no longer needs to trust anyone."

2. The Quantization Cost of Circuit Compilation: The Provable Model May Not Be the Original

Fitting a neural network into a zero-knowledge circuit is far from just rewriting the code in a different language. Zero-knowledge proof systems are naturally suited to integer arithmetic over finite fields, while mainstream neural network inference defaults to floating point, and large models' parameter counts are unfriendly to circuit size — the number of "gates" in a circuit directly drives proof generation time and cost, often growing super-linearly with model size. To keep proof generation within acceptable time and cost, practice generally requires "quantizing" the model: compressing floating-point weights and activations into low-bit-width integer approximations, sometimes also trimming layers or swapping certain nonlinear activation functions for circuit-friendlier approximations.

This creates an easily overlooked verification gap: what gets a proof generated for it is often not the original model researchers assume, but a quantized, approximated, structurally altered "circuit version" of it. This circuit version may match the original model's behavior on most inputs, but on edge cases or precision-sensitive judgments, quantization error can push the conclusion in a different direction — and that divergence never shows up in the proof's validity, because the proof verifies that "the circuit executed correctly," while how closely the circuit resembles the original model is an engineering choice made by whoever built it, not something cryptographic proof covers. Verifiers should ask: has the quantization error between the circuit version being proved and the original model advertised to the public been independently assessed and disclosed? Are there decision scenarios where the circuit version and the original model would diverge?

  • Neural network inference defaults to floating point; zero-knowledge circuits favor integer arithmetic, and larger models scale circuit size unfavorably.
  • Practice generally requires quantizing, trimming, and approximating nonlinear functions to keep proof-generation cost manageable.
  • Verification gap: what's proved is a quantized approximation of the model — whether its divergence from the original has been independently assessed and disclosed, and whether it diverges on edge-case inputs.

3. The Boundary of the Proof: "Correctly Executed" Isn't "Correctly Judged"

This is the point most often misread about zkML, and it echoes closely what this series concluded about TEEs in the second piece. A zero-knowledge proof can deterministically tell you: given this input and this committed set of model weights, the circuit did faithfully execute the computation, and the output was in fact derived this way, with no step swapped out along the way. It proves "computational integrity." But it cannot answer two other equally critical questions: whether the input itself is genuine and unaltered raw material, and whether the model's judgment is factually correct. If the input fed into the circuit is a forged satellite image or tampered text, the zero-knowledge proof will faithfully prove "the circuit did compute this conclusion based on this forged input" — the proof itself is entirely valid, and the conclusion is still wrong.

Further, even with genuine input, the model itself may carry systematic bias or be fooled by an adversarial sample, arriving at a conclusion that is "correctly executed" in the proof's sense but "incorrectly judged" in the factual sense. The zero-knowledge proof can only guarantee that "this possibly flawed model did run through faithfully" — it makes no claim about the quality of the model's judgment. When evaluating any product claiming to use zkML, researchers should clearly separate which layer the marketing phrase "verifiable on-chain" actually verifies — if the messaging implies "proof passed = conclusion trustworthy," that conflates computational integrity with factual correctness, two entirely different properties.

  • Zero-knowledge proofs deterministically prove "computational integrity": the circuit executed correctly, the output genuinely derived from the claimed input and model.
  • They cannot prove the input itself is genuine, nor that the model's judgment is factually correct — bad input or a biased model still gets faithfully proven.
  • Verifiers should be wary of messaging that equates "proof passed" with "conclusion trustworthy" — these belong to computational integrity and factual correctness respectively.

4. Circuits and Trusted Setup: Where the New Trust Roots Hide

Zero-knowledge proof systems aren't abstract math that's trustworthy by default either — their security rests on a series of concrete engineering and cryptographic prerequisites that also need scrutiny. First is the correctness of the circuit implementation itself — has the code that translates model inference logic into circuit constraints been independently audited? A flawed circuit could let an attacker craft a fake proof that "appears to verify but doesn't actually correspond to the claimed input and output" — this class of bug tends to be extremely subtle and hard to spot without formal verification or deep auditing. Second, some zero-knowledge proof schemes (particularly earlier SNARK constructions) rely on a one-time "trusted setup" ceremony to generate public parameters; if the participating parties collude, or the setup process leaves a backdoor, the security of every proof generated from those parameters is weakened — which is why a multi-party, publicly verifiable setup ceremony is considered more trustworthy than one generated by a single party.

Verifiers should treat both of these as the "new trust roots" of a zkML system and ask: has the circuit code been publicly and independently audited, and is the audit report available for review? If the scheme relies on trusted setup, how was that ceremony conducted, were participants sufficiently diverse, and was the process publicly verifiable? These questions, stacked alongside the quantization cost and proof boundary discussed in sections 2 and 3, together form a complete verification picture of a zkML system — zero-knowledge proofs solve the trust problem of "is the operator honest," but in doing so they introduce a new layer of trust — "are the circuit and setup trustworthy" — that requires the same rigor of scrutiny, rather than eliminating trust altogether.

  • Independent auditing of the circuit implementation is the first new trust root to check — a flawed circuit can allow forged proofs that "pass verification" without corresponding to reality.
  • Some proof schemes depend on a one-time trusted setup ceremony; participant diversity and public verifiability directly affect the security of every proof generated afterward.
  • Zero-knowledge proofs relocate trust from "is the operator honest" to "is the circuit and setup trustworthy" — a shift, not an elimination, and it demands equally rigorous scrutiny.

5. Positioning Alongside TEEs and Multi-Source Arbitration: What Gap Does zkML Fill

Comparing zkML with the trusted execution environments (TEEs) covered in the second piece of this series makes their complementary — rather than overlapping — boundaries clearer. TEEs rely on hardware-level isolation and remote attestation to let you trust that "the code ran on this input inside an untampered environment"; zkML relies on cryptography to let you trust that "the computation behind this proof was in fact executed according to the claimed circuit logic" — both only answer the layer of "was execution tampered with," and neither answers "is the input real" or "is the model's judgment correct." Their respective weaknesses also differ: TEEs depend on a hardware vendor's root of trust and have a history of side-channel attacks; zkML depends on the correctness of circuit implementation and trusted setup, and at the current stage, proof generation cost for large models remains significant, often requiring a tradeoff between model size and provability.

As a result, a robust on-chain trusted model execution design rarely expects zkML to carry the whole weight alone — instead it treats zkML as one candidate implementation for the "execution integrity" layer, then stacks the multi-source cross-checking and challengeable adjudication mechanisms discussed in the second piece of this series to cover the two gaps neither zkML nor TEEs can close: whether the input is genuine, and whether the judgment is correct. When evaluating any on-chain model service claiming to use zkML, verifiers should ask: exactly which stretch of the process does zkML cover in this system — full model inference, or some simplified sub-module? Does the system also stack independent multi-source cross-checking or a human-challenge mechanism to handle input forgery and model misjudgment? If a system claims the entire pipeline is fully trustworthy purely on the strength of "we use zero-knowledge proofs," that claim itself is a signal that warrants further questioning, not one to accept at face value.

  • zkML and TEEs share a strikingly similar capability boundary: both only prove "execution wasn't tampered with," neither proves "the input is real" or "the judgment is correct."
  • Their trust roots differ: TEEs depend on hardware vendors and isolation mechanisms, zkML depends on circuit implementation and trusted setup — each with its own attack surface.
  • Robust designs typically treat zkML/TEEs as one piece of the execution-integrity puzzle, stacking multi-source cross-checking and challengeable adjudication to cover input and judgment risks.

6. Verification Checklist and Series Wrap-Up

Distilling the five sections above into a reusable checklist, run through these for any product or service claiming to make on-chain models "trustworthy" via zkML: first, proof coverage — does this zero-knowledge proof cover full model inference, or just a simplified sub-module? Second, quantization cost — has the divergence between the circuit version being proved and the original model advertised to the public been independently assessed and disclosed? Third, is the proof's boundary honestly labeled — does the marketing conflate "computational integrity" with "trustworthy conclusion," and does it clearly state the proof doesn't cover input authenticity or judgment correctness? Fourth, are the new trust roots verifiable — has the circuit implementation been independently audited, and if it relies on trusted setup, were participants diverse and the process publicly verifiable? Fifth, combined defenses — does the system stack multi-source cross-checking or challengeable adjudication on top of zkML/TEE, to backstop the risks the proof technology itself cannot cover.

Looking back across these three pieces published so far in the "AI x On-Chain" series, the same methodological thread runs through them, applied to three different technical layers: the first covered where an AI agent's authority as a "fund executor" should be set and how it should be enforced; the second covered where an AI oracle's trust as a "source of truth" gets relocated, and how multi-source checks and trusted execution should backstop it; this one, as the third piece in the series, covers what a proof technology like zkML actually proves, and what gaps remain beyond that proof's boundary that other mechanisms must fill. The shared conclusion is: regardless of whether the new technical form is an agent, an oracle, or a zero-knowledge proof, any claim of "more trustworthy" that comes with a new layer of technology should never be accepted at face value — it should be broken down into concrete, verifiable technical prerequisites. That's the position this site's methodology series has held throughout. The entire piece discusses abstract mechanism categories and verification methods only, names or evaluates no real product or protocol, and is not investment advice in any form. The series will keep extending into new mechanism layers ahead.

  • Five-question checklist: proof coverage, quantization cost, whether the proof boundary is honestly labeled, whether new trust roots are verifiable, whether combined defenses exist.
  • The shared thread across the three-part series: any "more trustworthy" technical claim should be broken into concrete, verifiable prerequisites rather than accepted at face value.
  • The entire piece is a discussion of mechanism categories and methodology, names no real product, and is not investment advice.