> For the complete documentation index, see [llms.txt](https://mixfun.gitbook.io/mixfun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mixfun.gitbook.io/mixfun/overview/how-privacy-works.md).
# How Privacy Works
> The three ideas behind every MixFun flow: shared pools, zero-knowledge proofs, and optional relayers.
Every privacy flow on MixFun uses some combination of three ideas. Understanding these three ideas makes every flow easier to follow.
## Shared pools
A pool is a Solana program account that holds many users' deposits in one place. When you deposit into a pool, your deposit joins every other active deposit in that pool. When someone withdraws, the pool pays out from its total balance.
The pool does not know who deposited. It does not need to. All it knows is that a valid withdrawal proof means a valid withdrawal.
The number of active deposits in a pool is called the anonymity set. A pool with 2 active deposits gives you 1-in-2 privacy. A pool with 1,000 gives you 1-in-1,000. The bigger the pool, the harder any individual deposit is to trace to a withdrawal. See [Anonymity sets](/mixfun/concepts/anonymity-sets.md).
Pool liquidity and anonymity are the same thing in MixFun. A pool with N active deposits holds N denominations' worth of tokens, ready to pay out to N valid proofs. You never wait for external liquidity; withdrawals always clear as long as your proof is valid.
## Zero-knowledge proofs
A zero-knowledge proof is a short piece of data that convinces a verifier something is true without revealing why it is true.
At withdrawal time, you prove two things to the pool:
* You know the secret behind a real deposit.
* You have not already spent that deposit.
You prove both without revealing which deposit is yours. The proof is generated locally in your browser, so your secret never leaves your device.
MixFun uses a proof system called Groth16. Every withdrawal is gated by a proof that takes a fraction of a second to generate and verify, and the proof reveals nothing beyond "this withdrawal is valid".
## Optional relayers
When you deposit into a pool, you use a wallet with some SOL, to pay the Solana gas for the deposit. When you withdraw, you need SOL again, to pay gas for the withdrawal.
But what if you want to withdraw into a fresh, empty wallet? A wallet with no prior history, to keep the withdrawal maximally unlinked?
The relayer solves this. You send your withdrawal proof to MixFun's relayer, and the relayer submits the transaction on your behalf. The relayer pays the Solana gas and keeps a small portion of your withdrawal as payment.
Relayers are optional. If your receiving wallet already has SOL for gas, you can withdraw directly and skip the relayer fee. See [Relayers](/mixfun/concepts/relayers.md).
## How the three combine
Each MixFun flow picks a different mix:
* **Private Send and Shielded Pools** use all three: shared pools, ZK proofs, and an optional relayer.
* **Private Swap** uses shared pools plus ZK proofs, and adds an intent engine that matches complementary swaps (or falls back to Jupiter V6).
* **Stealth Transfers** uses none of them. Stealth relies on cryptography at the address layer (one-time addresses derived from the recipient's public keys) rather than pools.
See it in action
Private Send is the simplest flow that exercises all three concepts.
---
# 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://mixfun.gitbook.io/mixfun/overview/how-privacy-works.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.