> For the complete documentation index, see [llms.txt](https://zka-protocol.gitbook.io/zka-protocol-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zka-protocol.gitbook.io/zka-protocol-docs/concepts/zk-validity.md).

# ZK Validity

Zero-knowledge validity is one of the core pillars of ZKAP.\
It ensures that every encrypted action submitted through the protocol is **correct, authorized, and well-formed**, without revealing anything about the content or the sender.

This section explains what “validity” means in ZKAP, how zero-knowledge proofs enforce it, and why this mechanism enables anonymous execution at scale.

***

### 1. The challenge: validating actions without seeing them

In traditional blockchains:

* contracts inspect calldata
* contracts verify signatures
* contracts check parameters
* nodes validate sender identity and nonce

This is impossible when the payload is encrypted.

ZKAP solves this with zero-knowledge proofs, allowing the protocol to validate requests **without exposing any inputs**.

***

### 2. What “validity” means inside ZKAP

A ZKAP action is considered *valid* if:

1. The identity used in the proof is correctly formed
2. The payload structure is correct
3. The commitment matches the encrypted payload
4. The nullifier is derived properly
5. The action is still within the expiry window
6. The request is not a replay

All of these checks are performed inside the ZK circuit, not on the blockchain.

The blockchain only sees a yes/no proof result.

***

### 3. The zero-knowledge proof enforces correctness

The proof guarantees:

* the payload is well-formed
* all constraints are satisfied
* no invalid or manipulated data is included
* the sender’s identity is valid, but never revealed
* the nullifier is generated correctly
* expiry rules are respected

Nothing about amounts, tokens, routing, or parameters becomes public.

***

### 4. Validity without identity

Normally, identity is required to validate actions:

* Ethereum uses signatures from EOAs
* Cosmos uses account sequences
* Solana uses signer accounts

ZKAP eliminates this requirement.

Instead of showing *who* sent the action, ZKAP shows:

* “I am allowed to perform this action”
* “This payload is valid”
* “I followed the protocol rules”

But never reveals the sender’s identity or signature.

***

### 5. Public and private inputs in ZKAP proofs

The proof contains:

#### Private inputs (hidden)

* ephemeral identity
* payload hash
* nonce
* expiry
* constraints / parameters

#### Public outputs (visible)

* nullifier
* commitment root

These public outputs allow the blockchain to do verification without knowing anything about the private inputs.

***

### 6. Why the blockchain can trust the proof

The blockchain verifies:

* the proof matches the circuit
* the circuit enforces correct rules
* the nullifier isn't reused
* the expiry is still valid

Because zero-knowledge proofs are cryptographically binding,\
the validator contract can trust the proof *fully* without inspecting any plaintext data.

This is what allows ZKAP to maintain:

* privacy
* correctness
* stateless execution
* anonymous submitters

all at the same time.

***

### 7. Benefits of ZK-based validity

#### No need for signatures

Proofs replace signature authentication.

#### No visible calldata

The proof verifies structure without showing it.

#### No replay attacks

The nullifier is publicly checkable.

#### No identity leakage

Proofs hide all identity and metadata.

#### No need for application-specific circuits

ZKAP circuits are generic and reusable.

#### No trust assumptions

The contract verifies everything independently.

***

### 8. Example: validating a private swap

The proof asserts:

* action type = swap
* amount > 0
* expiry > current block
* nullifier is unique
* commitment matches encrypted payload
* routing constraints are valid

But never reveals:

* which token
* how much
* which pool
* who is swapping

The application decrypts the payload **only after** the proof succeeds.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://zka-protocol.gitbook.io/zka-protocol-docs/concepts/zk-validity.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.