# >>> inference labs

Artificial Intelligence Unleashed, connecting AI to the global economy:

A world where AI, deeply entwined with the global digital economy is fast approaching. As we navigate through this nascent and pivotal stage in AI's evolution, we acknowledge its profound implications and incredible scale at consolidating a massive amount of data collection and processing.

It is imperative we all take on the role of stewardship with deep conviction that the development of AI in this early stage is aligned with the principles of free-speech, democratic values, and a diverse dataset with the voices and opinions of many. This key phase necessitates steadfast determination, vision, and a globally inclusive mission, to thwart the risk of AI's monopolization by proprietary, closed development for misuse or influence against the global populace.

This highlights why it's necessary for AI to be adaptable, user-friendly, and provide the least barriers to entry for all. It's critical in order to counterbalance the misuse seen in the past two decades by dominant tech companies. In order for AI to truly fulfill its potential, it needs to be democratized and widely distributed, which is why it's essential to encourage broad participation instead of concentrating power.

Our belief in successfully realizing our mission lies in the implementation of our core thesis, which advocates for AI to be modular rather than monolithic. This stands in stark contrast to centralized corporations, as we strive to adopt an open-source approach.

The early internet, though fundamentally decentralized, was primarily designed for information exchange, not for intrinsic value transfer. This shortcoming paved the way for Web2, which found ways to monetize consolidated and centralized information as a service. However, this led to an unfortunate situation where control over information, with the power to influence behaviors, became exceptionally profitable for a select few.

Web3 offers a unique solution by integrating the value layer directly into the network level, making value exchange as fundamental as information exchange. This addresses the monopolistic issues that have dominated the past, paving the way for countless opportunities in the realm of Artificial Intelligence. We foresee the widespread adoption of Smart Agents as autonomous Artificial Intelligence, capable of maintaining context, building upon memories, with defined sets of goals. As these Smart Agents naturally function in the digital realm, they require the means to exchange value during interactions with both humans and other machines. Currently, Web3 caters to all these needs, providing the necessary tools to facilitate this exchange of value. It equips Smart Agents to operate securely, transparently, and efficiently. Traditional fiat financial systems are currently unequipped to incorporate Smart Agents in a standardized fashion. With web3, however, Smart Agents gain the ability to participate in smart contracts, audit and review governance, and ensure that services or value exchanges have been fulfilled properly. Smart Agents would require the layer of trust be programmatically accessible, and transparent for analysis.

At the core, our vision is to harness the transformative principles of Web3 and integrate them into Artificial Intelligence. We aim to foster the creation of tools, applications, and networks, wherein layers of value and trust are seamlessly incorporated within open, decentralized systems and protocols. When our vision is realized we will see a world not of smart agents but sovereign agents, accessible by all, but guided and operated by the many.


# Litepaper

#### State of the Art AI

Today’s state of the art AI systems come as a result of many improvements over the last few years. Some examples are advanced dataset collection and AI cleanup algorithms (AI used to train AI), Reinforcement Learning from Human Feedback (RLHF), and hardware advancements such as the release of the NVIDIA A100/H100 GPUs. These improvements have led ChatGPT to be one of the fastest growing products ever released, with massive user growth expected to continue.

These AI systems have caught the attention of the public because they are novel and useful. They are seemingly able to answer any question from scratch before the user's eyes. They have an established business and entertainment use case.

#### Open Source AI

A recently leaked Google Memo highlights and confirms the closed sourced AI producers' concerns. In a matter of days, the open source community was able to take a leaked LLM from Meta and improve it in a way that took Google and OpenAI months.

The initial assumption of creating models which have a) prohibitive training costs b) 2-3 month training times c) massive datasets in the size of PBs, would inherently create datamoats may be incorrect. Open Source initiatives are currently training models on consumer grade desktop hardware with iteration cycles of days instead of months while achieving 90% of the closed source model utility. Community members are creating datasets from the larger proprietary models and other sources. This is achieved with spending pennies on the dollar in comparison to the larger corporations.

#### Monolithic AI

Today’s companies which deliver AI solutions operate in all parts of the AI value chain. Everything from dataset collection and data cleaning, training and operating infrastructure, to delivery of products and services (such as API integrations) are often developed and offered in house. 

As these companies and the industry overall matures, the structure will become less monolithic. Naturally some companies will emerge as more performant on certain parts of the AI value chain than others and will come integrated and reliant on more external parties. The same trend has been previously observed in all other established value and supply chains.

#### AI and Web2

Many products and services have been built in the web2 space around AI technology. Everything from AI Assistants, Companions, Trading Algorithms and Funds, to AI Video Creation has evolved well past tech demonstrations and has 

#### AI and Web3

AI and Web3 will create entirely new forms of businesses and opportunities. As the AI industry grows, the common use case we see today of humans interacting with AI will become matched with machines interacting with machines. This can already be seen today with the rise of tools such as AutoGPT, an open source project, in which users create a bot to achieve any arbitrary goal by using ChatGPT.

Payment settlement layers will become more important as machine to machine AI interaction becomes more prevalent. How can machines agree AI is executed correctly without the need for human confirmation or intervention? How can one qualify the output of an AI system? How can a node prove it will offer value without disclosing specifics upfront? Blockchain and trustless technology is the obvious answer, offering guarantees to both parties where traditional payment systems don’t.

#### Conclusion

