> 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://zka-protocol.gitbook.io/zka-protocol-docs/concepts/stateless-execution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.