zkML Inference Proof: What the Receipt Proves, and What the Model Still Does Not

AI x Crypto Systems — Sat, 23 May 2026 12:08:16 +0000

AI x Crypto Systems disclosure: this article was prepared with AI assistance as an editorial helper. The ideas, facts, code, sources, and conclusions were reviewed by a human.

AI x Crypto Systems disclosure: this article is a technical explanation, not investment advice. AI x Crypto Systems does not recommend buying, selling, or holding any cryptoasset.

zkML Inference Proof

A zkML Inference Proof is easy to oversell. A zkML Inference Proof can show that a committed model computation produced a claimed output from a specific input or input commitment. A zkML Inference Proof cannot show that the model was worth using, that the training data was clean, or that the answer is true. A zkML Inference Proof should be read as a receipt for execution, not as a certificate of intelligence.

The short version

A zkML Inference Proof can verify a formal computation claim.
A zkML Inference Proof cannot verify real-world truth by itself.
A zkML Inference Proof needs inspectable artifacts: model commitment, input commitment, output, proof, and verifier.
A zkML Inference Proof is strongest when the claim is narrow enough to test.

Proof Boundary

zkML Inference Proof proves execution, not truth. zkML Inference Proof matters because AI systems usually ask developers to trust a private server, while crypto infrastructure prefers a checkable statement. zkML Inference Proof ties a model commitment, an input or input commitment, an output, and a verifier to one formal claim. zkML Inference Proof becomes useful only when the boundary of that formal claim is visible.

AI x Crypto Systems uses the receipt-chain diagram to show artifact order, not to imply that a standalone proof file is enough. A verifier still checks the proof against the selected verifier key, the model commitment, the input commitment or public input, and the claimed output.

Proof receipt

Artifact	What a developer should ask	Why the artifact matters
Model commitment	Which model or circuit was committed?	Model names are not proof identities.
Input commitment	What input is public, private, or committed?	A valid proof can still use bad input.
Output	Which output is bound to the proof?	The proof should fail if the output changes.
Verifier	Which verifier checks the proof?	The verifier defines the accepted statement.
Proof	Which proof artifact was generated?	The proof is the receipt, not a trust slogan.

Model Commitment

zkML Inference Proof depends on the exact model artifact being committed. zkML Inference Proof loses practical meaning if the model name stays the same while the weights, architecture, preprocessing, quantization, or circuit changes. In practice, the inspectable thing is a commitment, hash, circuit, proving key, or verifier key linked to a specific computation. zkML Inference Proof should make model identity inspectable before asking a developer to trust the result.

Source check: EZKL documents the practical proving flow around compiled model artifacts, witness generation, proof generation, and verification. See EZKL proving flow and EZKL docs.

Input Commitment

zkML Inference Proof is only as honest as the input story behind the proof. zkML Inference Proof can verify a computation over an input or an input commitment, but zkML Inference Proof does not prove that the input was complete, unbiased, fresh, or collected from the right source. A bad input can still produce a valid proof if the committed computation was executed correctly. zkML Inference Proof needs provenance around the input, not only a proof around the inference.

AI x Crypto Systems uses the input-provenance visual to separate data-source truth from proof validity. zkML Inference Proof can bind an input commitment to a computation, but zkML Inference Proof still needs signatures, logs, attestations, or domain evidence when the source itself matters.

What a zkML proof can and cannot say

Claim	Inside the proof?	Still needs separate evidence
The committed computation produced this output	Yes	The exact proof statement and verifier
The input came from the right source	No, unless separately committed or signed	Data provenance
The model is fair or useful	No	Evaluation, audits, benchmarks
The answer is true in the real world	No	External facts and domain validation

Output Meaning

zkML Inference Proof can verify where an output came from, but zkML Inference Proof cannot make the output semantically correct. zkML Inference Proof could prove that a weak classifier produced a label, a biased model produced a score, or a useless model produced a number. The cryptographic statement can be valid while the model answer remains wrong in the real world. zkML Inference Proof reduces one trust problem and leaves the judgment problem alive.

The trap is in the verb "prove". zkML Inference Proof proves the formal statement that the verifier is built to check. zkML Inference Proof does not prove everything a marketing page might imply.

Quantization Gap

zkML Inference Proof often proves a transformed computation, not the floating-point notebook a developer remembers. zkML Inference Proof systems usually need machine-learning operations to become proof-friendly arithmetic, and that path can involve ONNX export, quantization, circuit compilation, settings files, and witness generation. That transformation can be legitimate, but the transformation changes what a developer should inspect. zkML Inference Proof should name the model version, circuit version, and quantization assumptions before claiming verification.

AI x Crypto Systems uses the quantization-gap diagram as a common developer path, not as a universal zkML law. Some systems use ONNX, some systems use another intermediate representation, and some systems phrase the transformation differently; the important point is that the proved computation may be a transformed version of the original notebook computation.

Developer check

Ask whether the original model, ONNX export, quantized model, and circuit are all identified.
Ask whether the verifier is tied to the circuit version.
Ask whether the output comes from the same transformed computation that the proof verifies.
Ask whether the article, demo, or product distinguishes float model output from circuit output.

