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:

{
  "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