Guard system

How Chamber constrains what a vault can do at the contract level

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:

Manager (or trader) submits a transaction via the vault's executeTransaction() entrypoint.
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".)
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.
If the guard approves (returns a non-zero transaction type), the call executes. If not, revert.
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.

For integrators

If you're building on Chamber (using the SDK, the MCP server, 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 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.