Verifier Key

zkML Inference Proof is checked by a verifier, not by rerunning the model in a reader's head. zkML Inference Proof uses a verifier artifact or verifier contract to check that the proof satisfies the selected circuit and public statement. That verifier is part of the claim because the verifier decides what proof is valid. zkML Inference Proof without a visible verifier is closer to a slogan than a developer artifact.

AI x Crypto Systems uses the verifier-key visual to show that zkML Inference Proof accepts a formal statement, not a marketing claim. zkML Inference Proof becomes inspectable when the verifier key or verifier contract is named beside the proof artifact.

Source check: the ERC-7992 draft describes an interface with modelId, inputCommitment, output, and proof for verifying ML inference proofs. AI x Crypto Systems treats ERC-7992 as a draft, not as a finalized standard.

Receipt View

zkML Inference Proof becomes easier to reason about as a receipt. zkML Inference Proof should expose the model commitment, input policy, output, proof artifact, verifier, and verified statement. The receipt does not need hype to be useful. The receipt needs to answer one boring question: what can a developer verify without trusting the model provider?

{
  "model_commitment": "hash-of-model-or-circuit",
  "input_commitment": "hash-or-private-input-policy",
  "output": "claimed-output",
  "proof": "proof-artifact",
  "verifier": "verifier-artifact-or-contract",
  "statement": "this committed computation produced this output"
}

AI x Crypto Systems uses the proof-receipt visual as the practical artifact a developer should ask to inspect. zkML Inference Proof becomes less vague when the article shows the receipt fields instead of repeating the word "verifiable."

Break Test

zkML Inference Proof should fail when a bound artifact changes. zkML Inference Proof becomes easier to trust when a developer can change the output, model commitment, public input, or verifier expectation and watch verification fail. That small break test teaches more than a paragraph saying "trustless AI." zkML Inference Proof earns credibility when the failure mode is visible.

AI x Crypto Systems uses the break-test diagram to show binding, not to assume every output is public. If the system hides the output, the same test should apply to the public commitment or statement that the verifier checks.

A useful tiny experiment

Generate or inspect one proof artifact.
Change the claimed output by one value.
Run verification again.
Expect verification to fail.
If verification still passes, the proof is not binding what the article claims the proof binds.

Research Trail

zkML Inference Proof is not only a blog idea. zkML Inference Proof has a research trail across CNN proofs, realistic ML inference systems, and verifiable machine-learning surveys. The useful reading pattern is not "read everything"; the useful reading pattern is "separate execution proof from every other trust claim." AI x Crypto Systems uses the sources below to keep that boundary tight.

AI x Crypto Systems uses the research-trail visual to connect sources around one boundary question. zkML Inference Proof should be researched by asking what each paper or guide proves, what each paper or guide assumes, and what each paper or guide leaves outside the proof.

Source	Use it for	Do not overclaim
zkCNN	Early proof framing for neural-network predictions	Do not generalize one CNN setting to all zkML.
ZKML EuroSys 2024	Practical constraints and optimization for ML inference proofs	Do not imply every large model is easy to prove.
Trustless DNN Inference	Private inputs/weights and DNN inference framing	Do not claim privacy is automatic in every design.
Survey of ZKP-Based Verifiable ML	Field map and categories	Do not replace primary sources with a survey.
Mina zkML guide	Developer workflow and on-chain verification framing	Do not treat a product guide as neutral benchmark data.

What zkML Does Not Prove

zkML Inference Proof does not prove model quality. zkML Inference Proof does not prove clean training data, fair labels, safe deployment, current input data, good product design, or honest business claims. zkML Inference Proof proves a narrower computational statement under a chosen proof system. zkML Inference Proof is strongest when the article, product, or documentation says that narrow statement out loud.

AI x Crypto Systems uses the red-flag visual as a wording filter. zkML Inference Proof should replace broad claims like "proves truth" with narrower claims like "proves execution" before a developer treats the proof as useful evidence.

Red-flag phrases

"zkML makes AI trustworthy."
"zkML proves the answer is correct."
"zkML solves AI privacy."
"zkML makes LLMs cheap on-chain."
"zkML removes the need for audits."

Verification Choice

zkML Inference Proof is one verification pattern, not the only pattern for AI infrastructure. zkML Inference Proof offers a cryptographic proof when the computation can fit the proof system, while trusted execution environments and optimistic machine-learning designs make different tradeoffs around hardware trust, scale, cost, and finality. The right comparison is not "which label sounds more decentralized"; the right comparison is "which constraint is the system actually solving?" zkML Inference Proof should be chosen when the formal proof boundary is worth the proving cost.

AI x Crypto Systems uses the comparison visual to prevent a false winner-takes-all frame. zkML Inference Proof is strongest for narrow cryptographic claims, TEE designs are strongest when hardware trust is acceptable for larger models, and opML designs are strongest when challenge windows are acceptable for cheaper scale.

Developer Checklist

