Why zk-ML?
Machine learning systems are already making decisions about credit, healthcare, content moderation, hiring, and more. The problem is not just "does the model work?" but "can we prove what model ran, on what kind of input, without exposing everything?"
Zero-knowledge machine learning (zkML) answers that by attaching cryptographic proofs to ML computations. These proofs show that a model was evaluated correctly, while keeping sensitive pieces (such as model weights, user data, or internal activations) hidden.
In practice, most useful zkML applications today fall into two patterns:
Model-owner proofs: The model provider proves that a specific, committed model produced a given output, without revealing the weights.
User proofs: The user proves that their private data satisfies some property (age, risk score, eligibility, etc.) according to a model, without revealing the raw data.
The rest of this page focuses on these two patterns and the concrete use cases we're building toward.
Pattern 1: Model owner as prover (model auditing)
The core problem: evaluation–deployment gap
Model audits, benchmarks, and certifications are only meaningful if the model under test is the same model actually running in production.
Today, a typical flow looks like this:
The provider submits a model for evaluation or certification.
The evaluator runs tests and publishes metrics.
Later, the provider deploys "a model" behind an API or service.
There is usually no cryptographic link between the evaluated model and the deployed one. A provider can:
present a compliant model for audit, then
deploy a slightly different model (cheaper, less accurate, lightly fine-tuned, or partially compressed) in production.
Users and regulators have to trust that no substitution happened. There is no way to check.
zkML closes this gap.
What zkML adds
With zkML, the model owner can:
Commit to a specific model
Export the model (for example, in ONNX format).
Quantize it (fixed-point / integer form).
Compute a cryptographic commitment (a hash) to the model structure and weights.
Publish this commitment as the "certified" or "approved" model identifier.
Prove each inference came from the committed model
When the service answers a query, it also produces a zero-knowledge proof that:
it evaluated the committed model on the given input, and
the reported output matches the computation inside the circuit.
The proof hides the actual weights and internal activations but proves they are consistent with the published commitment.
Let auditors verify without seeing IP or infrastructure
An auditor (or even a smart contract) receives:
the input (or a challenge constructed by the auditor),
the output,
the model commitment hash,
and the zk proof.
They run a verifier that checks:
"Did the committed model produce this output on this input?"
If the proof fails, the service is out of compliance.
This gives cryptographic evidence of model identity, not just performance numbers in a PDF.
Example use cases
Some concrete scenarios where this pattern is valuable:
Regulated models (finance, health, public services)
A credit-risk model certified by a regulator can be tied to a commitment.
During random or periodic audits, regulators can challenge the live system and verify that answers are produced by the certified model — without seeing the weights.
API providers and SLAs
A model-as-a-service provider claims: "you're paying for our Tier-A model, not the cheaper Tier-B one."
zkML allows them to prove that each billed request was answered by the committed Tier-A model.
Benchmarking and reproducible evaluations
An evaluation lab publishes benchmark scores for a committed model hash.
Later, downstream users can demand proofs that the deployed model matches that hash before trusting the published metrics.
In all of these, zkML is not about "AI safety in general." It is about one precise question:
"Did this particular approved model produce that answer?"
Pattern 2: User as prover (private inputs and identity)
In many situations, the user wants to keep their data private but still prove that it satisfies some property defined by a model.
Zero-knowledge lets the user prove statements of the form:
"If you ran your model on my secret input, the outcome would satisfy property P."
without revealing the input itself.
Age and eligibility checks (zk identity)
One timely application is age and eligibility verification for online services, especially around:
teen access to social media,
age-restricted content,
parental controls, or
jurisdiction-based access (for example, different countries or regions).
A simplified flow:
A provider trains an age or eligibility classifier:
It might use signals like face images, voice, or interaction patterns.
The exact features depend on policy and regulation.
The user obtains an offline evaluation or credential:
The model (or a trusted third party) runs on the user's data.
Instead of storing the raw data, the system derives a compact representation (for example, an embedding or internal activations) and a classification result (like "over 16").
The user creates zk proofs for specific predicates:
"I am over 16."
"I am not on a banned device list."
"I belong to the allowed jurisdiction set."
The platform verifies the proof:
It never needs to see the raw face, voice recording, ID document, or full feature vector.
It only learns that the user satisfies the required condition.
This pattern is also relevant to account bans and multi-account abuse:
A platform can require a proof that "this user is a unique person not tied to a previously banned identity,"
without linking the user to a real-world name or exposing biometric data.
zk KYC and private scoring
A related class of use cases involves KYC (Know Your Customer) and private scoring:
A bank or exchange runs a KYC / AML / sanctions model on a user's documents.
Instead of storing or sharing all raw outputs, it issues a credential or runs an on-chain proof that:
"This user passed our KYC checks and is not on a sanctions list."
Or "this user's risk score is below threshold T."
The verifier (for example, a DeFi protocol or another institution):
learns only that the user satisfies the required policy,
but not the exact score, income, address, or sensitive details.
In these scenarios, zkML helps bridge AI-based decision logic and privacy-preserving credentials.
How our stack fits in
Our current work focuses on making these use cases practical, not hypothetical:
Model auditing pipeline (model owner as prover):
Export models to ONNX.
Quantize to fixed-point integers suitable for arithmetic circuits.
Compile to circuits and generate proofs using a transparent (no trusted setup) backend.
Bind each proof to a model commitment hash, so auditors can verify that a live service still uses the certified model.
Selective / slice-level proofs:
For large models, we support proving only over selected "slices" (sub-computations),
so that high-stakes parts of a pipeline (for example, the final classifier head or a risk module) get proofs, while the rest runs conventionally.
Identity and eligibility prototypes (user as prover):
We design circuits that model "over 16 / under 16", admission thresholds, or other policy predicates,
allowing users to prove eligibility without revealing the raw input.
The long-term goal is simple to state:
Make it normal for ML systems to ship proofs, not just predictions.
zkML is the cryptographic layer that makes those proofs trustworthy, compact, and verifiable — on-chain or off.
Last updated