System Architecture
ZKAP operates as a privacy-preserving transport layer that sits between applications and blockchain execution environments. Instead of replacing smart contracts or introducing a new VM, ZKAP focuses on transforming how requests are sent, verified, and consumed.
Below is a breakdown of how the system is structured and how each component interacts with the others.
1. High-Level Architecture
ZKAP consists of four main components:
Client / Agent
ZKAP Proof Generator
ZKAP Frame & Validator Contract
Application Decryption & Execution Layer
The architecture can be viewed as a pipeline:
Client / Agent → Build Payload → Encrypt Payload → Generate Zero-Knowledge Proof → Build ZKAP Frame → Submit to Validator Contract → Application receives encrypted event → Application decrypts payload → Application executes logic
ZKAP does not replace application logic or smart contracts. It replaces how actions are transported into those applications.
2. Component Overview
2.1 Client / Agent Layer
This is where the action originates.
A sender:
creates an anonymous identity
builds a private payload
encrypts the payload
generates the ZK proof
constructs a ZKAP Frame
Senders can be:
user wallets
backend services
autonomous agents
bots
off-chain logic engines
The sender never reveals identity or metadata.
2.2 ZK Proof Generator
This component verifies validity without revealing inputs.
The proof system ensures:
payload format is correct
identity is formed correctly
nullifier derives correctly
expiry is not exceeded
action matches commitment
The proof generator can be:
client-side
agent-side
server-side (trusted by no one, because ZK guarantees correctness)
2.3 ZKAP Frame Transport Layer
This is the encrypted message sent to the blockchain.
A ZKAP Frame contains:
zk_proof
commitment_root
encrypted payload
nullifier
session hash
expiry block
The blockchain only sees encrypted bytes and a ZK proof. Nothing in the frame leaks identity or metadata.
2.4 ZKAP Validator Contract
The validator contract:
verifies the ZK proof
checks nullifier replay
checks expiry block
emits an encrypted event
The validator never sees:
sender address
input parameters
function selector
calldata
It only ensures correctness.
2.5 Application Execution Layer
The final layer is the receiving application.
The application:
subscribes to ZKAP Validator events
decrypts the payload using its key
reads the private action
executes normal business logic
Examples:
DEX processes a private swap
Bridge processes a private cross-chain command
Agent orchestrator handles a task
RFQ engine receives a private quote request
Governance module reads a private action
The application sees the instruction, but never sees who sent it.
3. Architecture Diagram (Text Version)
User / Agent → (Generate Identity) → (Encrypt Payload) → (Generate ZK Proof) → Build ZKAP Frame → Submit Frame to Validator
Validator Contract → Verify Proof → Check Nullifier → Emit AnonymousEvent
Application → Listen for AnonymousEvent → Decrypt Payload → Execute Logic
4. Key Architectural Principles
Privacy lives at the transport layer, not the VM layer
All requests are encrypted end-to-end
Validity is proven with zero knowledge
No identity or metadata is ever exposed
Applications do not need redesign
Agents can operate without keys or EOAs
Multi-chain routing works without leakage
Stateless architecture simplifies scaling
5. Why This Architecture Works
This system architecture enables:
anonymity without trusted servers
validity without revealing inputs
privacy without new blockchains
fast integration for developers
safe execution for agents
protection from MEV and surveillance
ZKAP is architecture-first: it solves privacy at the foundational transport layer, not at the application or VM level.
Last updated