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.
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:
This action is encoded into a payload.
Example:
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
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
nullifier is correctly derived
expiry is inside allowed range
action type matches the commitment
The proof does not reveal:
It only proves “this request is valid.”
📦 5. Everything is wrapped into a ZKAP Frame
A ZKAP Frame is created:
This is the only thing sent to the blockchain.
There is no:
🛡️ 6. Submit the Frame to the ZKAP Validator Contract
The validator contract checks:
check nullifier (prevent replay)
If all good → it emits an AnonymousAction event.
Example (conceptually):
Apps see only encrypted data.
📥 7. Application decrypts the payload and executes logic
Now the application (DEX, wallet, agent orchestrator, bridge service…) does:
listens for AnonymousAction events
decrypts the ciphertext using its key
reads the user’s private request
executes the logic normally
The application learns:
But never learns:
