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:

1. verify the ZK proof

2. check nullifier reuse

3. 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.