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.
Last updated