> 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