End-to-End Example
This section walks through a complete example of how a ZKAP request flows from a user or agent into an application. It shows the full lifecycle: identity → payload → proof → frame → validation → execution.
The goal is to help developers and users visualize how ZKAP works in practice.
1. Scenario Overview
A user wants to perform the following action:
“Swap 500 USDC → ETH privately on a DEX without revealing identity, calldata, or routing information.”
The same process applies to:
bridge commands
agent instructions
governance actions
RFQ requests
cross-chain intent
private automation tasks
2. Step-by-Step Flow
Step 1 — User/Agent prepares a private payload
Example payload (in plaintext before encryption):
{ "action": "swap", "tokenIn": "USDC", "tokenOut": "ETH", "amount": "500", "minOut": "0.3", "expiry": 12345678 }
This stays entirely off-chain.
Step 2 — Generate an Anonymous Identity
The sender creates an ephemeral, unlinkable identity.
This identity:
does not belong to a wallet
has no signature
disappears after use
cannot be correlated across actions
It exists only for proving validity inside the ZK circuit.
Step 3 — Encrypt the Payload
The full payload is encrypted using a symmetric key. Output = ciphertext.
No node, relayer, or contract can read the content.
The ciphertext hides:
amount
token pairs
routing logic
intent structure
any user metadata
Step 4 — Generate the Zero-Knowledge Proof
The user generates a ZK proof that asserts:
the payload is valid
the identity is valid
the nullifier is derived correctly
the expiry block matches
the payload commitment is correct
But reveals none of the actual data.
Proof output = zk_proof.
Step 5 — Construct the ZKAP Frame
A ZKAP Frame is built:
{ "zk_proof": "...", "commitment_root": "0xabc...", "payload_ciphertext": "0xff12...", "nullifier": "0xdef...", "session_hash": "0x9988...", "expiry_block": 12345678 }
This is the only structure that goes on-chain.
No sender. No signature. No calldata. No visible action. No metadata.
Step 6 — Submit Frame to the ZKAP Validator Contract
The validator does three things:
verify the ZK proof
check nullifier reuse
check expiry block
If valid → the validator emits:
AnonymousAction(commitment_root, payload_ciphertext)
This becomes the application’s input.
Step 7 — Application decrypts the payload
The DEX backend receives the event.
It decrypts the ciphertext using its decryption key.
It recovers the original payload:
{ "action": "swap", "tokenIn": "USDC", "tokenOut": "ETH", "amount": "500", "minOut": "0.3" }
Step 8 — Application executes the logic normally
The DEX executes the swap exactly as a standard swap:
routing logic
slippage checks
liquidity selection
settlement logic
But without ever knowing:
who the user was
where request originated
which address submitted it
what user behavior pattern looks like
3. Final Summary
The complete lifecycle:
Prepare Payload → Encrypt → Generate ZK Proof → Build Frame → Submit Frame → Validator Verifies → Anonymous Event Emitted → App Decrypts → App Executes Logic
ZKAP transforms blockchain interactions from being transparent and identifiable into anonymous and encrypted — while keeping everything valid and executable.
Last updated