> 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/concepts/encrypted-frames.md).

# Encrypted Frames

ZKAP introduces a new request format called the **ZKAP Frame** — an encrypted, zero-knowledge-validated message that replaces traditional blockchain transactions.\
Instead of sending cleartext calldata, addresses, signatures, and function selectors, every action is wrapped inside an encrypted frame that reveals **nothing** about the sender or the intent.

This section explains what a ZKAP Frame is, why it exists, and how it transforms the privacy model of Web3.

***

### 1. The problem with normal blockchain requests

Traditional transactions reveal:

* the sender’s address
* the function being called
* the parameters
* the amounts
* the tokens involved
* the routing logic
* explicit metadata
* behavioral patterns

Once submitted, this information becomes publicly visible forever.

This makes every blockchain user and application vulnerable to:

* MEV attacks
* surveillance
* address clustering
* strategy extraction
* unwanted correlation

ZKAP Frames completely remove these leak points.

***

### 2. What is a ZKAP Frame?

A ZKAP Frame is an **encrypted, structured request object** verified by a zero-knowledge proof and consumed by the ZKAP Validator.

A frame contains:

* zk\_proof
* commitment\_root
* encrypted payload (ciphertext)
* nullifier
* session hash
* expiry block

Everything except the zk\_proof and nullifier is encrypted or opaque.

The blockchain does **not** see:

* addresses
* calldata
* function selector
* token pairs
* execution details
* any form of identity

It receives only the frame.

***

### 3. Why encrypt the payload?

Encryption ensures:

* complete confidentiality of action details
* no function call is visible
* no token identifiers leak
* no amounts leak
* no strategy or behavior is revealed
* no front-running or MEV insight
* the application alone can interpret the request

Even if someone downloads all historical ZKAP Frames, they learn **nothing**.

***

### 4. How the encrypted payload works

The payload is encrypted using a symmetric encryption scheme:

* AES-GCM
* or ChaCha20-Poly1305

The encryption provides:

* confidentiality
* authenticity
* integrity protection
* tamper resistance

Only the sender and the receiving application share the decryption key.

The blockchain, nodes, relayers, or indexers cannot decrypt it.

***

### 5. The role of each field inside the ZKAP Frame

#### zk\_proof

Proves that the payload is valid without revealing it.

#### commitment\_root

A hash binding the payload and expiry to ensure integrity.

#### encrypted\_payload

Contains the actual instruction for the application — but is unreadable to everyone else.

#### nullifier

Prevents replay attacks while revealing no identity.

#### session\_hash

Ensures ephemeral, non-linkable context.

#### expiry\_block

Defines the time window in which the request is valid.

***

### 6. What a ZKAP Frame replaces

A normal Ethereum transaction includes:

* from address
* signature
* gas parameters
* calldata
* function selector

A ZKAP Frame replaces all of these with one object.

There is no:

* sender
* public key
* function selector
* calldata
* visible action
* transaction graph

This provides true privacy at the transport level.

***

### 7. Benefits of using encrypted frames

#### Full confidentiality

Applications are the only entities able to decrypt the instruction.

#### MEV protection

Nothing in the frame reveals intent or routing.

#### Metadata elimination

Frames remove all traces of:

* behavioral patterns
* signature schemes
* RPC fingerprints
* address history

#### Cross-chain transparency removal

Intent and routing data remain fully encrypted across chains.

#### Universal format

ZKAP Frames allow any application to plug into privacy without redesigning smart contracts.\
**validity without visibility, execution without exposure.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zka-protocol.gitbook.io/zka-protocol-docs/concepts/encrypted-frames.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.