A provider's statement that its model outputs are verifiable is only as useful as the specific claim behind it, because the mechanisms grouped under verifiable inference check different things. A zero-knowledge proof reveals nothing beyond the statement it establishes. Such a proof can show that an output is consistent with weights the provider has committed to.[1] A sampled audit checks only some requests and is designed to detect large-scale cheating with high probability.[6] This checklist turns a general claim into ten questions, each with a worksheet.
When to use this checklist
Use it before you rely on a provider's or protocol's claim that its outputs are verifiable. For example, you might rely on the claim when you pay for a particular model or let an agent act on the outputs. Gather the written claim with the paper or specification behind it, the verification tools, and your own requirements, including what a single wrong output would cost you.
1. Write down exactly what is claimed
Write the claim out in full, naming the model, input, output, decoding settings (which control how each token is chosen) and time of the run. Each mechanism covers only some of these. zkLLM's zero-knowledge proofs show that a returned result is correct for the prompt and for a confidential model the provider has committed to.[1] Gong, Liu and Li argue that such proofs do not bind the computational effort spent. In their Hollow-LLM attack, a provider keeps the declared architecture and parameter count but uses weights that reduce the work to that of a much smaller model. The proofs still verify.[3] TOPLOC checks hashes of the model's internal activations. Its authors note that it cannot detect speculative decoding, in which a cheaper model generates the tokens. In their tests, though, it caught every change of model, prompt or numerical precision.[4]
2. Identify the mechanism
Name the mechanism the claim relies on. Each family of mechanisms rests on different evidence and assumptions.
| Mechanism | Example | A passing check shows | Main assumption |
|---|---|---|---|
| Zero-knowledge proof | zkLLM, DeepProve[1, 2] | The output matches the public architecture run on committed weights[3] | The commitment identifies the intended weights |
| Hardware attestation | Serving in a trusted execution environment (TEE)[7, 9] | Which software genuine hardware loaded | The hardware vendor and the measured software |
| Activation fingerprint | TOPLOC[4] | Recomputed activations match the provider's hashes within set thresholds | A validator able to rerun the model |
| Refereed delegation | Verde[5] | The correct result, if at least one provider is honest | Operators in the model's computation give bit-identical results across hardware |
| Optimistic re-execution | EigenAI[8] | Nobody challenged within the dispute window, or re-execution matched | Someone challenges; verifiers use identical hardware |
| Sampled audit | IMMACULATE[6] | Audited requests were consistent with the claimed model | Audit requests are indistinguishable from normal ones |
3. Find out who can run the verification
Find out what data and hardware the verifier needs, because these decide whether you, or someone you trust, can run it. Zero-knowledge proofs promise public verifiability,[3] and DeepProve reports verification times of 1 to 3.7 seconds.[2] TOPLOC's validator reruns the model over the generated tokens to recompute activations,[4] so it needs the weights and suitable hardware. EigenAI requires verifiers to use the same graphics processing unit (GPU) models as the operators who run inference, because A100 and H100 GPUs produce different results for identical operations.[8]
4. List what you still have to trust
List each party or component whose failure would let a wrong output pass. Every mechanism leaves at least one, and the table's last column names the main one. Outside testing does not remove that dependence. Cai and colleagues conclude that tests run without the provider's cooperation cannot reliably detect model substitution. Statistical tests on text outputs need many queries and miss subtle substitutions, and tests on log probabilities fail because production inference is nondeterministic.[7] Cai and colleagues propose TEEs instead. A TEE moves trust to the hardware vendor and the measured software. Our guide to reading a remote attestation report covers those checks.
5. Check whether every output is covered
Find out whether the scheme checks each output, a sample or only disputed results. An IMMACULATE auditor sends a small number of random requests that look like normal traffic. The auditor then asks the provider to prove how it served them. The authors reason that cheating pays only if a provider deviates on a non-negligible share of requests. So, they argue, such sampling detects large-scale deviations with overwhelming probability.[6] Under EigenAI's optimistic design, results stand unless someone challenges them during a dispute window.[8] Both designs target systematic cheating. Neither guarantees that a particular output you received was checked.
6. Check how the evidence is bound to your request
Check that the evidence refers to your request, so that it cannot be reused for another. It must also capture every input that determines the output. EigenAI describes its output as a pure function of the model, prompt, seed and decoding settings, that is, as depending only on these four inputs. So all four must be recorded for a re-execution to match.[8] Session binding matters too. Attestation reports in WhatsApp's TEE-based system originally carried no client-supplied value, so they could have been replayed. Meta's fix ties each report to one Transport Layer Security (TLS) connection.[9] Keep the evidence with the record of any action an agent takes on the output. You can then trace that action to a verified result.
7. Check how the model is committed
Check the model commitment, a published cryptographic fingerprint of the weights that later proofs refer to. In zkLLM, the provider spends up to 20 minutes committing to a model and publishes a commitment of about 10 MB.[1] A commitment fixes a set of weights without saying which weights they are. Unless the provider links it to a release you can inspect or evaluate, a proof shows only consistency with some fixed weights. The Hollow-LLM results show that weights fitting a large declared architecture can do a much smaller model's work.[3]
8. Find out what happens when a check fails
Find out what consequence a failed check has. Without a defined consequence, detecting an error changes nothing. In EigenAI, a mismatch found on re-execution leads to slashing, which takes funds from the operator's stake.[8] In Verde, a dispute narrows to a single operator in the model's computation. The referee re-executes that operator to find which provider was wrong.[5] With proofs and attestations, your own client decides the consequence, so confirm that it rejects an output that fails.
9. Weigh cost and latency
Record what verification costs, because cost decides how much traffic a provider can afford to verify. zkLLM reports proving one inference of a 13-billion-parameter model in under 15 minutes.[1] DeepProve reports about 174 proven tokens per minute for GPT-2 and 86 for Gemma 3.[2] IMMACULATE limits its verifiable computation to audited requests and reports under 1% throughput overhead.[6] EigenAI reports under 2% overhead in its own tests.[8] Verde runs each task on at least two providers, so total cost at least doubles. Its reproducible operators also carry overhead relative to PyTorch: on A100 GPUs, the authors report 58% for Llama inference at 1 billion parameters and 98% at 8 billion.[5]
10. Look for independent review
Look for outside review of both the mechanism and its deployment. zkLLM was accepted to the ACM Conference on Computer and Communications Security (CCS) in 2024; DeepProve's ePrint entry lists a minor revision for CCS 2026.[1, 2] Academic analysis can also expose a gap in a whole class of claims, as the Hollow-LLM paper argues for zero-knowledge inference.[3] Deployments need their own review. Trail of Bits' pre-launch audit of WhatsApp's TEE-based system found 28 issues, eight of them rated high severity.[9] Treat figures that only the provider has measured, such as EigenAI's reproducibility results, as claims until others reproduce them.[8]
A worked example
Sources
- zkLLM: Zero Knowledge Proofs for Large Language Models
- DeepProve: Verifiable End-to-End Large Language Model Inference
- Hollow-LLM Attack: Computationally Trivial Weights in Zero-Knowledge Verification of LLM Inference
- TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable Inference
- Verde: Verification via Refereed Delegation for Machine Learning Programs
- IMMACULATE: A Practical LLM Auditing Framework via Verifiable Computation
- Are You Getting What You Pay For? Auditing Model Substitution in LLM APIs
- Deterministic Inference Is Here: How EigenAI Makes Every AI Output Verifiable
- What we learned about TEE security from auditing WhatsApp's Private Inference
Check or correct this page
Verification record
The digest below shows whether the text you are reading matches the published source. It does not show that the reporting is correct. The build computes it from this page's Markdown source and lists it in the site manifest.
e19e029da9a1d28247f5d640def20bdfc6d26e25f17ce50760d6ad52a6a17711
.jpg){kind=link}