# 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 --- # Agent Instructions: 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: ``` GET https://docs.chamberfi.com/security/guard-system.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.