> 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/stateless-execution.md).

# 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

In ZKAP:

* each swap has its own identity
* each swap has no relation to another
* no session exists
* no on-chain traces link the actions

Each action is an isolated, anonymous request.