Proprietary AI systems had a head start due to stockpiles of resources, developer talent and well defined business objectives. It was quickly realized with a fraction of the resources, an internet based community of people working together can outpace and outperform large technology conglomerates. In the long term, Open Source will prevail.


# Responsible & Ethical AI

The current landscape of AI ethics and emerging trends.

AI ethics is an emerging field with multiple competing narratives about how to reliably build human values into AI. Some of the most current methods include Reinforcement Learning from Human Feedback (RLHF), Constitutional AI, and ethical frameworks. 

## Reinforcement learning from human feedback (RLHF)

[RLHF is a technique used in machine learning that focuses on integrating human feedback](https://huggingface.co/blog/rlhf) into model behavior. The method was intentionally designed to mimic human judgment, while prioritizing specific ethical values, such as safety and harmlessness. RLHF works by having humans evaluate various scenarios, ranking them from 0-5 according to various ethical values. A reinforcement learning model is then trained on this data. 

The method is also intended to capture the context that machines lack in ethical dilemmas. Despite the effectiveness of RLHF in changing model behavior, the technique still suffers from operational challenges, such as the lack of scalibility of human annotation and inconsistent labeling. 

[RLHF was originally developed by research teams at OpenAI](https://arxiv.org/abs/1706.03741) but is also used in many other companies, such as Hugging Face, [Weights & Biases](https://wandb.ai/ayush-thakur/RLHF/reports/Understanding-Reinforcement-Learning-from-Human-Feedback-RLHF-Part-1--VmlldzoyODk5MTIx), and [Deep Mind](https://www.deepmind.com/blog/learning-through-human-feedback), as well.

## Constitutional AI

[Constitutional AI (CAI) was created by Anthropic as an alternative to RLHF](https://arxiv.org/abs/2212.08073), attempting to encode specific ethical principles into the model itself, rather than rely on human annotators. Cleverly, the developers at Anthropic call Constitutional AI “Reinforcement Learning with *AI Feedback*”. Anthropic considers CAI to be a better version and replacement for RLHF, as relying on AI rather than human feedback solves scalability issues.  

However, losing the human voice in AI development removes valuable information about context that only end users have. Also, CAI must pre-determines the principles built into AI, leaving end users unable to participate. 

## Ethical Frameworks

Ethical frameworks, such as the [Responsible AI toolkit by PwC](https://www.pwc.com/gx/en/issues/data-and-analytics/artificial-intelligence/what-is-responsible-ai.html) or [Explainable AI by IBM](https://www.googleadservices.com/pagead/aclk?sa=L\&ai=DChcSEwjp-cjP1NL_AhV8FK0GHYbdAvwYABAAGgJwdg\&ohost=www.google.com\&cid=CAESbeD2EGDrVMDQwhDeIbGeCMzuAZgsjzktFnlV0UgWIMDdKDGBNiIT-ra_casymug5NyJQf4LJrsID1cIjUV8TbaPQHAWpwvtgypRXoWSndefVzzgchnl3T0ktOdtHUdH_gpMAf0sziW_7NjQZEuk\&sig=AOD64_0fZhmtlpfg5883GCz38eGomaFUmA\&q\&adurl\&ved=2ahUKEwiZwr7P1NL_AhWrLEQIHZR-ALEQ0Qx6BAgHEAE\&nis=2), serve as a foundation for creating ethical AI systems, but they too are not without drawbacks. However, ethical frameworks face critique [because most frameworks cannot be implemented well in practice](https://hbr.org/2020/11/ethical-frameworks-for-ai-arent-enough) and [lack empirical verification](https://algorithmwatch.org/en/ai-ethics-guidelines-inventory-upgrade-2020/).

## DevOps, MLOps, etc.

There's also an increase in developer tools that aim to streamline the process of building ethical AI. However, this method also faces critique because it essentially outsources ethical decision-making to tool creators rather than the users or the developers themselves.

## Emerging Trends

The future of AI ethics presents many opportunities. One path is personalized ethics, which relies on modularized AI dominating over monolithic models. Personalized ethics could allow for customization according to user's values and beliefs, ensuring that AI systems reflect a diversity of ethical perspectives.

Another trend has been the need to [place greater emphasis on the role of the end user](https://www.emergingtechbrew.com/stories/2022/01/17/seven-ai-ethics-experts-predict-2022-s-opportunities-and-challenges-for-the-field). As it currently stands, end users have minimal input in improving model performance, verifying behavior, or disagreeing with problematic model output. Future methodologies may seek to improve the imbalance of power by giving more control to the users who interact with the AI systems daily.

[Also, the idea of creating an "unbiased" model is under scrutiny. ](https://arxiv.org/abs/2302.12149)As a blog by Anthropic states, "AI models will have value systems, whether intentional or unintentional." Complete neutrality of AI models is unachievable due to the nature of data always being created from the point of view of the subject. Instead, the focus will likely shift towards acknowledging these inherent biases and values, developing models that critically engage with them.

## Conclusion

AI ethics is a field in flux, grappling with present challenges while anticipating future ones. It's a space of ongoing experimentation that requires a continuous dialogue among stakeholders in the eternal pursuit just and good AI systems.


# zk-ML

To redefine the vision of a decentralized and verifiable world computer into a reality by embedding cryptographically verified off-chain artificial intelligence to EVM compatible networks. The challenge? Today's public blockchains do not support artificial intelligence. Running off-chain Inference without verification put operator's intellectual property at stake, and requires users to trade-off trustlessness and again rely on centralized points of failure. But we're changing the game. With zk-VIN, we are ready to introduce web3 like never before – smart, verified intelligence.\
\
Over recent years, zero-knowledge proofs have played a pivotal role in blockchain technology for two primary reasons: (1) they enhance the scalability of compute-limited networks by handling transactions off-chain and subsequently confirming the outcomes on the mainnet; and (2) they bolster user confidentiality by facilitating veiled transactions, which are only accessible to those with knowledge of the concealed details. Given the nature of blockchains, the significance of these features is evident. For instance, a decentralized platform like Ethereum cannot amplify its throughput or block size without imposing excessive demands on validator computational power, bandwidth, and response time. This necessitates the use of rollups in their many forms. Additionally, since all transactions are transparent to everyone, there's a growing need for on-chain privacy solutions. However, the utility of zero-knowledge proofs isn't confined to these two aspects. They also offer a third set of advantages: the efficient validation that any computation, not just those associated with an off-chain version of the EVM, has been executed accurately. This potential extends well beyond the realm of blockchains.

Innovations in systems that harness the power of zero-knowledge proofs for concise computational verification are paving the way for users to expect the same level of trustworthiness and verifiability from all digital products, especially machine learning models. The increasing computational demands of blockchains have spurred research in zero-knowledge proofs, leading to the development of new and novel proving systems that are more memory-efficient and offer swifter proving and validation times. As a result, it's now feasible to validate machine learning algorithms.


# 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:

1. **Model-owner proofs:**\
   The model provider proves that a specific, committed model produced a given output, without revealing the weights.
2. **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:

1. **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.
2. **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.
3. **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:

1. 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.
2. 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").
3. 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."
4. 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.\ <br>


# Benchmarks

Leveraging ZK-SNARKs (zero-knowledge succinct non-interactive argument of knowledge), we demonstrate their versatility across a range of applications. Specifically, we illustrate how to utilize ZK-SNARKs to authenticate the execution of machine learning models.\
\
**Why EZKL?**&#x20;

* Convert an ONNX model into a ZKP
* Apache 2.0 Open Source License
* Inference Labs is a contributor
* Prove + verify at command-line (or binary, contract, WASM)
* Regularly updating with new layers, suitable for compact production models
* Performance improvements

**NanoGPT**\
\
A neural network model created by Andrej Karpathy for generating text, similar to GPT-3.  The main purpose is to demonstrate compressing a self-attention model small enough to run efficiently in a browser or other edge contexts.

<https://github.com/karpathy/nanoGPT>\
\
**Hardware**\
Google Cloud\
28 cores \
448GB RAM\
500GB SSD\
\
**Our Progress**\
The latest update focused on optimizing sparsity issues. Essentially, certain neural networks may contain redundant computations at various stages (consistently producing zeros). These inefficiencies have been addressed and improved in the most recent version.<br>

<figure><img src="/files/XViXLPA4NRnnsBLZL6FC" alt=""><figcaption><p>In the span of less than a month we have observed a 30% increase in efficiency on implementation optimizations alone.</p></figcaption></figure>

<figure><img src="/files/nCvX9c4P0RevktGbDwy6" alt=""><figcaption></figcaption></figure>

**Next Steps**\
Optimize and reduce proving times and memory consumption while generalizing model support.


# Glossary

zkML terminology

### A

**Activation Function**

A function applied elementwise to a layer’s outputs in a neural network to introduce non-linearity. Common examples include ReLU, sigmoid, and softmax. In zkML, activation functions must be implemented with arithmetic constraints that are efficient in a finite field.

**Arithmetic Circuit (Circuit)**

A low-level representation of a computation built from basic operations over a field, such as additions and multiplications. In zkML, we translate model layers (Conv, GEMM, ReLU, etc.) into arithmetic circuits so that a proof system can check their correctness.

### B

### C

**Circuit Size**

A measure of how large an arithmetic circuit is, typically in terms of the number of gates or constraints. Larger circuit sizes generally mean higher proving time and memory usage.

**Clip**

An elementwise operation that restricts each input value to a specific range \[min, max]. Values below min are set to min; values above max are set to max. In zkML circuits, Clip is implemented using comparisons and max/min logic.

**Constraint System**

A set of equations that must hold for all valid computations. Each gate or operation in a circuit contributes constraints. A proof of correct execution is essentially a proof that all constraints in the system are satisfied by a given witness.

**Convolution (Conv)**

A layer that slides a learnable kernel over an input tensor (such as an image) to extract local features. In ONNX, Conv nodes represent convolutions. In zkML, Conv becomes a structured arithmetic circuit performing many multiply-add operations.

### D

**DSperse**

A framework for targeted verification in zero-knowledge machine learning (zkML) developed by Inference Labs. DSperse lets developers apply zero-knowledge proofs only to selected “slices” (sub-computations) of a model instead of the entire model, trading off between performance, cost, and assurance. It also facilitates proof aggregation, allowing multiple slice-level proofs to be combined efficiently into a single verifiable artifact. This enables focused verification of the most sensitive or critical parts of an AI pipeline while keeping overall proving cost manageable.

### E

**Expander**

A proving backend developed by Polyhedra Network based on GKR- and sum-check-style protocols. Expander is designed for scalable, memory-efficient verification of large arithmetic circuits. JSTprove uses Expander to generate and verify proofs for compiled ONNX models.

**Expander Compiler Collection (ECC)**

A Rust-based frontend for building arithmetic circuits that target the Expander prover. ECC provides APIs for defining layers, range checks, and other gadgets, and emits the circuit structure and metadata that Expander needs. JSTprove uses ECC to compile quantized ONNX models into arithmetic circuits.

### F

**Fiat–Shamir Transformation**

A method for converting an interactive proof into a non-interactive one by replacing the verifier’s random challenges with hashes of the transcript. Instead of multiple rounds of back-and-forth messages, the prover derives each challenge deterministically using a cryptographic hash function applied to previous messages. This eliminates interaction while preserving soundness in the random-oracle model. Many practical zk-SNARKs, zk-STARKs, and GKR-based zkML systems rely on the Fiat–Shamir transformation to turn interactive protocols into single-message proofs suitable for offline or on-chain verification.

**Fixed-point Representation**

A way to encode floating-point numbers as integers by multiplying them by a fixed scaling factor (for example, 2^s) and rounding. All arithmetic is performed on integers, and scaling is tracked explicitly. This is the standard way to represent floating-point ML computations inside arithmetic circuits.

### G

**GEMM (General Matrix Multiplication)**

A standard name for dense matrix multiplication. In ONNX and many ML frameworks, GEMM or MatMul nodes represent linear layers that multiply an input by a weight matrix and add a bias. In zkML, these become matrix-multiplication circuits, often a major contributor to circuit size.

**GKR Protocol (Goldwasser–Kalai–Rothblum)**

An interactive proof technique for verifying computations over layered arithmetic circuits. It reduces checking an entire circuit to checking a small number of polynomial identities. Many modern zkML stacks, including GKR-based provers, use this protocol (or variants) as a backbone.

**Ground Truth**

The "true" labels or values used to evaluate a model's predictions. For example, in classification, the ground truth is the correct class for each input. zkML proofs often show that a prediction was computed correctly, given a fixed model and input, but do not guarantee that the model matches ground truth.

**GPU (Graphics Processing Unit)**

A processor designed for highly parallel workloads. In zkML, GPUs can accelerate both machine learning (training and inference) and cryptographic proving, because they can evaluate many similar arithmetic operations in parallel.

### H

**HALO2**

A proving system based on Plonkish arithmetization that supports features like custom gates and lookup tables. It is widely used in the zk ecosystem (for example, by Zcash and various rollups).

**Homomorphic Encryption**

A family of encryption schemes that allow computations to be performed directly on encrypted data without decrypting it. The result is still encrypted and can be decrypted later to obtain the final value. Homomorphic encryption is a complementary privacy technology to zkML.

### I

**Inference**

The phase where a trained model is used to make predictions on new inputs. In zkML, we typically prove that an inference was carried out correctly (for example: “running this ONNX model on input x produced output y”) without requiring the verifier to re-run the model.

**Interactive Proof**

A protocol in which a prover and a verifier exchange multiple messages. The verifier sends challenges; the prover responds. Zero-knowledge proof systems originally started as interactive proofs before non-interactive variants became common.

### J

**JSTprove**

An open-source zero-knowledge machine learning (zkML) toolkit developed by Inference Labs. JSTprove takes an ONNX model as input and provides an end-to-end pipeline: quantization, circuit compilation (via ECC), witness generation, proof creation (via Expander), and verification. It exposes this flow through a developer-friendly CLI (commands like compile, witness, prove, verify), making zkML accessible to ML engineers without requiring deep cryptography expertise.

### K

### L

**Layer (Neural Network Layer)**

A building block of a neural network that transforms its inputs into outputs, such as a convolution, fully connected (GEMM) layer, or activation layer (ReLU). In zkML, each layer type is translated into a specific circuit gadget or constraint pattern.

**Layer 1 (L1)**

A base blockchain that provides core consensus, security, and data availability (for example, Ethereum mainnet). zkML systems often generate proofs off-chain and verify them on an L1 smart contract.

**Layer 2 (L2)**

A protocol built on top of a Layer 1 blockchain to improve scalability. L2s typically process transactions off-chain and post proofs or compressed data back to L1. zk-rollups are a common L2 design that relies on zero-knowledge proofs.

### M

**Machine Learning**

A family of methods where models learn patterns from data instead of being programmed with explicit rules. ML covers both training (learning parameters) and inference (using the trained model). zkML systems use zero-knowledge proofs to attest that specific ML computations—most commonly inference, but potentially also training steps or metrics—were executed correctly.

**Mainnet**

The primary network for a blockchain where real-value transactions occur. When we talk about verifying zkML proofs “on mainnet,” we mean verifying proofs on the production chain rather than on test or development networks.

**Model**

The learned function produced by a training process. It maps inputs (features) to outputs (predictions). In zkML, the model’s structure and weights are part of the computation we encode in a circuit, and often the model (or its hash) is a public input to the proof.

**Multi-party Computation (MPC)**

A cryptographic technique that lets several parties jointly compute a function over their inputs while keeping those inputs hidden from each other. MPC and zero-knowledge proofs are often used together: zk proofs can attest that an MPC protocol was followed correctly, and MPC can be used inside zk protocols to help construct witnesses or commitments.

### N

**Neural Network**

A model composed of interconnected layers (neurons) that apply linear operations and non-linear activations to data. Neural networks are widely used for tasks like vision, language, and classification. zkML frameworks commonly support neural network architectures exported to ONNX.

**Neuron**

A basic computational unit in a neural network. It takes one or more inputs, applies a weighted sum and a bias, and then passes the result through an activation function. In circuits, neuron computations are expanded into additions, multiplications, and activation constraints.

**Non-interactive Proof**

A proof that the prover can generate as a single message, with no back-and-forth with the verifier. zk-SNARKs and many practical zkML systems use non-interactive proofs so verification can be done offline or on-chain without interaction. Many non-interactive schemes are obtained by applying the Fiat–Shamir transform to an underlying interactive protocol, replacing verifier challenges with hash-based challenges.

### O

**ONNX (Open Neural Network Exchange)**

An open standard for representing machine learning models. ONNX defines a common set of operators (Conv, Gemm, Relu, MaxPool, etc.) and a portable file format. zkML systems like JSTprove take ONNX models as input and compile them into arithmetic circuits.

**Oracle**

A system that feeds off-chain data into a blockchain so it can be used by smart contracts. In zkML, an oracle might provide model hashes, parameters, or other metadata that proofs reference.

**Overfitting / Underfitting**

Overfitting occurs when a model fits the training data too closely, including noise, and performs poorly on new data. Underfitting occurs when a model is too simple to capture the structure in the data, performing poorly on both training and test sets. zkML does not change these phenomena; it just allows us to prove that a given model’s computation (for example, an inference) was executed correctly.

### P

**Polynomial Commitment**

A cryptographic scheme that lets a prover commit to a polynomial once and later prove its evaluations at specific points. The commitment is short, and verification is efficient. Many modern proof systems use polynomial commitments internally to prove that large arithmetic circuits are satisfied.

**Precision**

A metric for binary or multi-class classification. Precision measures how many of the examples the model predicted as positive were actually positive.

**Proof**

The artifact produced by the prover that convinces a verifier that the constraints of the circuit are satisfied for some (possibly hidden) witness. In zkML, a proof typically attests that a specific model computation (often an inference) was executed correctly with respect to an ONNX model and inputs.

**Proof Size**

The number of bytes in a proof. Many modern proof systems have small, nearly constant proof sizes even for large circuits, which is important for on-chain verification.

**Proof System (Proving System)**

The combination of algorithms and protocols used to create and verify proofs. Examples include zk-SNARKs, zk-STARKs, and GKR-based systems. A zkML framework chooses one or more proof systems as backends to generate proofs for compiled circuits.

**Prover**

The party that runs the computation (for example, model inference), constructs the witness, and generates the zero-knowledge proof that all constraints are satisfied.

**Proving Time**

How long it takes the prover to generate a proof for a given computation. It depends on circuit size, proof system, hardware (CPU/GPU), and implementation details.

**Public Inputs**

Values that both the prover and verifier know and that are part of the statement being proved. Examples include the model hash, claimed output, or public configuration parameters. Depending on the proving system, public inputs may be encoded directly in the circuit or designated as public components of the witness.

**Private Inputs**

Values used in the computation that the prover does not want to reveal, such as secret inputs, private model weights, or internal activations. Zero-knowledge guarantees that these remain hidden while still allowing verification of correctness.

### Q

**Quantization**

The process of converting floating-point numbers (weights, activations, inputs) into integers, usually with a fixed scaling factor. In zkML, quantization reduces the cost of arithmetic operations in the circuit while keeping the model’s behavior close to its original floating-point version.

### R

**Recall**

A metric for classification problems. Recall measures how many of the truly positive examples the model correctly identified.

**Rectified Linear Unit (ReLU)**

A popular activation function defined as ReLU(x) = max(x, 0). It keeps positive values and zeroes out negative ones. ReLU is widely used in modern neural networks and appears directly in zkML circuits.

### S

**Scaling Factor**

The constant used in fixed-point quantization (for example, 2^s). Multiplying a real number by the scaling factor and rounding gives its integer representation. When multiplying quantized values, the scaling factor must be adjusted carefully to keep results in the same scale.

**Slice (Model Slice)**

A selected sub-computation of a model, typically a contiguous sequence of layers and activations taken from a larger architecture. If a model can be viewed as a composition fₙ ∘ … ∘ f₂ ∘ f₁, a slice might be a sub-composition f₍ᵢ₊ₖ₎ ∘ … ∘ fᵢ. Frameworks like DSperse use slices to apply zero-knowledge proofs only to critical portions of a model.

**Smart Contract**

A program deployed on a blockchain that runs deterministically on every node. In zkML, smart contracts often verify zero-knowledge proofs to confirm that off-chain ML computations were executed correctly.

**Softmax**

A function that turns a vector of scores into a probability distribution by exponentiating each score and dividing by the sum. It is often used as the final layer in classification models. Implementing softmax exactly in finite fields is expensive, so zkML systems may use approximations or alternative formulations.

**Statement (Claim)**

The assertion that a proof is about. For example: “Given model hash H and input x, the output y is the result of running the model encoded by H on x.” A valid proof convinces the verifier that the statement is true without revealing the underlying witness.

**Sum-check Protocol**

A classical subroutine in interactive proofs used to verify that a sum of polynomial evaluations has a claimed value. It is a core building block inside GKR and related proof systems that underlie many modern zkML stacks.

**Supervised Learning**

A learning setting where models are trained on labeled examples (input, target output). The goal is to learn a mapping that generalizes to unseen data. Most classification and regression models used in zkML are trained in a supervised way.

**Sybil Attack**

An attack in which one entity creates many fake identities (nodes or accounts) to gain disproportionate influence in a network. Decentralized proving or validation networks must be designed to resist Sybil attacks, often by tying identities to economic or resource-based costs.

### T

**Test Data (Test Set)**

A subset of data held back during training and used for the final evaluation of a model. It approximates how well the model will perform on unseen data. zkML systems typically prove correctness of specific computations for particular inputs, not statistical performance, but test data is still used upstream during model development.

**Testnet**

A separate blockchain network used for testing and development, where tokens have no real economic value. zkML projects often first deploy proof verification contracts and run experiments on testnets before moving to mainnet.

**Token**

A unit of value issued by a blockchain or protocol. In the zkML context, tokens may be used to incentivize provers, pay for verification, or participate in protocol governance, but they are distinct from the proofs and circuits themselves.

**Training Data (Training Set)**

The data used to train a model. The model adjusts its parameters to minimize a loss function on this data. Most current zkML frameworks operate on the trained model (inference), but in principle training steps or metrics can also be modeled and proved.

### U

**Unsupervised Learning**

A learning setting where models find structure in data without labeled outputs, for example via clustering or dimensionality reduction. It is less commonly used directly in zkML examples, which typically focus on supervised tasks, but the concept appears in broader ML discussions.

### V

**Validation Data (Validation Set)**

A subset of data used during model development to tune hyperparameters and make decisions about model architecture. It differs from test data, which is used only for final evaluation. zkML operates after model selection, but the quality of the model still depends on how validation was done.

**Verification**

The process of checking a proof. Verification is much cheaper than re-running the original computation and does not require access to the witness. In zkML, verification is what smart contracts or off-chain verifiers do to confirm that a computation (often an inference) was executed correctly.

**Verification Time**

How long it takes a verifier to check a proof. One key advantage of modern proof systems is that verification time is typically much smaller than the original computation time.

### W

**Witness**

The full set of values that satisfy a circuit’s constraints: inputs, intermediate values, and outputs. In zkML, the witness includes the internal activations of the model for a given input. The prover uses the witness to generate a proof, but the witness itself is typically not revealed.

### X

### Y

### Z

**Zero-Knowledge Proof (ZKP)**

A proof that lets a prover convince a verifier that a statement is true (for example, “this model inference was executed correctly”) without revealing any additional information about the inputs or intermediate values. ZKPs must be complete (honest proofs are accepted), sound (false statements are rejected with high probability), and zero-knowledge (no extra information beyond the truth of the statement is leaked).

**zkML (Zero-Knowledge Machine Learning)**

zkML refers to techniques that generate zero-knowledge proofs about machine learning computations. Typical use cases include proving that a model was evaluated correctly on some inputs, without revealing the inputs, model weights, or intermediate activations.

**zk-SNARK**

Short for “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.” A zk-SNARK is a proof system that is succinct (proofs are very small and fast to verify), non-interactive (a single message from prover to verifier), and an argument of knowledge (the prover cannot generate a valid proof without “knowing” a valid witness). zk-SNARKs are widely used in blockchain and zkML systems to prove large computations with small proofs.


# Privacy Policy

\[inference labs]

Inference Labs (“Inference Labs”, “us”, “we”, or “our”) is dedicated to preserving the privacy rights of our users. This Privacy Policy outlines our data collection, usage, and sharing practices in relation to the Inference Labs website, software, and affiliated internal and external services.

1. **Data Collection**

“Personal Data” refers to information that can identify a user, such as names, email addresses, and private details.

“Anonymous Data” refers to information that does not associate with Personal Data and cannot identify users.

We collect both Personal Data and Anonymous Data in a fair and lawful manner. Data is collected only as needed for the purposes outlined in this Policy.

2. &#x20;**Information Provided by Users**

We gather Personal Data and information from users through their use and access of the Service, including but not limited to names, email addresses, and other details that may identify them. Additionally, we collect blockchain addresses, which may be linked to Personal Data when users engage with the Service.

Users can set preferences on the Service, which may be linked to their user ID, browser, or mobile device.

If a user reaches out to us, we may collect their name, email, and the content of their message. We may also obtain Personal Data when users provide it voluntarily or when clearly stated as part of the collection process.

3. **User Information Collected by Technology**

We may use automatic data collection technologies, including as analytics tools, to gather information about your device, software, usage habits, and browsing behaviors when using the Service. Automatic data collection technologies include:

i. **Server Collection**

We, as well as our third-party service providers, may gather technical data about users' devices, including (but not limited to) operating systems, browser types, IP addresses, device IDs, blockchain addresses, and timestamps, to better understand their interactions with the Service.

ii. **Log Files**

We gather certain information automatically and store it in log files, a standard practice. Information stored in log files may include: IP addresses, browser types, ISPs, and operating systems.

iii. **Tracking and Cookies**

We may track your usage of Inference Labs through technologies like web beacons, pixel tags, session cookies, and persistent cookies to gather information. Note that if you choose to disable cookies, your experience with the Service may be impacted.

iv. **Analytics services**

We use automatic data collection technologies that may transmit information to Analytics Services, who may use cookies, log files and other tools to analyze your data. By accessing the Service, you give your consent to these Analytics Services to collect and analyze your data.

4. **Information Collected from Third-Party Companies**

We may collect Personal Data and/or Anonymous Data about users from third-party companies that offer their products and services related to the operation and improvement of the Service.

5. **Information from Blockchains**

We gather information from publicly accessible and visible blockchain activity, including NFT transactions and smart contract data, such as blockchain addresses, purchases, sales, and transfers of digital assets.

6. **Data Collection and Minors**

Inference Labs makes every reasonable effort to keep its platform safe for minors and will make efforts to reject or remove any information regarding individuals under the age of 13, or those under 18 without parental supervision.

7. **Geographic Data Location**

We securely store data collected by automatic technologies in servers located within the continental US, using top data protection and security practices and adhering to all applicable laws.

By using the Service, you agree to the processing of both Personal and Anonymous Data within the US by any automatic collection services or Analytics Services we may utilize.

8. **Using Collected Data**

We process your Personal Data for the purpose of running our business. We analyze both Personal and Anonymous Data to personalize and enhance your experience with Inference Labs, which includes:

•    
Providing the Service and interacting with users and NFTs.\
•    
Securing and facilitating account creation.

\
•    
Identifying users.

\
•    
Supporting administrative functions, user support and communication.

\
•    
Improving the Service through data analysis with Analytics Services.

\
•    
Tailoring user experience through pattern analysis.

\
•    
Detecting and preventing harmful activity, including violations and fraud.

\
•    
Complying with applicable laws and regulations.

We may convert Personal Data into Anonymous Data for trend analysis and to improve user experience. We may use and disclose Anonymous Data for any purpose.

9. **Disclosing Personal Data**

We may share Personal Data:

•    
With trusted analytics providers and entities involved in Inference Labs's restructuring.\
•    
With our affiliated partners bound by this Privacy Policy.\
•    
With relevant authorities if required by law or in an ongoing investigation.\
•    
With consent or at the direction of the user.

10. **Third-Party Websites and Services**

This Policy does not extend to external entities linked to or required for use of the Service.

The security of users' crypto wallets and blockchain assets is the responsibility of the issuing party and not Inference Labs. The use of third-party crypto wallets on the Service is subject to the issuing party's policies.

11. **Privacy Compliance**

Users may be safeguarded by privacy laws relevant to their geographic location, such as PIPEDA in Canada, GDPR in the EU and UK, electronic data protection laws in the US, and similar legislation.

Inference Labs makes every reasonable effort to abide by these regulations and accommodate user requests to assert their rights under applicable privacy laws.

We do not have control or the ability to alter information stored on blockchains.

12. &#x20;**Security**

Inference Labs employs multi-layered security measures to protect all user and service data. In the event of a security breach, we will promptly investigate and resolve the issue, and notify any affected users.

13. &#x20;**Limited Collection**

We keep Personal Data only for as long as you use the Service, including during inactive phases of a Inference Labs account. If Personal Data is not transformed into Anonymous Data, is no longer needed for a user's experience, for Service enhancements, dispute resolution, or legal compliance, it will be deleted permanently.

14. &#x20;**Modification of the Privacy Policy**

This policy is subject to change and revision without prior notice. Any updates will be in effect immediately upon being posted.

15. &#x20;**Contact**

Please address any inquiries, objections, grievances, or worries regarding this Policy or our data preservation and analysis practices to: <privacy@inferencelabs.com>

&#x20;


# Terms of Service

\[inference labs]

Inference Labs drives the development of various leading-edge initiatives in artificial intelligence, Web3 and the blockchain. These are its Terms of Service (the “Terms”).

&#x20;1\. **Agreement to Terms**

These Terms refer to Inference Labs as “the Service”, “we”, “us”, and “our”. The terms “you” and “user” pertain to individuals who use the Service, including those acting on behalf of others.\
\
The terms “user content” refers to any materials that are shared, displayed or submitted by users of the Service, such as images, data, transaction records and feedback.

By accessing and using the Service, you acknowledge and agree to comply with these Terms and all relevant and applicable legislation. Your acceptance of these Terms also implies your agreement to our separate Privacy Policy.  You confirm that you possess the authority to agree to these Terms on behalf of any entity for whom you use the Service.

Inference Labs reserves the right to limit or withdraw user access for violation of these Terms.

2\. **Assumption of risk**

By accessing and using Inference Labs, you acknowledge and accept any associated risks and assume full responsibility. In using the Service, you understand and agree to the following:

•    
Inference Labs is not responsible for disputes between users and third parties.

•    
You are responsible for determining and paying any applicable taxes related to your use of the Service.

•    
You are solely accountable for all interactions and transactions within the Service and on the blockchain.

3\. **Limitation of liability**

Inference Labs does not provide any guarantees regarding the security or the uninterrupted availability of the Service, nor do we warrant the reliability, accuracy, currency or completeness of the information provided via the Service. Inference Labs shall not be held liable for any damages associated with the use of the Service.

4\. **Intellectual property and user content**

Inference Labs owns the rights to all intellectual property used by and created for us. You retain the rights to content you share with, display on, or submit to Inference Labs. Inference Labs reserves the international, non-exclusive right to display and modify user content for the purposes of service improvement or promotion, but does not claim ownership of user content.

5\. **Eligibility**

In using the Service, you must comply with all applicable laws and regulations within your jurisdiction. You must be the age of majority in your jurisdiction or use the Service under the supervision of a legal guardian. Your use of the Service must not involve any illegal activity or prohibited behaviour.

6\. **Prohibited behaviour**

You acknowledge that Inference Labs has zero tolerance for and therefore prohibits any behaviour that has the potential to damage the Service or users of the Service, including but not limited to the exposure of personal information, promotion or distribution of illegal or harmful content, and infringement of intellectual property rights. Inference Labs will handle any illegal activity in full cooperation with applicable legislation.&#x20;

7\. **Modification to Terms**

Inference Labs has the right to modify these Terms at any time, solely at our discretion and without prior notice.

8\. **Contact**

Please address inquiries regarding these Terms to us directly at <privacy@inferencelabs.com>


# Anti-Corruption & Ethics Policy

Version 1.1  |  Effective Date: January 1, 2024 - Last Reviewed: January, 2026

\[inference labs]

This policy applies to all employees, officers, directors, contractors, agents, and any third parties acting on behalf of Inference Labs Inc. (the “Company”). Compliance with this policy is a condition of engagement with the Company.

**1. Commitment to Ethical Business Conduct**

Inference Labs Inc. is committed to conducting business with integrity, transparency, and in full compliance with all applicable laws and regulations. The Company maintains a zero-tolerance policy toward bribery, corruption, and unethical business conduct in any form, regardless of geography or business context.

**2. Anti-Bribery and Anti-Corruption**

No employee, officer, contractor, or representative of the Company may directly or indirectly offer, promise, give, request, or accept any bribe, kickback, or improper payment to or from any person or entity, including government officials, customers, suppliers, or business partners.

The Company complies with all applicable anti-corruption and anti-bribery laws, including:

* [Corruption of Foreign Public Officials Act (Canada)](https://laws-lois.justice.gc.ca/eng/acts/c-45.2/page-1.html)
* [Criminal Code of Canada](https://laws-lois.justice.gc.ca/eng/acts/C-46/page-1.html)
* [Foreign Corrupt Practices Act (USA)](https://www.justice.gov/criminal/criminal-fraud/foreign-corrupt-practices-act)
* [UK Bribery Act 2010](https://www.legislation.gov.uk/ukpga/2010/23/pdfs/ukpga_20100023_en.pdf)

**3. Government Officials**

For purposes of this policy, “government official” means any officer or employee of a government, government-owned or government-controlled entity, public international organization, or any person acting in an official capacity on behalf of any such entity. This includes employees of state-owned enterprises and officials of political parties.

Interactions with government officials must comply with all applicable anti-corruption laws. Employees and representatives may not provide gifts, payments, or any other benefits intended to improperly influence a government decision or action.

**4. Gifts and Business Hospitality**

Reasonable and customary business expenses are permitted in connection with legitimate business activities, provided they are not intended to improperly influence business decisions and comply with applicable laws and this policy. Gifts or hospitality that are excessive in value, provided in cash, or offered in connection with a pending business decision are prohibited.

**5. Conflicts of Interest**

Employees and representatives must avoid situations where personal interests conflict, or could reasonably appear to conflict, with the interests of the Company. Examples include:

* Holding a financial interest in a competitor, supplier, or customer without disclosure
* Engaging in outside employment or consulting that competes with or compromises duties to the Company
* Using Company resources, information, or relationships for personal gain
* Participating in decisions where a personal relationship with a vendor or partner could influence the outcome

Actual or potential conflicts of interest must be disclosed promptly to Company leadership. The Company will determine on a case-by-case basis whether a conflict exists and what steps, if any, are required to mitigate it.

**6. Commissions and Third-Party Payments**

Any commissions, referral fees, or third-party compensation arrangements must be supported by written agreements, reflect fair market value for legitimate services rendered, and comply with applicable laws. Such payments must never be used to facilitate improper or unlawful conduct. Due diligence should be conducted on third parties before entering into such arrangements.

**7. Political Contributions**

Company funds, assets, or resources may not be used to make contributions to political parties, candidates, or campaigns without prior written approval from Company leadership and in compliance with applicable laws. This policy does not restrict employees from making personal political contributions in their individual capacity.

**8. Accurate Records**

The Company maintains accurate books, records, and financial documentation. All transactions must be recorded honestly and reflect their true business purpose. No false, misleading, or incomplete entries shall be made in the Company’s records for any reason.

**9. Reporting and Enforcement**

Employees and representatives are expected to report suspected violations of this policy promptly to Inference Labs Inc. leadership or the designated compliance contact. Reports may be made confidentially where permitted by law.

Retaliation against any individual who reports concerns in good faith will not be tolerated and may itself constitute grounds for disciplinary action.

Violations of this policy may result in disciplinary action up to and including immediate termination of employment or engagement, and may be referred to the appropriate legal or regulatory authorities.

**10. Training and Acknowledgement**

All employees and relevant contractors are expected to read, understand, and comply with this policy. The Company will provide training on this policy as appropriate. Employees may be required to acknowledge in writing that they have received, read, and understood this policy.

**11. Ongoing Compliance and Review**

Inference Labs Inc. will review and update this policy annually, or more frequently as required to ensure continued compliance with applicable laws and evolving business practices. The current version of this policy will be maintained and made available to all relevant parties.

**Questions and Compliance Contact**

For questions regarding this policy, to report a concern, or to request guidance, please contact:

Compliance Contact: <shared@inferencelabs.com>

Inference Labs Inc.  |  [www.inferencelabs.com](http://www.inferencelabs.com)

<br>