Pricing a zero-knowledge proof of an LLM gives an absurd number, and teams conclude zkML is not ready. They are pricing the wrong model. For small fixed models on high-stakes decisions, zkML already pays for itself today.
Two numbers, from the same field, a thousandfold apart. A zero-knowledge proof of one inference of a thirteen-billion-parameter language model: about fifteen minutes on a parallelized GPU implementation. A zero-knowledge proof of one inference of a linear-regression model: about a tenth of a second. Both are zkML. Both are real, published, reproducible figures. And almost every team that evaluates the field looks only at the first one, decides the technology is not ready, and never discovers that the second one describes a primitive they could ship this quarter.
The mistake is not arithmetic. It is target selection. A team that wants to prove an AI output on-chain reaches, by reflex, for the model it cares about most — and the model it cares about most is the large language model, because that is the one doing the visible, impressive work. It prices a proof of that model, gets a number that is not a business case, and shelves zkML as a category. The number was correct. The choice of model was not. The thing worth proving was almost never the LLM. It was a small, fixed classifier sitting somewhere quieter in the same stack — a credit model, a fraud scorer, an eligibility gate — and for that model the proof is already cheap enough to run on every decision it makes.
zkML — producing a zero-knowledge proof that a specific model produced a specific output from a specific input — has a real ceiling and a real floor, and the entire “is zkML ready” conversation collapses the two into one verdict. This essay separates them and stays on the floor: the narrow, specific set of use cases where small-model zkML pays for itself today, who the first customers actually are, why those customers and not others, and the concrete test for whether a given team is one of them.
Concede the ceiling first, plainly, because pretending it is not there is exactly how teams end up shelving the whole field. Proving a large transformer is expensive, and the most advanced specialized provers do not hide it. zkLLM (arXiv 2404.16109), among the strongest language-model provers, reports proving an inference of a thirteen-billion-parameter model in under fifteen minutes with a fully parallelized GPU implementation. Read that as the achievement it is — a frontier result from people optimizing hard — and then read what it is not. Fifteen minutes is not a per-query latency budget. It is not something a user waits through. It is an audit artifact: a thing you generate once, after the fact, to prove a claim to someone who will check it later. As a real-time, user-facing primitive for frontier-scale models, zkML does not exist, and saying otherwise helps nobody.
The reasons are structural, not incidental, which is why they will not be engineered away inside a year. The zkML survey (arXiv 2502.18535) names three. Limited circuit expressiveness: a proof system works over arithmetic circuits, and the operations a transformer leans on — softmax, large non-linearities, attention over long contexts — do not map cleanly onto that substrate, so each one is approximated or decomposed at a cost. High proving cost: proof generation is superlinear in circuit size, and a frontier model is an enormous circuit. Deployment complexity: a working zkML system is a toolchain — quantization, circuit compilation, trusted-setup management, proof generation, on-chain verification — and every stage is its own source of failure.
So the first move, before any business case, is to stop pricing the ceiling. A team that benchmarks zkML by proving an LLM in real time has measured the one thing the field cannot yet do and ignored the things it can. The ceiling is genuinely years out. Pricing it and walking away means missing the floor entirely — and the floor is where the customers are.
Drop from frontier transformers to small, fixed models and the numbers stop being absurd. EZKL’s published benchmarks put a zero-knowledge proof of a linear-regression model at roughly 0.12 seconds, and a random-forest classifier at roughly six seconds. The ZKML system work from EuroSys 2024 went further than the headline timings: it showed that circuit-layout choices alone swing proving performance by about 24×. That detail matters more than it looks. A technology whose performance moves that much under ordinary engineering decisions is a technology that rewards engineering — and rewarding engineering is the signature of something that has left the research phase and entered the optimization phase. Earlier work on scaling trustless DNN inference (arXiv 2210.08674) had already pushed verified proofs to ImageNet-scale models, establishing that “small” here means small relative to a frontier LLM, not toy.
model proof cost regime
────────────────────────── ─────────────── ─────────────────────
linear / logistic regression ~0.1 s FLOOR — ships today
small tree ensemble / forest single-digit sec FLOOR — ships today
small CNN / tabular net seconds–minutes edge — case by case
13B-parameter LLM ~15 min (GPU) CEILING — audit only
frontier LLM, real time not practical years outThe table is the whole strategic point. There is no smooth ramp from the floor to the ceiling along which a team can pick a comfortable spot — there is a cheap regime, an expensive regime, and a band in between that has to be decided model by model. A model that proves in tenths of a second to single-digit seconds is a model you can afford to prove on every high-value decision it touches, with the proof cost vanishing against the value of the decision. The only question left is which decisions clear that bar — and the next two sections are the two answers that clear it most cleanly today.
The first real customer is regulatory compliance, and the reason is a structural conflict that a zero-knowledge proof resolves and nothing else does cheaply. A regulated institution has to demonstrate, to an auditor or a regulator, that a model meets a bar — a fairness constraint across protected groups, an approved and unmodified scoring methodology, a risk threshold. But the model’s weights are a trade secret and often a competitive moat; handing them to an examiner is handing over the asset. The standard resolution today is trust plus paperwork: the institution attests, the auditor samples, and a great deal rides on documentation that cannot itself be verified, only believed.
A zero-knowledge proof dissolves the conflict instead of negotiating it. The work on verifiable evaluations of machine-learning models using zkSNARKs (arXiv 2402.02675), built on EZKL, produces an attestation that a model with fixed, private weights achieved a stated performance or fairness metric over a public dataset — and the proof reveals the metric without revealing the weights. The verifier learns the claim is true and learns nothing else. That is precisely the shape a regulator needs: it does not want the institution’s intellectual property, it wants an assurance it cannot get today without taking someone’s word.
Look at why this customer sits squarely on the floor rather than near the ceiling. The models that carry regulated decisions — credit scoring, insurance underwriting, anti-money-laundering classification — are small and fixed by design, not by accident, because regulators favour models a human can interpret and audit, and an interpretable model is a small one. zkAML (ePrint 2025/465) demonstrates the AML case end to end, with proof generation around 220 milliseconds and constant-time verification, so the verifier’s cost does not grow with the institution’s. Compliance attestation is a first customer because every precondition is already satisfied: the model is already small, the stakes are already high enough to justify a proof, and the secrecy-versus-verification conflict is not a hypothetical — it is a recurring, expensive cost that institutions already pay in audit cycles. zkML does not create the demand. It meets a demand that predates it.
The second customer is structurally different: not a regulated institution proving a property of its model, but any setting where one party must trust a score that another party computed. Scaling trustless DNN inference (arXiv 2210.08674) names the deployment patterns directly — verifying that a model-as-a-service prediction was genuinely produced by the claimed model and not a cheaper substitute, verifying a model’s stated accuracy, and trustless retrieval. The common thread is a number crossing a trust boundary.
Make it concrete. A fraud-detection vendor sells risk scores to a bank; the bank acts on those scores but cannot see the model and has only the vendor’s word that the model it audited is the model still running. A risk rating feeds a lending decision a counterparty relies on. An eligibility determination gates a payout. An oracle pushes a model’s output on-chain, where a smart contract will settle real value against it the moment it arrives. In every case the consumer of the number has a direct, monetary incentive to want assurance that the agreed model ran on the agreed inputs, unaltered — and in every case, today, that assurance is a contract and a reputation, not a proof. A zero-knowledge proof attached to the score converts “trust the vendor” into “check the proof.” The vendor still keeps the model private; the consumer stops having to take the score on faith.
This is the on-chain face of the verifiable-inference question that the which-zkml-ships essay and the opML-or-zkML essay take up in detail. The economic logic is the same one that governs the compliance case: when the stakes per decision are high enough, a cheap proof on a small model is worth more than the trust it replaces — and a fraud score wrong by design, or an oracle feed quietly swapped for a cheaper model, is a loss large enough that a six-second proof is a rounding error against it.
Compliance attestation and fraud scoring look like different businesses, but they pass the same four-part test — and that test, not a vibe about whether “zkML is ready,” is the actual decision a team should be making:
A use case that passes all four is a zkML customer today, not in some future release. A use case that fails any of them — most often “small and fixed” — is pricing the ceiling, and should reach instead for the optimistic and trusted-hardware approaches that the opML-or-zkML essay and the DeepProve essay lay out, which trade cryptographic certainty for cost in exactly the regimes where a full proof does not fit.
One honest caveat belongs here. These are early customers. The compliance and fraud applications above are demonstrated and benchmarked in research — zkAML, the verifiable-evaluations work, the trustless-inference deployment patterns — not yet a shelf of off-the-shelf production products. That gap is what “first customers” means: the floor is real and it is reachable, the proving costs are not the obstacle, and the work that remains is integration and productization rather than a research breakthrough. The floor is not crowded yet. That is the opportunity.
The four-part test above is the analysis; this is the operational version — what a team should have done before commissioning a proof for a model headed to production:
The team that priced a proof of its language model and walked away answered a question nobody needed answered. The fraud classifier two services over has been provable for a while — and it was the one that mattered.
Our taxonomy argued prompt injection is a vulnerability class you contain, not a bug you fix. Here is the quantitative half — against the strongest published defenses, indirect-injection attack success stays high, and for agents that can act it stays alarming.
10 min →
A quality-ascending curriculum beats random shuffling — until a decaying schedule delivers your best data exactly when the learning rate is too small to absorb it. The same coupling flips proxy-model ablations: which dataset wins depends on the schedule, not the data alone.
13 min →
An agent workflow that pauses for human approval and then resumes looks safe — a person clicked approve. But the approval decision and the authority the resumed step runs under are two different objects, and most systems conflate them by carrying the approval as an in-band signal the resumed call trusts. That is a confused-deputy bug: a forged resume, a replayed request, or an approval granted at one gate authorizes an action it was never meant to. The fix is to stop transporting approval and start deriving authority from the trusted approval record at resume time, scoped to the exact suspended step — capabilities enforced at the tool boundary, fail-closed by default.
14 min →