> For the complete documentation index, see [llms.txt](https://docs.chamberfi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chamberfi.com/security/guard-system.md).

# Guard system

The Guard System is the contract-level layer that decides which actions a manager or trader is allowed to take with vault funds. Every swap, deposit, borrow, or stake a vault submits is routed through it first. Calls that don't match a whitelisted protocol and a whitelisted action are **rejected by the contract**, not filtered in the UI.

This is the mechanism behind Chamber's positioning: *the goal is not to trust the manager more; the goal is to make the vault safer by design*. The same logic applies to AI managers and automated strategies. They use the same surface, and the same guards apply.

## How it works

A vault's call path for any external action looks like this:

1. Manager (or trader) submits a transaction via the vault's `executeTransaction()` entrypoint.
2. The vault asks a central registry: **is this destination contract whitelisted?** If not, revert. (Internally this is the contract guard lookup; the revert code is `"dh23"`.)
3. If whitelisted, the vault asks the matching **contract guard**: is this specific call permitted? The guard decodes the calldata and checks the function being called, the target, the amounts, and the vault's state.
4. If the guard approves (returns a non-zero transaction type), the call executes. If not, revert.
5. For assets, a separate **asset guard** layer governs how the vault holds, prices, and withdraws each supported asset type.

Both layers are enforced by the contracts themselves. There is no off-chain step that a manager can skip by sending a transaction directly.

## Two guard types

**Contract guards** govern *what protocols and what actions*. Each integrated protocol ships with its own contract guard that decodes calls and enforces protocol-specific rules.

**Asset guards** govern *what assets a vault can hold, price, and withdraw*. Each asset type has an asset guard that knows how to compute its balance, its USD value, and how to unwind it during a withdrawal.

The two layers interact: adding a new asset to a vault requires a matching asset guard, and executing a swap requires both the target protocol (contract guard) and the resulting asset (asset guard) to be whitelisted.

## What the Guard System prevents

* **Calls to non-whitelisted protocols.** A manager cannot swap on an unaudited DEX. The revert is at the contract entrypoint.
* **Actions outside the per-protocol rules.** Even for a whitelisted protocol, only the specific function selectors the guard approves can be called.
* **Holding unsupported assets.** A manager can only add assets that are on Chamber's protocol-wide allowlist (governance-controlled, with registered price feeds). Random tokens can't be added to a vault.
* **Misconfigured withdrawals.** Asset guards enforce that a complex position (LP, perp, lending position) is correctly unwound or transferred during withdrawal, rather than simply transferred as a useless token.

## What the Guard System does NOT prevent

Being explicit about the boundary matters:

* **Bad manager decisions within the rules.** A manager can still swap a whitelisted asset for another whitelisted asset at a bad price. Guards shape the action space; they don't grade decisions inside it.
* **Market losses.** A vault holding whitelisted assets can still lose value when the market moves. That's the product, not a bug.
* **Protocol-level exploits in integrated protocols.** If Aave is exploited, a Chamber vault holding aTokens on Aave is affected. Guards constrain Chamber's interaction surface; they can't insure the protocols Chamber interacts with.
* **Fee changes or privacy toggles.** These are manager-settable and sit on a separate permission layer with their own rules (e.g. 14-day announcement for fee increases). The Guard System governs the trading/asset surface, not the fee-admin surface.

## Manager vs. trader permissions

At the Guard System layer, **manager and trader are treated identically**. Both can call `executeTransaction()`, and the same guards apply to both. The difference between them is enforced one layer above, in the vault's per-role permissions:

* Only the manager can set or rotate the trader address.
* Only the manager can change fee settings.
* The trader has two separate toggles: "can change vault assets" (ON by default) and "can toggle vault privacy" (OFF by default).

Once a transaction reaches the guard, the only question is *is this a permitted call on a whitelisted protocol*? The guard doesn't re-check who sent it.

For the full manager/trader breakdown, see [Manage: trader delegation](/manage/trader-delegation.md).

## For integrators

If you're building on Chamber (using the [SDK](/build/sdk.md), the [MCP server](/build/mcp-server.md), or calling contracts directly), every trade you compose will be subject to the same Guard System. Your code must produce calls that would pass a manager's direct submission, or they'll revert at the vault's entrypoint.

The [Build: Guard system](/build/guard-system.md) page covers this from the integrator's side: which guards exist, how to check whether a protocol or asset is supported on a given chain, and how to surface the "action rejected by guard" error back to a user.

## See also

* [Audits](/security/audits.md): the Guard System code has been reviewed repeatedly
* [Risk model](/security/risk-model.md): where Guard System sits in the overall risk picture
* [Supported assets](/concepts/supported-assets.md): the public face of the asset and protocol allowlists
* [Build: Guard system](/build/guard-system.md): integrator-facing details