> For the complete documentation index, see [llms.txt](https://docs.zama.org/protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zama.org/protocol/confidential-vault/concepts/confidentiality.md).

# Confidentiality

What an observer can and cannot see, what batching guarantees, and the known limits.

The protocol's confidentiality claim is precise: **no observer can attribute any part of a batch's aggregate to an individual participant.** Amounts are encrypted end to end; only sums become public. This page draws the boundary of that claim, including its known limits.

## What an observer sees

| Public                                            | Encrypted                               |
| ------------------------------------------------- | --------------------------------------- |
| Who joined a batch (addresses, timestamps)        | How much each participant joined with   |
| The batch's decrypted **aggregate** amount        | Each participant's position handle      |
| The batch's exchange rate after finalization      | Each participant's claimed amount       |
| The direction (deposit vs. redeem) and batch id   | Confidential token balances             |
| Wrap ("shield") amounts — public ERC-20 transfers | The confidential total supply of cShare |
| Unwrap ("unshield") amounts, per user             |                                         |

Batch metadata is fully transparent: an indexer can reconstruct every batch, its participants, and its aggregate. The split of that aggregate across participants stays encrypted. Each user can decrypt and verify their own values — position, claim, balance — independently.

## How batching creates confidentiality

Each batch is a mixing round. If ten users join a batch that settles 1,240,000 USDC, an observer learns the total and the ten addresses — and nothing else. Any split among the ten consistent with the total is equally plausible. The anonymity set of a deposit is the set of its batch's co-participants.

This holds cryptographically: individual amounts exist on-chain only as ciphertext handles, the batcher aggregates them homomorphically, and the Zama protocol decrypts exactly one value per batch — the sum — with a verifiable proof.

## Known limits

Confidentiality is a best-effort property with three limits.

{% hint style="warning" %}
**A lone depositor is fully revealed** The dispatch gate is age-only, with no minimum participant count. A batch that reaches its minimum age with a single depositor reveals that depositor's exact amount when the aggregate is decrypted — the sum of one value is the value. Expect degraded guarantees during low-traffic periods.
{% endhint %}

There is no minimum participant count because amounts are encrypted: anyone can pad a batch with encrypted-zero joins, so a `minParticipants` gate would report an anonymity set it cannot verify.

**Shield–join correlation.** Wrapping USDC into cUSDC is a public transaction. A user who wraps 50,000 USDC and joins a batch minutes later has effectively published only the upper bound on their join amount. The correlation weakens with time, with balance reuse, and with unrelated wrapper activity — wrapping early, or holding a standing confidential balance, avoids it.

**Aggregate arithmetic across batches.** Anyone can chart the protocol's total flows over time. With few participants, differencing consecutive aggregates can bound (though never reveal) individual contributions.

**The vault you join is public.** Joining a batcher is a public transaction. To hide which vault received the money, send the same [router](/protocol/confidential-vault/concepts/multi-vault-router.md) call as every other user, with encrypted-zero legs for the vaults you did not pick.

The accurate one-line claim, for apps that surface the model to their users:

> Your deposit amount is hidden among the other deposits in your batch. Who you are, when you deposited, and the batch's total are public.

## What is trusted

The Zama Protocol is trusted for two things: computing correctly on ciphertexts, and decrypting only what the protocol marks publicly decryptable — batch aggregates and unwrap amounts. Decryptions carry KMS proofs the contracts verify on-chain. See [Trust Model](/protocol/confidential-vault/concepts/trust-model.md) for the full trust surface.

## Next steps

* [Batch Lifecycle](/protocol/confidential-vault/concepts/batch-lifecycle.md) — when the aggregate becomes public.
* [Architecture](/protocol/confidential-vault/concepts/architecture.md) — why deposits are batched.
* [Zama Protocol documentation](https://docs.zama.ai/protocol) — the FHEVM trust and threat model.


---

# 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://docs.zama.org/protocol/confidential-vault/concepts/confidentiality.md?ask=<question>&goal=<endgoal>
```

`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.