Privacy Guarantees

ZKAP provides a comprehensive privacy model designed to eliminate identity exposure, metadata leakage, behavioral correlation, and transaction visibility. These guarantees hold across chains, across applications, and across repeated user or agent activity.

This section outlines the exact privacy guarantees ZKAP offers, why they matter, and how they are enforced at the protocol level.


1. Complete Sender Anonymity

ZKAP fully removes the concept of a visible sender. There is no:

  • address

  • public key

  • signature

  • wallet lineage

  • account history

  • linkage to past interactions

Applications and contracts never learn who initiated the action.

The only public elements are:

  • proof (zero-knowledge)

  • nullifier (unlinked, one-time)

  • encrypted payload

Nothing within the frame identifies the sender.


2. Unlinkability Between Actions

ZKAP ensures that two actions cannot be linked to the same user or agent.

Each request uses:

  • a fresh anonymous identity

  • a fresh session hash

  • a unique nullifier

  • no persistent state

  • no signatures

This eliminates behavior tracking:

  • no correlation of swaps

  • no linking of agent commands

  • no traceable cross-chain behavior

  • no profiling of user patterns

Even the application decrypting the payload has no way to identify the sender.


3. Metadata Erasure

ZKAP removes all metadata normally exposed by blockchain or RPC interactions, including:

  • function selector

  • calldata structure

  • parameters

  • gas usage patterns

  • account nonces

  • signature scheme

  • signing algorithm fingerprints

  • timing clues from the sender

  • RPC call fingerprints

  • transaction propagation patterns

Everything is replaced by:

  • encrypted data

  • uniform frame structure

  • zero-knowledge proof validation

There are no metadata fingerprints left to analyze.


4. Encrypted Action Payloads

All action content is encrypted:

  • token types

  • amounts

  • strategy parameters

  • routing preferences

  • agent instructions

  • governance actions

  • cross-chain intents

  • encoded conditions

Because encryption is symmetric and end-to-end:

  • the blockchain cannot decrypt the payload

  • relayers cannot decrypt the payload

  • block explorers cannot decrypt the payload

  • MEV bots cannot read intent

  • RPC nodes cannot view content

Only the receiving application can decrypt the payload.


5. No Behavioral Traceability

ZKAP eliminates all long-term consistency and patterns that normally allow analysts to reconstruct user behavior.

There is:

  • no persistent address

  • no stored sessions

  • no public account sequence

  • no signature type fingerprint

  • no derived entropy reuse

  • no ordering clues

  • no visible transaction graph

Every ZKAP action is indistinguishable from every other ZKAP action.

This creates a privacy environment where:

  • inference attacks fail

  • clustering attacks fail

  • behavioral timelines cannot be built

  • machine learning deanonymization is ineffective


6. Cross-Chain Privacy Preservation

ZKAP maintains full privacy even when the action spans multiple chains or rollups.

Cross-chain intent flows normally expose:

  • source chain

  • target chain

  • bridge type

  • routing

  • liquidity paths

  • relayer patterns

ZKAP hides all of this by encrypting the end-to-end payload and using domain-separated nullifiers.

Observers cannot see:

  • the chain path

  • the purpose

  • the strategy

  • the sender

  • the destination logic

This allows private, multi-hop execution across L1s, L2s, and app-chains.


7. Protection Against MEV and Surveillance

Because intent, payload, and routing are hidden:

  • sandwich attacks are impossible

  • backrun extraction becomes impossible

  • RFQ offers cannot be intercepted

  • cross-chain relay strategies cannot be predicted

  • private orderflow cannot be leaked

  • internal routing logic stays confidential

On-chain surveillance — from analytics, indexers, MEV bots, RPC providers — sees nothing but encrypted frames.


8. Replay-Resistant Without Identity Leakage

Nullifiers provide replay protection without identity exposure.

A nullifier:

  • is unique

  • cannot be reused

  • does not reveal sender

  • is safe to publish

Nullifiers allow ZKAP to remain stateless while still secure.


9. Time-Bounded Privacy Through Expiry Enforcement

The expiry block ensures requests:

  • cannot be delayed by relayers

  • cannot be reordered maliciously

  • cannot be held for strategic leakage

  • cannot be replayed far into the future

This protects against timing-based metadata analysis.

Last updated