> 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/end-to-end-example.md).

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