zkML Inference Proof should be reviewed through artifacts, not adjectives. zkML Inference Proof deserves the same blunt questions every time: where is the model commitment, what input is public or private, what output is bound, which verifier is used, which circuit version was proved, what changed during quantization, and what claim remains outside the proof? zkML Inference Proof becomes practical when the answer is a set of inspectable artifacts, not the phrase "verifiable AI."

AI x Crypto Systems uses the checklist visual as the final review surface for zkML Inference Proof. zkML Inference Proof should leave a developer with named artifacts to inspect, not with a feeling that cryptography automatically made the AI system correct.

Before trusting a zkML inference proof

Identify the exact model or circuit commitment.
Identify the input commitment and what remains private.
Identify the output bound to the proof.
Identify the verifier key, verifier contract, or verifier artifact.
Identify the proving system and circuit version.
Identify whether quantization or preprocessing changed the computation.
Identify what the proof does not claim.

AI x Crypto Systems ends with the boundary card because zkML Inference Proof has one durable lesson. zkML Inference Proof verifies execution first, and the developer still validates reality, provenance, model quality, and product risk separately.

Sources

Mina Protocol zkML guide: https://minaprotocol.com/blog/minas-zkml-library-developer-guide
Inference Labs: https://docs.inferencelabs.com/zk-ml/why-zk-ml
EZKL documentation: https://docs.ezkl.xyz/
EZKL proving flow: https://docs.ezkl.xyz/getting-started/prove/
ERC-7992 draft: https://eips.ethereum.org/EIPS/eip-7992
zkCNN paper: https://eprint.iacr.org/2021/673
ZKML EuroSys 2024 paper: https://ddkang.github.io/papers/2024/zkml-eurosys.pdf
Trustless DNN Inference with Zero-Knowledge Proofs: https://openreview.net/pdf?id=GjNRF5VTfn
Survey of Zero-Knowledge Proof Based Verifiable Machine Learning: https://arxiv.org/abs/2502.18535
ZKProof reference: https://docs.zkproof.org/pages/reference/reference.pdf

How to Build an AI-Powered Data Pipeline with Web Scrapers

AI x Crypto Systems — Sun, 18 Jan 2026 06:23:09 +0000

Web scraping is essential for AI agents that need real-time data. In this tutorial, I'll show you how to set up a complete data extraction pipeline using Apify actors.

The Problem

AI agents need fresh data to make decisions:

Job aggregators need current listings
Lead generation tools need verified contacts
Market research needs competitor data
News monitoring needs latest articles

Manual data collection doesn't scale. APIs are often limited or expensive. Web scraping fills the gap.

Solution: Pre-built Scrapers + AI

Instead of building scrapers from scratch, use production-ready actors. Here's my toolkit:

Job Data

RemoteOK Scraper - Remote job listings with salary data
Greenhouse Scraper - ATS job boards (thousands of companies use Greenhouse)
Arbeitnow Scraper - European job market

Developer Data

GitHub Scraper - Repository stats, stars, languages
Stack Overflow Scraper - Q&A for training data
NPM Scraper - Package ecosystem analysis

News & Social

Hacker News Scraper - Tech news and discussions
Reddit Scraper - Community sentiment
Google News Scraper - Headlines by topic

Business

Email Verifier - Clean your lead lists
CoinGecko Scraper - Crypto market data

Quick Start

1. Get Apify Account

2. Run a Scraper

// Using Apify Client
const { ApifyClient } = require('apify-client');

const client = new ApifyClient({
    token: 'YOUR_API_TOKEN',
});

// Scrape remote jobs
const run = await client.actor("muscular_quadruplet/remoteok-scraper").call({
    maxItems: 100
});

// Get results
const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(`Found ${items.length} jobs`);

3. Use with AI Agents (MCP)

Connect to mcp.apify.com and use natural language:

"Scrape 50 remote JavaScript jobs from RemoteOK"
"Get top 100 cryptocurrencies from CoinGecko"
"Find trending posts from r/webdev"

Integration Examples

n8n Workflow

Add Apify node
Select actor (e.g., muscular_quadruplet/hackernews-scraper)
Connect to your AI processing nodes

Python Script

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")

# Verify emails before outreach
run = client.actor("muscular_quadruplet/email-verifier").call(
    run_input={"emails": ["lead1@company.com", "lead2@startup.io"]}
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item["valid"]:
        print(f"Valid: {item['email']}")

Why Pre-built Scrapers?

Maintained - I update them when sites change
Tested - E2E tests ensure they work
Scalable - Apify handles proxies and retries
MCP Ready - Works with Claude, Cursor, and AI agents

Available Actors

All my actors are free to use on Apify Store:

Actor	Use Case
Email Verifier	Lead cleaning
RemoteOK Scraper	Remote jobs
GitHub Scraper	Developer analytics
Hacker News Scraper	Tech news
CoinGecko Scraper	Crypto data
Reddit Scraper	Community insights

Next Steps

Pick an actor for your use case
Test with free tier credits
Integrate into your AI workflow

Questions? Drop a comment below.

Building AI-ready data tools at flowbot.company

DEV Community: AI x Crypto Systems