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