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

# Architecture

How confidential token wrappers, vault batchers, and public ERC-4626 vaults fit together.

The protocol connects two kinds of tokens. **Confidential tokens** are ERC-7984 tokens whose balances are encrypted values on Zama FHEVM. A **public ERC-4626 vault** generates yield. Between them sits the **batcher**: a contract that pools encrypted deposits, settles the pooled total against the vault in one public transaction, and distributes the proceeds back as encrypted balances.

## Contracts

Each vault has two batchers and a confidential share token. Vaults with the same underlying share one confidential asset token, so every USDC vault on a chain uses the same cUSDC. One router per chain joins several batchers in one transaction. For one vault, the wiring is:

```mermaid
flowchart LR
    USDC["USDC<br/>(public ERC-20)"]
    cUSDC["cUSDC<br/>ERC7984ERC20Wrapper"]
    Vault["ERC-4626 vault"]
    cShare["cShare<br/>ERC7984ERC20Wrapper"]
    DB["Deposit batcher"]
    RB["Redeem batcher"]

    USDC <-- "wrap / unwrap" --> cUSDC
    Vault <-- "wrap / unwrap" --> cShare
    cUSDC -- "encrypted joins" --> DB
    DB -- "deposit(assets)" --> Vault
    Vault -- "shares" --> cShare
    cShare -- "encrypted joins" --> RB
    RB -- "redeem(shares)" --> Vault
    Vault -- "assets" --> cUSDC
```

| Contract                          | Role                                                                                             |
| --------------------------------- | ------------------------------------------------------------------------------------------------ |
| `cUSDC` (`ERC7984ERC20Wrapper`)   | Wraps public USDC into confidential USDC. Balances are encrypted `euint64` handles.              |
| `cShare` (`ERC7984ERC20Wrapper`)  | Wraps the vault's public share token into confidential shares.                                   |
| ERC-4626 vault                    | A third-party yield vault. Deployed vaults per network are listed in the address reference.      |
| `DepositVaultBatcherConfidential` | Pools confidential USDC, deposits the aggregate into the vault, distributes confidential shares. |
| `RedeemVaultBatcherConfidential`  | Pools confidential shares, redeems the aggregate from the vault, distributes confidential USDC.  |
| `VaultBatcherConfidentialRouter`  | One per chain. Joins several batchers in one transaction, with encrypted-zero legs as decoys.    |

In these docs, the **batcher** always refers to this protocol's contract and the **vault** always refers to the third-party ERC-4626 contract.

The router sends one user's amount to several batchers at once. Legs with an encrypted zero hide which vault received the money, so users of the same app share one anonymity set across vaults. Each leg credits the user in that batcher, and the router keeps no funds. A user who wants one vault joins its batcher directly. See [Multi-Vault Router](/protocol/confidential-vault/concepts/multi-vault-router.md).

Some vaults are exclusive to the protocol: a `WhitelistSendAssetsGate` on the Morpho vault lets only the deposit batcher deposit, so the vault can be entered only confidentially. Redemptions are never gated. The gate address per vault is in [Contract Addresses](/protocol/confidential-vault/reference/addresses.md).

The token wrappers are shared Zama protocol infrastructure. The protocol resolves them by address from the Zama protocol registry and verifies at deploy time that each wrapper wraps the expected underlying.

## Why deposits are batched

An ERC-4626 vault accepts only public ERC-20 transfers, so a user who deposited alone would reveal their exact amount. The batcher aggregates instead: many users join a batch with encrypted amounts, and only the **sum** is decrypted. The vault sees one deposit from one address — the batcher. Observers see who participated, but not how much anyone contributed. [Confidentiality](/protocol/confidential-vault/concepts/confidentiality.md) covers what this guarantees and where it degrades.

## One direction per batcher

A batcher moves value in exactly one direction: the deposit batcher converts `cUSDC → cShare`, the redeem batcher converts `cShare → cUSDC`. Both inherit the same abstract `VaultBatcherConfidential` and expose the same lifecycle — join, dispatch, finalize, claim — described in [Batch Lifecycle](/protocol/confidential-vault/concepts/batch-lifecycle.md).

The two directions carry different settlement policy. Deposits enforce a slippage bound against the vault's share pricing. Redemptions have slippage protection hardcoded off, so users can always exit, including during a vault drawdown.

## Token wrappers

The `ERC7984ERC20Wrapper` converts between a public token and its confidential form at a constant scaling factor, with no fee and no spread. Confidential tokens use at most 6 decimals, so a 6-decimal underlying like USDC wraps 1:1.

The two conversion directions behave differently:

* **Wrap is synchronous and public.** `wrap(to, amount)` transfers public tokens in and mints encrypted units in the same transaction. The amount is visible on-chain.
* **Unwrap is asynchronous.** `unwrap` burns the encrypted amount and marks it for public decryption. A second call, `finalizeUnwrap`, releases the public tokens once the Zama Protocol has produced the cleartext and its proof.

The batcher uses this unwrap mechanism to reveal a batch's aggregate — and only the aggregate.

## Next steps

* [Batch Lifecycle](/protocol/confidential-vault/concepts/batch-lifecycle.md) — states, transitions, and what users can do in each.
* [Multi-Vault Router](/protocol/confidential-vault/concepts/multi-vault-router.md) — joining many batchers in one transaction.
* [Confidentiality](/protocol/confidential-vault/concepts/confidentiality.md) — what an observer sees, and the known limits.
* [Trust Model](/protocol/confidential-vault/concepts/trust-model.md) — roles, powers, and self-serve recovery.
* [Contract Addresses](/protocol/confidential-vault/reference/addresses.md) — deployed contracts per network.


---

# 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/architecture.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.