# Zero-Knowledge Proofs (ZK)

Purpose

ZK proofs in OpenShard serve a specific and bounded purpose: they allow a buyer to demonstrate that it holds valid credentials without disclosing the underlying Ethereum account address to the seller. Sellers verify these proofs before processing any protected inference request, which means the seller can enforce access control and validate buyer legitimacy without ever learning who the buyer actually is. This is the foundational layer of identity privacy in the system.

Commitment-Based Identity

The buyer derives a buyer commitment — a cryptographic commitment value computed from its identity material — which replaces the raw EOA in all externally visible request fields. The commitment serves as the buyer's externally shared identity anchor across requests and payment channels. Because the commitment is a one-way derivation, the seller cannot reverse it to recover the underlying account address. The actual EOA never appears in a normal inference payload under this model.

Proof Mechanics

When a buyer constructs a privacy-enabled inference request, it generates a ZK proof alongside the commitment. This proof attests that the commitment was derived correctly from valid underlying credentials, without revealing those credentials. The proof artifact is included in the request payload and transmitted to the seller alongside the commitment value and the encrypted inference content.

The seller invokes the proof verification logic from the credentials package before performing any other request processing. If verification fails, the request is rejected immediately. If verification succeeds, the seller proceeds with ECDH decryption, payload decryption, and payment validation. The proof check is the first gate in the seller's verification pipeline, ensuring that malformed or fraudulent credentials cannot cause any downstream processing to occur.

Nullifier Binding

Each ZK proof is bound to a nullifier — a value derived from the proof context that uniquely identifies this specific proof instance. After a proof passes verification, the seller extracts the nullifier and stores it in the replay nullifier cache. Any subsequent request arriving with a nullifier already present in the cache is rejected as a replay. This binding ensures that an intercepted request — complete with a valid proof, encrypted payload, and payment authorization — cannot be resubmitted by an attacker to obtain additional inference.

Payment Proof Separation

The ZK identity proof is structurally independent from the payment authorization proof. A buyer's commitment-backed identity governs who can submit requests under a given payment channel, while the spending authorization governs how much cumulative spend has been authorized in that channel. These are validated by different mechanisms in the seller's pipeline. This separation means the economics of an inference session — who paid, how much, for what — are validated independently from identity privacy, and neither layer is required to disclose information that belongs to the other.

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.openshard.ai/core-concepts/privacy-mechanism/zero-knowledge-proofs-zk.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.