Stateless Execution

ZKAP is built around a fully stateless execution model, meaning the protocol does not store persistent user information, session data, identity records, or any form of long-term state. This design is essential for guaranteeing true anonymity, eliminating correlation risks, and enabling large-scale private interactions across chains.

This section explains why statelessness matters, how ZKAP achieves it, and what advantages it brings compared to traditional blockchain systems.

1. Why state is dangerous for privacy

In most blockchain systems and applications, state leaks information:

account balances
sequence numbers
nonces
persistent identities
session history
“last used address”
behavior patterns over time

Whenever a protocol keeps state about users, it creates opportunities for:

correlation attacks
identity reconstruction
behavior clustering
deanonymization

Even mixers or private pools leak metadata over time if they track participant state.

ZKAP avoids all of this by design.

2. What “stateless” means in ZKAP

ZKAP does not maintain:

no user accounts
no balances
no identity registry
no session logs
no address history
no action history

The protocol does not need these because:

identity is ephemeral
payload is encrypted
validity is enforced by ZK proofs
replay prevention uses nullifiers only
expiry ensures time-bounded correctness

The only state stored by the validator contract is a set of nullifiers.

3. The only stored state: nullifiers

A nullifier is a hash that prevents replay attacks.

The validator keeps:

nullifierUsed[nullifier] = true

This is the only long-term record.

A nullifier does not reveal:

identity
address
payload content
action type
amount
any metadata

It is purely a one-bit flag: “this action cannot be reused.”

This ensures replay safety without compromising anonymity.

4. Why ZKAP doesn’t need sessions

Other systems require sessions to maintain:

authentication
request ordering
state progression
signature validity
multi-step flows

ZKAP eliminates all of these requirements.

Each action is:

self-contained
proven valid independently
unlinkable from previous actions
does not rely on global user state

This allows each request to stand alone without needing a continuous session.

5. Statelessness enables horizontal scaling

Because ZKAP does not maintain user or session state:

any number of validators can verify frames
relayers do not need to track user context
multi-chain execution becomes simple
agents can interact across thousands of chains
every action is independent

Stateful systems slow down and break under many agents. ZKAP scales effortlessly because it does not track users at all.

6. No nonce, no sequence, no address history

In ZKAP:

there is no nonce tied to an address
there is no global account sequence
there is no “account state” to refer to

Every request is valid or invalid based solely on the proof.

This dramatically simplifies both the protocol and application integration.

7. Benefits of stateless execution

Perfect unlinkability

No state = no way to correlate user actions.

High scalability

Stateless systems scale horizontally with no bottlenecks.

Multi-chain compatible

No shared state = instant compatibility across L1/L2/L3/app-chains.

Agent-friendly

Agents can execute unlimited actions without identity or key management.

Simpler integration

Applications don’t need to maintain user sessions or account state.

Strong privacy

Without stored state, long-term analysis becomes impossible.

8. Example: Stateless private swaps

A user performs:

swap A
swap B
swap C

In a normal blockchain, these swaps share:

the same address
the same nonce sequence
the same signature
predictable patterns