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

# Trust Model

Who can do what — permissionless operations, owner powers, and self-serve recovery.

Every lifecycle step that moves a batch forward is permissionless, the owner's powers are narrow and bounded, and a user can always recover what they are owed with their own transactions. This page enumerates each role and its exact reach.

## Self-serve recovery

A user can always eventually recover exactly what they are owed, using only `quit` and `claim`:

* Before dispatch, or after a cancellation: `quit(batchId)` returns the exact original deposit.
* After finalization: `claim(batchId, account)` delivers the proceeds at the frozen rate. Claims never expire.

An operator service dispatches batches, submits decryption callbacks, and delivers claims today. If it stopped, anyone could run each step, including the users themselves.

## Permissionless operations

Anyone — a user, a competing keeper, an app's backend — can call:

| Function                                           | Effect                                                  | Gate                                       |
| -------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------ |
| `dispatchBatch()`                                  | Closes the pending batch, requests aggregate decryption | Batch age ≥ its pinned minimum; not paused |
| `dispatchBatchCallback(batchId, cleartext, proof)` | Finalizes or cancels a dispatched batch                 | Valid KMS proof for the batch's unwrap     |
| `claim(batchId, account)`                          | Delivers a participant's proceeds — always to `account` | Batch finalized                            |
| `quit(batchId)`                                    | Refunds the caller's own deposit                        | Batch pending or canceled                  |

Stuck-batch recovery is therefore permissionless too: anyone can drive a dispatched batch to finalization when the vault cooperates, or to cancellation after the deadline when it does not.

## Owner powers

Each batcher is `Ownable` with a single owner. The owner can do four things, and only these:

| Power                  | Bound                                                         |
| ---------------------- | ------------------------------------------------------------- |
| Set minimum batch age  | At most 7 days (on-chain cap)                                 |
| Set callback deadline  | At most 30 days (on-chain cap)                                |
| Set slippage tolerance | At most 10000 bps; hardcoded to 0 (off) on the redeem batcher |
| Pause / unpause        | Halts joins and dispatch only                                 |

The owner cannot:

* move or freeze user funds;
* change the policy of a batch that is already open or in flight — all three parameters are pinned into a batch at creation;
* censor or force a batch outcome — dispatch, callback, and claim are permissionless;
* decrypt anyone's amounts — FHE permissions grant computation, never decryption;
* upgrade the contract.

Pause stops new joins and new dispatches; `quit` and `claim` stay open while paused. A batch whose callback arrives while the batcher is paused cancels without touching the vault, and its participants quit for a full refund.

## The router has no owner

`VaultBatcherConfidentialRouter` has no owner, no pause, and no parameters. Its one dependency is the Zama token wrapper registry, which lists the confidential tokens allowed to use the push entry point. Zama protocol governance controls that registry. A wrapper the registry drops loses the push path. Direct joins, `quit`, and `claim` on the batchers keep working.

The router holds no funds between transactions and moves only the caller's own tokens, only to the batchers the caller named. A hostile batcher or token named in a leg can cost the caller who named it, and nobody else.

## No upgrades

FHE access-control grants are permanent: once a user's handle is allowed to a contract, that grant cannot be revoked. That stays safe only if the contract's code can never change, so the batchers ship as plain deployments with no proxy and no upgrade path. The entire post-deploy change surface is the three bounded parameters above, and each applies only to batches not yet opened.

## External trust assumptions

Three external systems sit inside the trust boundary.

**The Zama Protocol.** Trusted to compute correctly on encrypted values and to decrypt only what the protocol marks decryptable. Every decryption the contracts consume carries a KMS proof verified on-chain. A dispatched batch can only finalize — or deadline-cancel — after the Zama Protocol produces the aggregate cleartext; pending batches remain quittable throughout any delay in the Zama Protocol.

**The ERC-4626 vault.** The batcher forwards value into a third-party vault, so vault risk is fully inherited. A deposit that breaches the batch's slippage bound reverts, and a vault failure inside the callback deadline leaves the batch retryable, then cancelable — participants recover via `quit`.

**The confidential token wrappers.** cUSDC and cShare are Zama protocol registry contracts, shared infrastructure outside this protocol's deployment. The registry's governance can pause a wrapper.

## Next steps

* [Batch Lifecycle](/protocol/confidential-vault/concepts/batch-lifecycle.md) — the states behind `quit` and `claim`.
* [Confidentiality](/protocol/confidential-vault/concepts/confidentiality.md) — what the Zama Protocol is trusted with.
* [Contract Addresses](/protocol/confidential-vault/reference/addresses.md) — current owners and policy values 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/trust-model.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.