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.
See also
Audits — the Guard System code has been reviewed repeatedly
Risk model — where Guard System sits in the overall risk picture
Supported assets — the public face of the asset and protocol allowlists
Build: Guard system — integrator-facing details
Last updated