Overview

How Chamber keeps depositor funds safe — architecture, audits, and track record

The short version: Chamber's core contracts have been live on Ethereum mainnet since October 2020 with no loss of depositor funds. That track record is the product of three things working together — a constraint-first architecture, ongoing audits, and a live bug bounty.

Architecture — the Guard System

Every trade a manager or trader submits is checked against a set of guards before it hits the underlying protocol. Guards allowlist which contracts the vault can interact with, which assets the vault can hold, and which specific actions (swap, deposit, borrow, stake) are allowed. Transactions outside those rules are rejected at the contract level — not filtered in a UI, not flagged by a monitoring system, rejected.

This architecture has been in use since 2020 and iterated on continuously. The goal isn't to trust the manager more. It's to make the vault safer by design.

See Guard system for the full mechanic.

Audits

Core contracts and each major integration (Aave, Pendle, GMX, Ethena, Hyperliquid, and others) have been audited since 2020 by Obsidian, Sherlock, Santipu, iosiro, CertiK, and Trust Security. Auditing is ongoing: new integrations and major upgrades are audited before they ship.

See Audits for the full timeline.

Bug bounty

Chamber runs a live bug bounty through Immunefi with payouts up to $50,000 for critical-level vulnerabilities. The program covers core contracts and active integrations.

See Bug bounty.

Risk model

Security controls don't reduce every risk. Market risk, strategy risk, and the risk of a manager making bad trades inside the vault's rules are not something contract-level guards can prevent — and Chamber doesn't pretend to.

See Risk model for the categories Chamber actively reduces vs. those that remain with the depositor, and Deposit: risks for the depositor-facing view.

Incident history

No loss of depositor funds since launch in October 2020.

See Incident history.