> 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/getting-started/how-zkap-works.md).

# How ZKAP Works

ZKAP changes **how applications interact with blockchains**.\
Instead of sending raw transactions that expose addresses, calldata, and signatures,\
ZKAP wraps every action inside an **encrypted, zero-knowledge–validated frame**.

This turns Web3 execution from:

❌ “Public transaction with sender → contract”\
into\
🟣 “Encrypted request → ZKAP Validator → Clean action for the app”

Below is a simple explanation of the process.

***

## 🧩 1. User/Agent generates an Anonymous Identity

Every action starts with an **ephemeral ZK identity**.

* not an EOA
* no private key
* no wallet
* cannot be linked
* disappears after use

This identity is used **only** inside the zero-knowledge proof.

No part of it ever becomes public.

***

## 🔐 2. Build a Private Payload

The user (or agent) prepares their action:

* swap
* deposit
* RFQ request
* governance vote
* agent instruction
* cross-chain intent

This action is encoded into a **payload**.

Example:

```json
{
  "action": "swap",
  "tokenIn": "USDC",
  "tokenOut": "ETH",
  "amount": "500",
  "minOut": "0.3",
  "expiry": 12345678
}
```

But the application **never sees this raw data**.

***

## 🔒 3. Encrypt the Payload

The payload is encrypted with a **session key**:

* AES-GCM or ChaCha20-Poly1305
* unique IV/nonce
* authenticated ciphertext

Result = `payload_ciphertext`

Only the sender and the destination application can decrypt it.

***

## 🧠 4. Generate a Zero-Knowledge Proof of Validity

The user generates a ZK proof showing:

* the payload is well-formed
* identity is valid
* nullifier is correctly derived
* expiry is inside allowed range
* action type matches the commitment

The proof does **not** reveal:

* the sender
* content of the payload
* any metadata
* any parameters

It only proves **“this request is valid.”**

## 📦 5. Everything is wrapped into a ZKAP Frame

A ZKAP Frame is created:

```
ZKAPFrame {
  zk_proof,
  commitment_root,
  payload_ciphertext,
  nullifier,
  session_hash,
  expiry_block
}
```

This is the **only** thing sent to the blockchain.

There is no:

* address
* signature
* calldata
* function selector

***

## 🛡️ 6. Submit the Frame to the ZKAP Validator Contract

The validator contract checks:

1. **verify ZK proof**
2. **check nullifier** (prevent replay)
3. **check expiry block**

If all good → it emits an **AnonymousAction event**.

Example (conceptually):

```
AnonymousAction(
   commitment_root: 0xabc...123,
   payload_ciphertext: 0xff23...
)
```

Apps see **only encrypted data**.

## 📥 7. Application decrypts the payload and executes logic

Now the application (DEX, wallet, agent orchestrator, bridge service…) does:

1. listens for `AnonymousAction` events
2. decrypts the ciphertext using its key
3. reads the user’s private request
4. executes the logic normally

The application learns:

* what action to execute
* what parameters to use

But **never** learns:

* who the sender is
* their address
* their signature
* their identity
* their usage patterns


---

# 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/getting-started/how-zkap-works.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.