# Chamber Documentation One vault for stocks, commodities, and crypto, managed onchain, with depositor funds protected by smart-contract guardrails. Stocks, commodities, and crypto, managed in one onchain vault. Chamber is a vault platform where managers trade tokenized stocks, commodities, and crypto in a single strategy, while depositor funds stay protected by onchain guardrails. See the [table of contents](https://github.com/dhedge/chamber-docs/blob/main/SUMMARY.md) for the full documentation. ## Start here * **New to Chamber?** → [What is Chamber](/introduction/what-is-chamber) * **Coming from dHEDGE?** → [dHEDGE → Chamber](/introduction/dhedge-to-chamber) * **Running a vault?** → [Manage](/manage/overview) * **Depositing?** → [Deposit](/deposit/overview) * **Building on Chamber?** → [Build](/build/overview) # What is Chamber Chamber is an onchain platform for vault-based asset management. A single vault can hold tokenized stocks, commodities, and crypto. Depositors keep custody; managers trade within rules the Guard Syste Chamber is an onchain platform where managers run trading strategies and depositors provide capital, with both sides bounded by smart-contract rules that no one can override. A single vault can hold tokenized stocks, commodities, and crypto side by side, so a manager can run a cross-asset strategy in one place instead of spreading it across separate platforms. The vault holds the funds. The manager trades the vault. The [Guard System](/security/guard-system) enforces what the manager can and cannot do. Nobody takes custody of anyone else's money. ## How it works Three parties, one smart contract. * **Depositors** deposit assets into the vault contract. They receive vault shares, an ERC-20 receipt representing their proportional claim. They can withdraw any time after the [post-deposit lockup](/deposit/lockup-withdrawals) (up to 24 hours, weighted across deposits) clears. * **Managers** design the strategy, set fees, and trade the vault's assets. They never take custody and are bounded by the Guard System's rules: only the vault's [enabled assets](/manage/permissions-access), only approved protocols, fee caps respected. * **The Guard System** checks every trade onchain. Calls that would violate the rules revert before they can touch vault funds. This is the shape of all onchain asset management worth doing: custody stays with the depositor, strategy decisions stay with the manager, and the rules are enforced by code rather than by trusting a counterparty. ## Two ways to run a vault Managers run a vault manually, programmatically, or a mix of both: * **Manual.** Trade directly in the [Chamber app](/manage/trading) with TradingView charts and per-category protocol tabs. * **Automated.** Run a bot via the [SDK](/build/sdk) or direct contract calls. Rebalance on a schedule or a signal. Many managers use an LLM to help write and maintain that automation. Either way, the Guard System applies the same constraints: a bot doesn't get looser rules than a human, and a human doesn't get looser rules than a bot. ## Who Chamber is for * **Vault managers:** human traders, strategy developers, and anyone running a bot or agent who wants onchain infrastructure without building their own vault contracts. * **Depositors:** individuals looking for managed onchain strategies with non-custodial guarantees. * **Developers:** teams building on top of Chamber via the SDK, subgraph, Data API, or MCP server. ## What Chamber is not * **Not custodial.** Chamber never holds your funds. Deposits live in the vault contract; the contract enforces who can do what. * **Not insured by default.** Audits, the Guard System, and bug bounties reduce risk, but every deposit carries market, smart-contract, and manager risk. Optional cover may be available via third-party providers (see [Insurance](/deposit/insurance)); otherwise see [Risks](/deposit/risks). ## Where to go next * **Running a vault?** Start at [Manage → Overview](/manage/overview) and the [Manager playbook](/manage/manager-playbook). * **Building an integration?** Start at [Build → Overview](/build/overview). * **Understanding the mechanics?** Start at [Concepts → Vaults as guardrails](/concepts/vaults-as-guardrails) and [Guard System](/security/guard-system). * **Moving from dHEDGE?** [dHEDGE → Chamber](/introduction/dhedge-to-chamber) covers what stays and what's new. * **Depositing?** Start at [Deposit → Overview](/deposit/overview) and [Find a vault](/deposit/find-a-vault). # dHEDGE → Chamber Chamber is the rebrand of dHEDGE. The contracts, vaults, and token continuity carry through. Positioning is the main thing that's changed. Chamber is the next chapter of **dHEDGE**. Same team, same core contracts, same DAO. The rebrand reflects a sharper focus on what the protocol has become good at: bounded, programmable vaults that let a manager trade stocks, commodities, and crypto in a single onchain strategy. If you're a current dHEDGE user, manager or depositor, nothing urgent changes. Your vault, your shares, your fees, and your DHT balance all carry through. ## What stays the same * **Existing vaults.** Every live dHEDGE vault continues to operate under Chamber. Same address, same holdings, same manager. * **Vault shares.** Shares (vault receipt tokens) are unchanged. No migration required. * **DHT token.** The DHT token is unchanged: same contract, same supply. See [DHT (legacy)](/governance-and-token/dht-legacy) for its current role. * **The DAO.** Same DAO, same proposals. Voting is weighted by vDHT on Snapshot (see [Governance](/governance-and-token/overview)). DHT staking rewards have ended, though vDHT still carries voting weight; see [Legacy staking](/governance-and-token/dht-staking) for context. * **Treasury.** Same onchain treasury, ongoing buybacks. See [Treasury](/treasury-and-protocol-economics/overview). * **Toros Finance.** Toros remains the ecosystem's leveraged-token brand and continues to operate as before (see [Ecosystem → Toros Finance](/ecosystem/toros-finance)). * **mStable and Flat Money.** Both remain live under the Chamber ecosystem umbrella. * **Guard System.** Same contract-level enforcement as dHEDGE's v2 vaults. * **All audits, fee limits, and onchain mechanics.** In short: if it's onchain, it's unchanged. ## What's changed Mostly framing, not mechanics. * **The name.** dHEDGE → Chamber. Domains, branding, and marketing pivot to Chamber. * **Hero positioning.** Chamber's public message leads with **one vault across stocks, commodities, and crypto**: tokenized equities and RWAs alongside spot crypto, in a single bounded strategy. * **App URL.** The app is moving to [**chamberfi.com**](https://chamberfi.com/). The existing `dhedge.org` URL will redirect to the new domain. ## What depositors need to do **Nothing.** Your existing position on dHEDGE is an existing position on Chamber. Log in to the new app, see the same vaults, same shares, same balance. Withdrawals and deposits work exactly as before. ## What managers need to do **Nothing urgent.** Your existing vault is your existing vault. Fees, assets, traders, and settings all carry through unchanged. A few things worth refreshing: * **Strategy description on your vault page.** If you wrote it under the dHEDGE branding, you may want to update any mentions to Chamber. * **Referral links.** Links generated under dHEDGE continue to work. If you distribute them widely, the underlying URL will update to a Chamber domain. Existing links redirect. See the [Manager playbook](/manage/manager-playbook) for post-rebrand manager guidance. ## What builders need to do **Very little.** Contract addresses are unchanged. The [subgraph](/build/subgraph), [SDK](/build/sdk), and [Data API](/build/data-api) continue to work. If you're deploying fresh integrations, use the Chamber-branded entry points where they exist. They point at the same underlying infrastructure. ## Why rebrand at all Two reasons, both practical: 1. **The product has evolved.** dHEDGE started as a general-purpose onchain asset management protocol. Chamber's current strength, one bounded vault that spans tokenized stocks, commodities, and crypto, is a specific, more useful positioning. 2. **Asset breadth is the wedge.** With Ondo's tokenized equities and RWAs live alongside crypto and commodities, a Chamber vault can run a cross-asset strategy that used to require several venues. Leading with that is honest to what Chamber now is. None of this is a new protocol. It's the same vault infrastructure, given a name that matches what it does. ## Related * [What is Chamber](/introduction/what-is-chamber) * [Governance](/governance-and-token/overview) * [Treasury](/treasury-and-protocol-economics/overview) * [Ecosystem](/ecosystem/overview) # Overview Run a vault on Chamber, manually in the app, or automated via the SDK, or a mix. Chamber gives managers the infrastructure to run an onchain vault. Managers never take custody of depositor funds. The vault holds them, and the [Guard System](/security/guard-system) enforces what the manager can and cannot do with them. Anyone can create a vault. ## Two ways to run a vault Managers run a vault manually, programmatically, or a mix of both: * **Manual.** Trade directly in the web app. Built-in [TradingView charts](/manage/trading), full UI control. * **Automated.** Run a bot via the [SDK](/build/sdk) or direct contract calls. Rebalance on a schedule or signal. Many managers use an LLM to help write that automation. A single vault can use both. The Guard System applies the same constraints either way. ## What's in this section * [Create a vault](/manage/create-a-vault): chain, denomination, fees, enabled assets. * [Chain capabilities matrix](/manage/chain-capabilities): what each chain supports. * [Denomination asset](/manage/denomination-asset): the reference currency for NAV. * [Permissions & access](/manage/permissions-access): public vs. private, enabled assets. * [Trader delegation](/manage/trader-delegation): delegate trade execution without fund access. * [Trading](/manage/trading): UI or API. * [Fees & performance](/manage/fees-performance): entry, exit, performance, management. * [Manager programs](/manage/manager-programs): referrals and programs for active managers. * [Manager playbook](/manage/manager-playbook): practical guidance for running a vault well. # Create a vault Step-by-step walkthrough of the Chamber vault creation flow: chain, fees, assets, and publish. Anyone can create a vault on Chamber. The flow takes a few minutes: pick a chain, set your fees, choose which assets the vault can hold, and publish. You'll be the manager; the vault holds depositor funds in its own contract, and the [Guard System](/security/guard-system) enforces what you can and cannot do with them. ## Before you start You need: * A connected wallet on the chain you want to deploy on. * A small amount of the chain's native token for the deployment transaction (e.g. ETH on Arbitrum, POL on Polygon, HYPE on HyperEVM). * Decisions on: vault name and symbol, fee structure, and which assets you want to trade. You do **not** need to decide your full strategy before creating the vault. Fees, enabled assets, and permissions can all be changed later. Fee **increases** have a [14-day announcement period](/manage/fees-performance); fee decreases and enabled-asset changes take effect immediately. ## 1. Pick a chain From the [Chamber app](https://chamberfi.com/), click **Manage** in the top nav. This opens **Start Your Manager Journey**, where you'll see a card for each supported chain showing what that chain supports: Spot, Lending, Leverage, LP, or Perps. See [Chain capabilities](/manage/chain-capabilities) for the full matrix. ![Start Your Manager Journey: chain selection](/files/Wcb8FzD76cJqSAaxRcw6) Picking a chain opens a confirmation modal to start the vault creation flow. The chain you pick here is fixed for the life of the vault. ## 2. Vault info ![Step 1: Vault Info](/files/gd2tDzGgFp4mtDWM69Gp) Fill in the basics. * **Vault Name.** The public-facing name depositors see. **Permanent:** stored onchain and cannot be changed later. * **Vault Symbol.** The ticker for your vault token (the receipt token depositors receive). Manager-chosen. Keep it short and recognizable. **Permanent:** also stored onchain and cannot be changed later. * **Manager Name.** Your public manager name. Used across the app and analytics. * **Manager Address.** Defaults to your connected wallet. This is the address that can change vault settings. Treat it like a treasury key. * **Privacy.** **Public** = anyone can deposit. **Private** = only whitelisted addresses can deposit. See [Permissions & access](/manage/permissions-access). * **Performance Fee.** 0–50%. Charged on profits above high-water mark. * **Management Fee.** 0–3% per year. Charged continuously on assets under management. * **Entry Fee.** 0–2%. Charged on deposits. * **Exit Fee.** 0–2%. Charged on withdrawals. Chamber takes 10% of your manager fees as a protocol fee. The displayed rate is what depositors pay; you receive 90% of it. See [Fees & performance](/manage/fees-performance) for worked examples and the fee-change announcement rules. ## 3. Assets ![Step 2: Assets](/files/wpq91GfudsKzcJm95ll2) Pick which assets your vault can hold and trade. Assets are grouped by category: * **Crypto:** spot tokens (WETH, WBTC, etc.). * **Stablecoins:** USDC, USDT, DAI, and similar. * **Lending:** aToken / cToken-style positions on Aave, Compound, and equivalents. * **Leverage:** [Toros](/ecosystem/toros-finance) leveraged tokens (e.g. BTCBULL2X, SOLBULL3X). * **Liquidity Provision:** LP positions on supported DEXes. * **Yield:** yield-bearing positions (Pendle, staked assets). * **System:** internal tokens used by Chamber integrations. Some tokens are only available as wrapped variants (WETH, WBTC). Native ETH and native BTC aren't held directly. A vault can enable a **maximum of 12 assets**. Default-enabled assets depend on the chain (on Arbitrum, USDC, WBTC, and WETH are pre-selected). On HyperEVM, perps also need the **Hyperliquid Perps Account** asset enabled, listed under System. Enabling it here doesn't by itself let the vault trade perps. See [Perps on HyperEVM](/manage/trading#perps-on-hyperevm). You can change the set of enabled assets later from vault settings without an announcement period. Enable new assets at any time (up to the 12-asset cap), or disable assets you no longer want, **as long as the vault doesn't currently hold any of that asset**. Close the position first, then disable. See [Permissions & access](/manage/permissions-access) for the full mechanic. Choose a tight set to start. Smaller sets are easier for depositors to reason about, and **each enabled asset adds gas cost to every deposit, withdrawal, and NAV calculation**, so keep it to the assets you actually plan to trade. ## 4. Preview and create ![Step 3: Preview](/files/SSKX93fjZaIDltzfxmJY) Review everything. The preview also surfaces: > *Deposit is locked for 24 hours after deposit.* This is a flash-loan protection measure that applies to **every** depositor, including you. Only the first 24 hours after each individual deposit are locked. Top-ups extend the remaining lockup proportionally rather than resetting it. See [Deposit → Lockup & withdrawals](/deposit/lockup-withdrawals). Click **Create Vault** and confirm the transaction in your wallet. Once it's mined, your vault is live and accepts deposits immediately. Your vault gets its own **contract address**, separate from your manager wallet address. The two are not interchangeable: the vault address is what holds depositor funds and what you quote when you need support with a specific vault. You'll find it on the vault page in the app. ## After creation Your vault is running, but it's empty and untraded. Typical next steps: * [**Seed it**](/deposit/deposit)**.** Managers usually deposit first to bootstrap. * [**Delegate a trader wallet**](/manage/trader-delegation) if you plan to trade via an API bot or automated strategy. * [**Trade manually**](/manage/trading) from the app UI. ## What's permanent vs. changeable Most settings can be changed after creation. A few cannot. **Permanent, set once at creation:** * **Chain.** A vault can't be moved from (say) Arbitrum to Base. Create a new vault on the target chain instead. * **Vault name and symbol.** Both are stored onchain and cannot be changed. * **Vault contract address.** Fixed at deployment. * **Denomination asset.** Always USD for every Chamber vault. See [Denomination asset](/manage/denomination-asset). **Changeable after creation:** fees (with a [14-day announcement](/manage/fees-performance) on increases), [enabled assets](/manage/permissions-access), [privacy](/manage/permissions-access), the [trader](/manage/trader-delegation), [deposit limits](/manage/permissions-access#deposit-limits), and the manager address (see below). ## Changing the manager address The manager address, the wallet that can change vault settings, claim fees, and represent the vault on governance, can be rotated from vault settings. **This is non-recoverable if you paste the wrong address.** There's no undo and no support ticket that fixes it. Whoever controls the destination address controls the vault. Double-check the address, ideally on a second device. Use cases: moving from a hot wallet to a hardware wallet, rotating after a suspected compromise, handing a vault to a new manager. # Chain capabilities matrix What each supported chain supports: spot, lending, leverage, LP, perps. The chain you pick when you [create a vault](/manage/create-a-vault) determines what the vault can do. Not every strategy is available on every chain. It depends on which protocols Chamber has integrated and which the [Guard System](/security/guard-system) has approved there. The chain is fixed for the life of the vault. If you need a capability that isn't on your chain, you'll need to create a second vault on a chain that supports it. ## Matrix | Chain | Spot | Lending | Leverage | LP | Perps | Equities & RWA | | -------- | :--: | :-----: | :------: | :-: | :---: | :------------: | | Ethereum | ✓ | ✓ | ✓ | | | ✓ | | Polygon | ✓ | ✓ | ✓ | ✓ | | | | Optimism | ✓ | ✓ | ✓ | ✓ | | | | Arbitrum | ✓ | ✓ | ✓ | ✓ | | | | Base | ✓ | ✓ | | ✓ | | | | Plasma | ✓ | ✓ | ✓ | ✓ | | | | HyperEVM | ✓ | | | | ✓ | | HyperEVM is the only chain with perps today, and it's in early access (see below). Ethereum is the only chain with tokenized equities and RWAs. ## What each capability means * **Spot.** Swap between the vault's enabled tokens via supported DEX aggregators (Odos, 1inch, KyberSwap, CoW Swap, Toros, Pendle). * **Lending.** Supply assets to lending markets (Aave, Compound-style) and hold the interest-bearing receipt token. * **Leverage.** Open leveraged spot positions through integrated lending loops. * **LP.** Provide liquidity on supported DEXes and hold the LP position as a vault asset. * **Perps.** Perpetual futures. Currently HyperEVM only, via Hyperliquid. * **Equities & RWA.** Hold tokenized US stocks, ETFs, and commodities issued by Ondo Stocks. Ethereum only. Subject to eligibility and regional access rules. See [Supported assets](/concepts/supported-assets). ## HyperEVM and Hyperliquid perps Perps on HyperEVM are gated. Chamber runs a **Hyperliquid early-access program**: only approved managers can deploy perps vaults today. It's not a permissionless feature yet. If you want to run a perps vault and aren't in the program, reach out via **Support Chat** in the [Chamber app](https://chamberfi.com/), or see the [manager programs](/manage/manager-programs) page. ## Picking a chain Pick the chain where your depositors already are and where the protocols you want to use are live. # Denomination asset Every Chamber vault is denominated in USD. Here's what that means for managers and depositors. **Every Chamber vault is denominated in USD.** That's fixed. It's not a setting you choose when you create a vault, and it's the same on every chain. "Denomination asset" is the technical term for the vault's unit of account: the currency the vault uses to keep score. For Chamber vaults, that's always USD. ## What's measured in USD Everything that expresses vault value: * **NAV** (net asset value): total value of what the vault holds. * **Vault token price**: what one unit of the vault is worth. * **Deposits and withdrawals**: sized in USD terms at execution time. * **Performance**: returns are reported in USD. * **Fees**: management, performance, entry, and exit fees all accrue in USD terms. ## The vault doesn't have to hold stablecoins USD is the *unit*, not a holding requirement. A vault can be 100% WETH and still report its value in USD. The price just moves with ETH. The denomination asset controls **how** value is reported, not **what** the vault holds. This matters for reading performance: * A **stablecoin-yield vault** aims for steady USD returns: flat-ish line going up. * A **directional vault** (e.g. ETH-heavy) will swing with its underlying. A bad week for ETH is a bad week for the vault in USD terms, even if the manager didn't trade. Depositors should read performance with the vault's strategy in mind, not just the number. The performance chart in the app lets you overlay ETH and BTC as benchmarks, useful for checking whether a directional vault is actually outperforming the asset it's exposed to, rather than just riding the market. ## How pricing works Vault NAV is computed continuously from onchain oracle prices of everything the vault holds, converted to USD. The vault token price you see in the app is live NAV divided by total supply. Deposits and withdrawals use the same pricing. See [Oracles](/concepts/oracles) for which oracle providers Chamber uses (Chainlink, Pyth, and TWAP) and how price feeds are selected per asset. ## Why USD and not a specific stablecoin Chamber accounts in USD rather than pegging to a specific stablecoin (USDC, USDT, DAI) so the vault isn't tied to any one issuer's peg or redemption path. In practice depositors interact using the stablecoins on that chain, but the accounting layer sits above them. ## Related * [Create a vault](/manage/create-a-vault): the creation flow. * [Fees & performance](/manage/fees-performance): how fees accrue against USD NAV. * [Vault token & shares](/concepts/vault-tokens): how the receipt token works. # Permissions & access Public vs. private vaults, depositor whitelists, enabled assets, and deposit limits. Chamber vaults have two separate access controls: * **Who can deposit**: public (anyone) or private (whitelisted addresses). * **What the vault can hold**: the set of enabled assets, capped at 12. Both are set by the manager and can be changed later. Trader access (who can execute trades on the vault's behalf) is covered separately in [Trader delegation](/manage/trader-delegation). ## Public vs. private vaults Every vault has a **privacy** setting. * **Public.** Anyone with a wallet on the vault's chain can deposit. This is the default for managers who want open participation. * **Private.** Only addresses the manager has added to the depositor whitelist can deposit. A vault can switch between public and private at any time. Flipping a public vault to private doesn't remove existing depositors. They keep their holdings and can withdraw normally. It just stops new unapproved deposits. ## Managing the depositor whitelist (private vaults) When a vault is private, the manager maintains a list of approved depositor addresses. * **Add.** Paste an address into the whitelist in vault settings. That address can now deposit. * **Remove.** Remove an address from the whitelist. They can no longer deposit. **Removing a whitelisted address does not force them out.** If the address already has a deposit, those holdings stay in the vault and the depositor can still withdraw normally. They just can't add more funds. This is deliberate: the manager controls who can *enter*, but can't seize or lock existing positions. ### When private vaults make sense * Friends-and-family vaults where you want a known depositor set. * Strategy vaults for a specific partner or allocator. * **Paid trading group**: managers running a subscription service or paid cohort can gate vault access to subscribers by whitelisting only their addresses. ## Enabled assets The set of enabled assets controls what the vault can hold and trade. You pick the initial set during [vault creation](/manage/create-a-vault), up to **12 assets enabled at once**, chosen from the chain's supported categories (crypto, stablecoins, lending, leverage, LP, yield). You can change the set later in vault settings: * **Enable** a new asset at any time, up to the 12-asset cap. * **Disable** an asset, **only if the vault doesn't currently hold any of it.** If there's a position in that asset, close it first, then disable. The 12-asset cap keeps vaults legible for depositors and bounds the surface area the [Guard System](/security/guard-system) has to enforce. Each enabled asset also adds gas cost to every deposit, withdrawal, and NAV calculation, so keep the set to assets you actually plan to trade. Changes to enabled assets take effect immediately. There's no announcement period (unlike fee changes, which have a [14-day notice window](/manage/fees-performance)). ## Deposit limits Two optional limits on deposit size, both set from vault settings. ### Minimum deposit The smallest USD amount a depositor can add in a single deposit. * Default: **$0** (no minimum). * Set it to reduce dust positions, control depositor count, or signal the vault is for larger allocations. ### Maximum supply cap Upper limit on total vault size. Once reached, new deposits are rejected until someone withdraws. * Default: **no limit**. * Expressed in the vault's [denomination asset](/manage/denomination-asset) (USD). * Use it to cap strategy capacity: some strategies perform worse at larger sizes. # Trader delegation Delegate a single trader address to execute trades on the vault's behalf, without giving up manager control. The **trader** is a separate address the manager authorizes to execute trades on the vault's behalf. It's how managers run a vault without signing every transaction from the manager wallet, useful for API bots and automated strategies. A trader can move the vault's assets within the rules. A trader **cannot** change fees or rotate the manager address. Those stay with the manager. Neither the trader nor the manager can withdraw depositor funds; the vault contract doesn't allow that. Everything the trader does still passes through the [Guard System](/security/guard-system): same enabled assets, same protocol allowlist, same constraints as the manager. ## Set Trader Open your vault in the [Chamber app](https://chamberfi.com/) and go to vault settings → **Set Trader**. You configure three things: * **Trader address.** One address. Paste the wallet you want to delegate to. Replacing it overwrites the previous trader. There's only ever one active trader per vault. * **Trader can change vault assets.** **On by default.** When on, the trader can both execute trades **and edit the vault's enabled assets**: adding new supported assets or removing unused ones, within the same rules the manager follows (e.g. can't remove an asset the vault currently holds). This is broader than "swapping between held assets": a trader with this toggle on can enable an asset you haven't explicitly approved and route funds into it. Turn this off if you want the trader restricted to trading within the assets *you've* enabled. * **Trader can toggle vault privacy.** **Off by default.** Lets the trader flip the vault between public and private. Most managers leave this off; only enable it if the trader is a trusted automation that needs to gate deposits on its own schedule. Confirm the transaction from your manager wallet to apply. Because the default is on, most trader setups today allow the trader to change enabled assets. If that's not what you want, turn it off explicitly before authorizing the trader. ## What the trader can and cannot do | Action | Manager | Trader | | ----------------------------------------------------- | ------- | ------------------------------------ | | Execute trades on enabled assets | Yes | Yes | | Use approved protocols (swaps, LP, lending, leverage) | Yes | Yes | | Edit the vault's enabled assets (add/remove) | Yes | Yes (if "change vault assets" is on) | | Flip vault privacy (public ↔ private) | Yes | Only if toggle is on | | Set vault maximum supply cap | Yes | Yes | | Change fees | Yes | No | | Change minimum deposit | Yes | No | | Rotate the manager address | Yes | No | | Access or withdraw depositor funds | No | No | The trader role is scoped to operational work. Anything that changes the vault's rules stays with the manager. ## Creating a trader wallet The trader wallet is just a standard EOA (externally owned account): any wallet you control. Common patterns: * **A fresh wallet you generate yourself** (e.g. via MetaMask, a hardware wallet, or a key generated in a secure environment). This keeps your manager wallet out of the hot path for trading. * **A server-side wallet** for an API bot or custom strategy. Treat the trader key with the same care as any trading key. It can move vault assets, and there's no revocation without rotating it. ## Rotating or revoking the trader To rotate: open **Set Trader**, paste the new address, confirm. The previous trader immediately loses the ability to trade. To revoke entirely: use **Remove Trader** in vault settings. That clears the trader address and disables the trader role until you set a new one. (You can't revoke by pasting `0x0000...0000` into Set Trader. The contract rejects the zero address there. Remove Trader is the correct path.) Rotate if you suspect the trader key is compromised, if you're retiring a bot, or if you're switching automation setups. ## Typical patterns * **Manual-only manager.** Don't set a trader. Sign every trade from the manager wallet. Simplest, slowest. * **Automated bot.** Set a trader wallet the bot controls. Keep privacy toggle off unless the bot genuinely needs it. * **Mixed.** Any of the above, plus the manager still trades manually whenever. The trader doesn't lock the manager out. # Trading Trade your vault from the Chamber app: swaps, liquidity, lending, leverage. TradingView charts your vault token. Managers trade directly from the [Chamber app](https://chamberfi.com/). The trading UI is category-based: pick what kind of position you want to open, pick the protocol, execute. Your vault token's price is charted in TradingView so you can analyze vault performance with the full TradingView toolset. This page covers manual trading. For bots and custom automations, see the [SDK](/build/sdk). ## Opening the trade view From your vault page, click **Manage Vault**. You'll see tabs across the top, one per trade category: * **Swaps:** spot-to-spot token swaps. * **Liquidity:** LP positions on supported DEXes. * **Lending & Borrowing:** supply and borrow on money markets. * **Leverage:** leveraged positions via Toros. * **Custom:** connect to any dApp via WalletConnect (within Guard System limits). * **All:** everything, ungrouped, for quick access. Each tab shows the protocols available **on your vault's chain** for that category. What's listed differs per chain. HyperEVM shows Perps and Spot; Base doesn't have Leverage; etc. See [Chain capabilities](/manage/chain-capabilities) for the full matrix. ## TradingView charts Your vault token's price is charted in the standard TradingView interface: drawing tools, indicators, and timeframes all work as normal. Use it to analyze your vault's own performance over time, not just individual assets. Charts are for analysis only; they don't execute trades. ## Protocols by category The set of supported protocols differs per chain. The **Manage Vault** screen in the app shows the full list for your vault's chain, grouped under the category tabs. That's the source of truth while you're trading. See [Chain capabilities](/manage/chain-capabilities) for a high-level matrix of what each chain supports (Spot, Lending, Leverage, LP, Perps). ## Executing a trade Selecting a protocol opens its native UI embedded directly in the Chamber app. You interact with the real protocol interface to build your transaction (enter sizes, set slippage, confirm), and sign it from the manager wallet (or the delegated [trader wallet](/manage/trader-delegation)). Both sides of any trade must be in your vault's [enabled assets](/manage/permissions-access). If an asset isn't enabled, enable it first. The Guard System checks every call onchain: enabled asset? approved protocol? Calling a function the guard actually allows? If anything fails, the transaction reverts before it can touch vault funds. ## Perps on HyperEVM Perps are set up differently from the other categories, because the order book isn't on HyperEVM. Your vault lives on HyperEVM, and Hyperliquid's perps order book lives on HyperCore. To trade, the vault sends instructions across to HyperCore through a Hyperliquid system contract called CoreWriter, and the Guard System checks those calls like any other integration. Perps run through [HyperEVM Trade](https://www.hyperevm.trade/), Chamber's Hyperliquid interface. Like the other protocol UIs it's embedded in the Chamber app, or you can open the site in its own window and connect your vault to it via [WalletConnect](#custom-trades-via-walletconnect). Three things have to be in place before a perps trade goes through: 1. **Your vault is approved for the integration.** Perps are in early access, so the team enables them per vault. Until that's done, trades fail with "Vault not whitelisted for this integration". See [Chain capabilities](/manage/chain-capabilities) to request access. 2. **"Hyperliquid Perps Account" is one of your enabled assets.** You do this one yourself, and it's the step most managers miss. Enable it like any other asset (see [Enabled assets](/manage/permissions-access#enabled-assets)) and the vault's perps balance is priced into NAV. That asset's address is Hyperliquid's CoreWriter contract, which is why skipping it fails with "CoreWriter not enabled in vault". 3. **The market you want is approved.** Perps markets are approved onchain one at a time. If one you want isn't available, ask via **Support Chat** in the [Chamber app](https://chamberfi.com/). ### Moving capital in and out Enabling the asset doesn't move any money. Your vault's USDC sits in its EVM wallet on HyperEVM, and perps trade against separate balances on HyperCore, so you have to move capital across before you can open a position. The transfer panel in HyperEVM Trade shows four balances for your vault: * **EVM Wallet:** USDC held by the vault on HyperEVM. * **Spot:** your Hyperliquid spot balance. * **Crypto Perp:** margin for crypto perps markets. * **Real World Perp:** margin for real-world asset markets such as equities and commodities. The panel takes a **From** and a **To**, so each move is one action: pick EVM Wallet → Spot to deposit, then Spot → Crypto Perp (or Real World Perp) to fund the account you want to trade against. Reverse the direction to bring capital back, which is what you do when you want to trade spot on HyperEVM again: Crypto Perp → EVM Wallet. The two perp accounts are funded separately. Margin sitting in Crypto Perp doesn't back a Real World Perp position, so if you trade both, you fund both. Within a single account the opposite is true: each perp account is cross-margin, so the whole balance backs every position you hold in it. A loss on one position reduces the margin behind the others, and a liquidation draws on the account as a whole rather than just the position that moved against you. Size positions with that in mind. Only USDC moves across. Tokens the vault holds on HyperEVM stay on HyperEVM, so to put more capital behind a perps position, swap to USDC first, then transfer. The perps account uses one of your 12 enabled assets, so a perps vault has 11 slots left for everything else. Plan for that if you want wide market coverage. ## Custom trades via WalletConnect The **Custom** tab is a secondary way to interact with integrated protocols. Instead of using the embedded protocol UI on the main trade page, you connect your vault directly to the protocol's own site via WalletConnect and complete the trade there. Useful when you want to use a protocol feature that isn't surfaced in the embedded Chamber view. The flow: 1. Open the dApp you want to use in a new tab and click its **Connect Wallet** button, choosing **WalletConnect**. 2. Copy the WalletConnect QR code or connection URI from the dApp. 3. Paste it into the **WalletConnect** field on the Chamber Custom tab. 4. Confirm the connection. The dApp now sees your vault address, not your personal wallet. 5. Trigger transactions via the dApp; they're signed from your manager (or trader) wallet and routed through the Guard System. What you **can't** do via WalletConnect: route around the Guard System. Calls to disallowed contracts or unlisted assets revert onchain. Custom doesn't expand what's allowed. It's just a different entry point into the same protocols. If you want a protocol or asset enabled that isn't supported yet, reach out via **Support Chat** in the [Chamber app](https://chamberfi.com/) and we can look into adding it. ## Deposits, withdrawals, and vault accounting Trading changes what the vault holds, not its NAV (beyond slippage and fees). Depositor accounting is handled separately in USD via the [denomination asset](/manage/denomination-asset). Every swap, LP position, and leveraged token is priced against USD by the oracle layer so depositor shares reflect the vault's true value. ## Not covered here * **Fees you pay as a manager trading:** gas only; Chamber doesn't charge a per-trade fee. Depositor-side fees (entry/exit/perf/mgmt) are in [Fees & performance](/manage/fees-performance). * **Running a bot:** see the [SDK](/build/sdk) or call the contracts directly. # Fees & performance Four fee types: entry, exit, performance, management. How they're calculated, the 14-day announcement period, and Chamber's 10% protocol cut. Chamber vaults support four fee types. Managers pick the mix that suits the strategy. All fees are set at [vault creation](/manage/create-a-vault) and can be changed later, subject to a 14-day announcement period. Chamber takes **10% of manager fees** as a protocol fee. The rate displayed to depositors is the full rate they pay. The manager receives 90% of it, Chamber receives 10%. ## The four fee types ### Entry fee Charged on each deposit by reducing the shares the depositor receives. A depositor adding $10,000 to a vault with a 0.5% entry fee receives vault shares worth $9,950; shares worth the remaining $50 are minted to you and the protocol. Range: 0–2%. ### Exit fee Charged on each withdrawal. Same shape as the entry fee, applied on the way out. Shares are taken as the fee before the remaining shares are redeemed for assets. Range: 0–2%. ### Performance fee Charged on the vault's share price appreciation above its **high-water mark** (HWM). The HWM is vault-level: the highest share price the vault has reached since the last performance fee was minted. It is not tied to any individual depositor's entry price. * Typical range: 0–50%. * When share price grows above the HWM, new shares are minted to the manager and Chamber (90/10) worth the manager's agreed cut of the vault-wide gain. Every existing holder's share count is unchanged; their share of the total supply dilutes by a matching fraction. That's how all depositors collectively pay the fee. * If the vault drops below its HWM and later recovers, no performance fee accrues until the HWM is exceeded. * Performance fees are automatically calculated and minted on every new deposit or withdrawal, and can be triggered manually by the manager. Example (vault level): A vault has a share price of $1.00 at its high-water mark. Total supply is 1,000,000 shares. Share price grows to $1.20 (a 20% gain, vault-wide). With a 20% performance fee, shares worth 20% of the $200,000 NAV gain ($40,000) are minted: split $36,000 to the manager, $4,000 to Chamber. The new HWM becomes the post-mint share price. This is socialized across every holder. A depositor who entered at $0.80 and a depositor who entered at $1.00 both experience the same dilution when the fee mints. ### Management fee Charged continuously on the vault's total share supply, at the annualized rate. Charged regardless of performance. * Range: 0–3% per year. * Accrues per second and is minted whenever a deposit, withdrawal, or manual trigger causes accounting to run. A vault with $1M NAV and a 2% annual management fee accrues \~$54.79 per day of fee value. ## Fee caps | Fee | Cap | | ----------- | ----------- | | Entry | 2% | | Exit | 2% | | Performance | 50% | | Management | 3% per year | Caps are enforced onchain. The Change Fees screen in the app shows the current limits at the point of any change. ## Chamber's 10% protocol cut The 10% protocol cut applies across all four fee types, minted at the same time as the manager's 90%. The cut funds the [treasury](/treasury-and-protocol-economics/overview), which pays for development, audits, oracles, and other infrastructure. Depositors see the gross fee rate. The split itself is invisible to them. ## Worked example A vault with: * $1,000,000 starting NAV * 2% management fee * 20% performance fee * 0.5% entry and exit fees Over a year in which the share price grows 20% (vault ends above its high-water mark throughout), with $100k of deposits and $50k of withdrawals along the way: | Fee type | Gross fee value | Manager (90%) | Chamber (10%) | | ---------------------------------- | --------------- | ------------- | ------------- | | Management (2% on avg NAV \~$1.1M) | \~$22,000 | \~$19,800 | \~$2,200 | | Performance (20% on \~$200k gain) | \~$40,000 | \~$36,000 | \~$4,000 | | Entry (0.5% on $100k deposits) | $500 | $450 | $50 | | Exit (0.5% on $50k withdrawals) | $250 | $225 | $25 | | **Total** | **\~$62,750** | **\~$56,475** | **\~$6,275** | Numbers rounded. ## Changing fees: 14-day announcement Fee **increases** have a 14-day announcement period. You propose the new fee today; it takes effect 14 days later. Depositors have time to exit at the old rate if they don't want the change. Fee **decreases** take effect immediately. This is a depositor-protection measure and is not optional. The Guard System enforces it onchain. ## How fees accrue **Every Chamber fee is settled in vault shares.** Entry, exit, performance, and management fees all mint new shares to the manager and the Chamber protocol (split 90/10) rather than skimming cash from the deposit or withdrawal asset. * **Entry fees.** At deposit, the depositor receives fewer shares than their full deposit value would imply; the remaining shares are minted to the manager and protocol. * **Exit fees.** At withdrawal, a portion of the shares being redeemed is taken as the fee before the rest is burned for assets. * **Performance fees.** The amount owed is a function of time and the share price's run above the high-water mark. The contract can compute it at any moment. Shares are actually minted on the next deposit, withdrawal, or manual fee trigger, not continuously. * **Management fees.** Same pattern: the owed amount scales per second against total vault supply, but the shares are only minted when deposit/withdrawal/manual accounting runs. ## Claiming fees Fees live in your manager address as vault shares, a position in your own vault. To realize them: * Hold the shares as a position, same as any other depositor. * Or withdraw them, which works like any other withdrawal: single-asset or underlying basket. See [Withdrawals](/deposit/lockup-withdrawals). Because fees are shares, not cash, they stay exposed to the vault's performance until you withdraw. If the vault grows, so does the value of your accrued fees; if it shrinks, your accrued fees shrink too. Many managers withdraw on a regular cadence to lock in fee value. ## Referral shares A portion of your fees can be shared with referrers via two separate programs: * **Offchain referral program:** share a % of your performance and management fees per depositor. * **Onchain referral program:** share a % of your entry fees (all depositors). Both are optional and off by default. See [Manager programs](/manage/manager-programs) for how they work and when each applies. ## Related * [Create a vault](/manage/create-a-vault): setting fees at creation. * [Oracles](/concepts/oracles): how the NAV that performance fees are calculated against is priced. # Manager programs Referral programs, early-access chains, and DAO grants available to Chamber managers. Chamber runs a few programs that active managers can opt into. Most involve sharing fees with referrers or getting early access to new chains and features. ## Referral programs Two separate referral programs exist. They're independent: you can enable either, both, or neither. ### Offchain referral program (performance + management fees) A referrer earns a share of the **performance** and **management** fees generated by the depositors they bring in. * Set in vault settings → **Manage Referral Program**. * Two sliders: % of performance fees (0–100%), % of management fees (0–100%). * Generates a referral link for that vault. Depositors arriving through the link are attributed to the referrer for as long as they hold. * Optional toggle: **hide referral link from the vault page** (useful if you only want to share it directly). * Disabled by default. The sliders set **how much of your fee** goes to the referrer. The DAO takes its 10% protocol cut first, then the slider splits what's left. Example: 20% performance fee → 10% goes to the DAO → 18% (of profits) remains for the manager → 50% slider splits that 9%/9% between referrer and manager. ### Onchain referral program (entry fees) A referrer earns a share of the **entry** fee paid by the depositors they bring in. Onchain, programmatic, and trackable. * Set in vault settings → **Onchain Referral Program**. * Two configs: * **Per-vault share**: override for this specific vault. * **Manager global default**: applies across all vaults you manage unless a vault overrides it. * Share range: 0–100% of the entry fee. * Disabled by default. > Referral shares only take effect when **entry fees are enabled** for the vault. A vault with a 0% entry fee can't pay out an onchain referral share. There's nothing to share. ### Which program fits which use case Offchain for long-term capital partners, onchain for wide-funnel referrals. Both can run in parallel. ## HyperEVM early access HyperEVM (Perps + Spot) is a limited early-access program. Not every manager can deploy a vault there yet. Managers are onboarded in waves. If you're interested, reach out via [Discord](https://discord.com/invite/BAWTbRA). ## DAO grants The Chamber DAO occasionally allocates treasury funds to managers running strategies the ecosystem wants more of, e.g. a specific yield product, a market-making vault, or a new chain's anchor vault. Proposals and past allocations live in [Governance](/governance-and-token/overview). If you have a vault idea that needs capital to bootstrap, start there. ## Related * [Fees and performance](/manage/fees-performance): how fees work before any referral split. * [Fees & performance](/manage/fees-performance): how fees accrue before any referral split. * [Chain capabilities](/manage/chain-capabilities): which chains are generally available vs. early access. # Manager playbook A short, sensible default setup for a first Chamber vault. A sensible default for managers running their first vault. Not the only way to do it, just a safe starting point. ## A sensible default * **Chain:** [Arbitrum](/manage/chain-capabilities). Cheap gas, broad protocol support, the widest asset set. * **Privacy:** start **private** with just your own address. Flip to public once you've seeded the vault and placed a few trades you're happy with. See [Permissions & access](/manage/permissions-access). * **Assets:** tight set: USDC + WETH + one or two others you actually plan to trade. You can enable more later. Cap is 12; three or four is plenty to start. * **Fees:** 0% entry, 0% exit, 10% performance, 1% management. Modest and easy to raise later (with a [14-day announcement](/manage/fees-performance)). * **Trader:** skip on day one. Trade manually from the manager wallet until you know the flow. Add a trader later when you're ready for an API bot or automated strategy. ## First week 1. [**Create the vault**](/manage/create-a-vault) with the defaults above. 2. **Seed it yourself**: deposit a meaningful amount so the vault isn't empty. Depositors read an empty vault as "unproven". 3. **Make a few trades** from the app. Get comfortable with the [trading UI](/manage/trading) and the TradingView charts. 4. **Write a short strategy description** for the vault page. One paragraph is enough: what you trade, how often, what a depositor should expect. 5. **Share the private-vault link** with a few people you trust. Get a couple of small external deposits before going public. ## When to go public Flip to public once: * You've been running the strategy for a couple of weeks. * The Vault Score and Risk Factor reflect real activity (not just the seed deposit). * You're comfortable with the Chamber UI, trade flow, and fee mechanics. Going public is a one-click toggle in vault settings: no announcement period, no migration. ## When to add a trader Add a [delegated trader](/manage/trader-delegation) when you want to: * Run a bot via the [SDK](/build/sdk) or direct contract calls. * Keep the manager wallet cold and trade from a hot trader wallet. Leave privacy-toggle permission **off** for the trader unless you have a specific reason to turn it on. ## Raising fees later Fee **increases** have a [14-day announcement](/manage/fees-performance). Plan around it: * Announce fee changes when the vault is performing well. Depositors are less likely to leave. * Keep changes small and infrequent. Frequent fee hikes erode trust faster than a higher starting fee. * Use [referral programs](/manage/manager-programs) to reward the people who brought capital in, rather than pushing fees up on everyone. ## What not to do * **Don't set the manager address to an exchange or custodial wallet.** [Rotating it](/manage/create-a-vault#changing-the-manager-address) is non-recoverable. * **Start small on assets.** Enable only what you actually plan to trade, and add more as the strategy needs them. * **Don't set the performance fee to 50% and the management fee to 3% on a new vault.** Work up from a modest baseline. ## Related * [Create a vault](/manage/create-a-vault) * [Fees and performance](/manage/fees-performance) * [Permissions & access](/manage/permissions-access) # Overview What it means to deposit into a Chamber vault: custody, shares, and how your position moves with the vault. Chamber vaults are onchain, non-custodial, and open to anyone with a wallet. When you deposit, your funds go into the vault contract, not to the manager, not to Chamber. The manager trades the vault within rules enforced by the [Guard System](/security/guard-system). You can withdraw at any time. This section walks through how depositing works, how to pick a vault, and what to know before committing capital. ## What depositing actually does You deposit assets (usually a stablecoin or native token) into a vault through the Chamber app, which routes the call through the vault contract. In return, the contract mints you **vault shares**: a receipt token that represents your proportional claim on everything the vault holds. Never transfer assets directly to the vault address; only deposits made through the proper flow mint shares. * If the vault grows, your shares are worth more. * If the vault loses money, your shares are worth less. * You can withdraw your shares any time (after the [24-hour lockup](/deposit/lockup-withdrawals)), either for a single asset or for the underlying basket. The manager can trade the vault's assets but **cannot withdraw, reassign, or seize your shares**. Custody is onchain and yours. ## Before you deposit * **Pick a vault that matches your risk tolerance.** Strategy, fees, track record, and chain all matter. See [Find a vault](/deposit/find-a-vault). * **Understand the fees.** Entry, exit, performance, management: these are set by the manager and vary per vault. See [Fees](/deposit/fees). * **Know the risks.** Smart contracts, market exposure, manager decisions, oracle risk. See [Risks](/deposit/risks). * **Plan your horizon.** Every deposit has a 24-hour lockup. Withdrawals are always available after that, but fee structures reward longer holds. ## What's in this section * [Find a vault](/deposit/find-a-vault): filtering by chain, strategy, fees, and vault score. * [Deposit](/deposit/deposit): the deposit flow end-to-end. * [Lockup & withdrawals](/deposit/lockup-withdrawals): the 24h post-deposit lockup and how withdrawals work (single-asset or basket). * [Fees](/deposit/fees): what you pay and when. * [Insurance](/deposit/insurance): coverage options. * [Risks](/deposit/risks): the honest list. # Find a vault How to browse, filter, and evaluate Chamber vaults before depositing. Chamber vaults are listed in the [Chamber app](https://chamberfi.com/). You can filter by chain, strategy category, fees, and performance metrics. Every vault has a public page with its full composition, history, and manager details. ## The vault directory Open the Chamber app and navigate to the vault list. Each card shows: * **Vault name and manager.** * **Chain.** Ethereum, Polygon, Optimism, Arbitrum, Base, Plasma, or HyperEVM. * **Strategy category.** Managed, automated, yield, leverage, etc., a label the manager sets in vault settings. * **Vault Score and Risk Factor.** Summary metrics (see below). * **Current AUM.** * **Fees.** Entry / exit / performance / management at a glance. ![Vault directory](/files/mV7rtsMhBxjHnoEUdw3j) ## Vault Score and Risk Factor Two metrics help you compare vaults quickly. Neither is a prediction; both are backward-looking. * **Vault Score**: a performance summary calculated as *Sortino ratio × √(7-day average vault value)*. Rewards steady, risk-adjusted returns on vaults that have meaningful capital deployed. A new vault with no history will show a low score until it's been running for a while. * **Risk Factor**: a 1–5 rating based on downside deviation. 1 = historically low downside volatility, 5 = historically high. Useful as a first-pass filter, not a guarantee. See [Leaderboard & ranking](/concepts/leaderboard-ranking) for the full methodology. ## The vault page Clicking into a vault shows: * **Composition**: what the vault currently holds, broken down by asset. * **Performance chart**: NAV over time, priced in USD via the [oracle layer](/concepts/oracles). * **Fee schedule**: full fees, the high-water mark for performance, and the annual management rate. * **Manager**: name, address, and any other vaults they run. * **Trading history**: recent transactions executed by the manager or their [delegated trader](/manage/trader-delegation). * **Whitelist status**: public or [private](/manage/permissions-access). If private, you'll see a "not eligible to deposit" message unless the manager has added your address. ![Vault page](/files/FaRSA1HcWpPo1299PPuN) ## What to look at before depositing Rough order of importance: 1. **Does the strategy match what you want exposure to?** A stablecoin yield vault and a leveraged ETH vault are radically different products. Read the strategy description. 2. **Risk Factor.** Anything you wouldn't sleep through should be reflected here. 3. **Track record length.** A vault with two weeks of history tells you less than one with two years. 4. **Manager.** Who runs it, what else they run, how they communicate. 5. **Fees.** Higher performance fees aren't automatically bad, but they need to be justified by the strategy. 6. **Composition.** What's the vault actually holding right now? Does it match the stated strategy? ## Related * [Deposit](/deposit/deposit): the deposit flow itself. * [Risks](/deposit/risks): the honest list of what can go wrong. * [Leaderboard & ranking](/concepts/leaderboard-ranking): how Vault Score and Risk Factor are calculated. # Deposit How to deposit into a Chamber vault: connect, choose asset, sign, receive vault shares. Depositing takes a minute or two. You connect a wallet, pick the vault, choose which asset to deposit, sign the Terms of Use, approve the token, and confirm the buy. In return you receive **vault shares**: your receipt token and proportional claim on the vault. ## Before you start * **Wallet on the right chain.** Each vault lives on one chain only. You deposit from the same chain the vault is on. * **Gas.** You'll pay network gas for the deposit transaction (e.g. ETH on Arbitrum, POL on Polygon). Small but non-zero. * **Eligibility.** [Public vaults](/manage/permissions-access) accept anyone. Private vaults require your address to be on the manager's whitelist. ## The flow ### 1. Open the vault From the [Chamber app](https://chamberfi.com/), click into the vault you want to deposit to. ### 2. Click Buy The button is labelled **Buy**. Buying into a vault and depositing are the same action. ![Vault page: Buy button](/files/psNkmwb7IAy7nyLOD2Qz) ### 3. Choose your asset Most vaults accept a small set of deposit assets: typically USDC, and often the vault's main non-stable asset (e.g. WETH on an ETH-strategy vault). The accepted list is set by the manager via the vault's [enabled assets](/manage/permissions-access). On HyperEVM, vaults take USDC. Enter the amount you want to deposit. The UI shows: * The **deposit value in USD** (the vault's [denomination asset](/manage/denomination-asset)). * Any **entry fee** (0–2% depending on the vault). * The **estimated vault shares** you'll receive. * A notice that your deposit will be **locked for 24 hours**. ![Deposit modal](/files/nBWUddo5XLLHLhfGR1Kr) ### 4. Sign the Terms of Use The first time you buy into a vault you'll be asked to sign the Terms of Use, which includes confirming you're not in a restricted location. This is an offchain message signature rather than a transaction, so it costs no gas and moves no funds. ### 5. Approve the token First-time deposits of a given asset require a one-off approval transaction: you're authorizing the vault contract to pull that asset from your wallet. Sign from your wallet. Small gas cost. ### 6. Confirm the buy Once approved, confirm the buy transaction. The app labels these last two steps **1/2 Approve Buy** and **2/2 Buy Now**. Once mined: * Your chosen asset moves from your wallet to the vault contract. * You receive vault shares in return, proportional to your deposit minus the entry fee. * The 24-hour lockup timer starts. ## After depositing * **You now own vault shares.** They show up in your wallet as a standard ERC-20 token with the vault's symbol. They're yours; the manager cannot move, burn, or seize them. * **Your deposit is locked for 24 hours.** You can't withdraw during that window. See [Lockup & withdrawals](/deposit/lockup-withdrawals) for why. * **Your position tracks the vault.** As the manager trades and the vault's NAV moves, the value of your shares moves with it, up or down. ## Common questions **Can I deposit to a private vault?** Only if the manager has added your address to the whitelist. If you can't deposit, the UI tells you plainly. **Can I deposit from a different chain?** No. The vault lives on one chain; you deposit on that chain. Use a bridge first if your funds are elsewhere. **What if I deposit the wrong amount?** You can withdraw after the 24-hour lockup (minus any exit fee). Deposit and withdrawal fees both apply if you change your mind right after the lockup. **Is there a minimum?** Some vaults set a [minimum deposit](/manage/permissions-access#minimum-deposit). Most don't. The UI tells you if there is one. ## Related * [Lockup & withdrawals](/deposit/lockup-withdrawals): what happens after the 24 hours. * [Fees](/deposit/fees): what you pay, before and after. * [Risks](/deposit/risks): what can go wrong. # Lockup & withdrawals The 24-hour post-deposit lockup, and the two ways to withdraw: single-asset or underlying basket. Every Chamber deposit has a lockup of **up to 24 hours**, after which you can withdraw any time. Withdrawals work in one of two ways: cash out as a single asset (Chamber swaps the vault's holdings for you), or redeem a pro-rata slice of the actual underlying basket. ## The 24-hour lockup After a deposit, your vault shares are locked before you can withdraw them. * A **fresh deposit** (no existing position in the vault) starts a full **24-hour** timer. * A **top-up** on top of an existing position applies a **weighted** lockup: the added lock time is proportional to how much you added relative to what you already held. A small top-up on a large existing position adds only a small amount of lock time (seconds or minutes). A large top-up adds something closer to the full 24 hours. * The gate applies to your **whole balance in that vault**, not just the new shares. During the lockup window, the entire position is locked. * The lockup applies to **everyone**, including the manager. It's a flash-loan protection measure: it blocks same-block manipulation patterns. It is **not** a redemption queue or a manager-controlled gate. Once the window passes, your shares behave like any other ERC-20: you can withdraw, transfer, or hold. ## Two withdrawal methods When you open the Withdraw modal on a vault page, you pick one of two methods. ### Single-asset withdrawal You specify which asset you want out (usually USDC). The vault liquidates a pro-rata slice of its holdings and returns the target asset to you. * **Pros.** Simplest outcome: you get one clean token. * **Cons.** Involves internal swaps at current market rates, which means slippage and swap fees eat into your withdrawal. On a thin market or a volatile day, that can be noticeable. ### Underlying basket withdrawal You receive a pro-rata slice of whatever the vault currently holds. If the vault is 60% USDC / 30% WETH / 10% aUSDC, you get 60%/30%/10% of your share value in each. * **Pros.** No market swaps on plain token holdings: you get those out directly, no slippage or swap fees. * **Caveat.** If the vault holds LP tokens, lending positions, or other complex assets, the protocol still has to *unwind* them to hand you the underlying. That's not a market swap, but it costs gas for the unwind steps and, in some cases, protocol-side costs (e.g. unstaking, withdrawing from a lending pool). * **Cons.** You have to handle the basket yourself. Some positions aren't trivially tradeable out in one click; you may need to unwind them manually. For most depositors, **single-asset is the default**. Use basket if the vault has a clean, liquid composition or if you want the individual positions for your own reasons. ## The withdrawal flow 1. **Open the vault page** in the [Chamber app](https://chamberfi.com/). 2. **Click Withdraw.** You'll see your current share balance, its USD value, and any exit fee. 3. **Pick the method**: single-asset or underlying basket. 4. **Enter the amount** of shares to redeem. You can part-withdraw; you don't have to exit fully. 5. **Sign the transaction.** Assets return to your wallet once mined. ![Withdraw modal](/files/VjYCLhrq64U8gtZqvEag) ## Fees on withdrawal The vault's exit fee (0–2% depending on the vault, set by the manager) applies to both methods. Performance fees are already accounted for continuously and aren't re-charged at withdrawal. See [Fees](/deposit/fees). ## Common questions **What if the vault holds an illiquid asset when I want to withdraw?** Single-asset withdrawal may have more slippage than usual; basket withdrawal hands you the illiquid token directly. In extreme cases (e.g. a single underlying market is frozen), withdrawals can be temporarily difficult (see [Risks](/deposit/risks)). **Can I withdraw a fraction of my shares?** Yes. Enter any amount up to your balance. **Is there a withdrawal queue?** No. Withdrawals are immediate once the lockup has passed. You don't wait for a manager action or a redemption window. **What if I deposit, then need to withdraw right away?** You can't. The lockup is enforced onchain. For a fresh deposit that's up to 24 hours; for a small top-up on an existing position it can be much shorter. Plan around it rather than depositing funds you might urgently need. ## Related * [Deposit](/deposit/deposit): the deposit flow itself. * [Fees](/deposit/fees): the fees you pay on deposit and withdrawal. * [Risks](/deposit/risks): edge cases around illiquid underlyings and withdrawal stress. # Fees What depositors pay on a Chamber vault: entry, exit, performance, and management fees. All settled in vault shares and socialized across depositors. Every vault sets its own fees, within protocol-wide caps. There are four fee types. **All four are settled in vault shares**, not in cash. The manager and the Chamber protocol receive newly-minted vault shares, and the economic effect on depositors is a small ongoing dilution of share price. Chamber's cut is **10% of every fee**, split automatically onchain. For the manager-side view of how fees are set and changed, see [Fees and performance](/manage/fees-performance). ## Fees are charged evenly across every depositor A key thing to understand up front: Chamber fees are **not** calculated against each depositor's personal entry point or cost basis. The vault has one shared high-water mark, one shared management-fee meter, and one shared fee schedule. When fees accrue, they accrue at the vault level and are socialized proportionally across every holder via share dilution. Practical consequence: whether you deposited yesterday or two years ago, you experience the same fee mechanic at the same time. ## The four fees ### Entry fee Charged on deposit. The mechanic: a portion of the shares that would have been minted to you is minted instead to the manager and the Chamber protocol. * Typical: 0–2%. * On a $10,000 deposit with a 0.5% entry fee, you receive shares worth $9,950; shares worth the remaining $50 are minted to the manager (90%) and Chamber (10%). * Disclosed up front in the deposit modal. ### Exit fee Charged on withdrawal. Same mechanic as the entry fee, on the way out: a portion of the shares you're redeeming is taken as the fee before the remainder is burned for assets. * Typical: 0–2%. * Applies to both single-asset and underlying-basket [withdrawals](/deposit/lockup-withdrawals). ### Performance fee Charged on the vault's appreciation above its **high-water mark** (HWM). The HWM is vault-level: the highest share price the vault has reached since the last performance fee was minted. The fee is not tied to any individual depositor's entry price. * Typical: 0–50%. * When the share price grows above the HWM, new shares are minted to the manager and the Chamber protocol equal in value to the manager's agreed cut of the growth. Every existing holder's share count stays the same, but each share is now a slightly smaller slice of the same vault. That's how the fee is paid. * If the vault drops below its HWM and later recovers, no new performance fee accrues until the HWM is exceeded. The HWM only resets when a new all-time high is set and the corresponding fee is minted. * Performance fees are automatically calculated and minted on every new deposit or withdrawal to the vault, and can also be triggered manually by the manager. ### Management fee Charged continuously on the vault's total assets. Works the same way as the performance fee: new shares minted to the manager and the Chamber protocol, socialized across all depositors via dilution. * Typical: 0–3% per year. * The amount owed scales per second against total vault supply, annualized. Shares aren't minted continuously; they're minted on the next deposit, withdrawal, or manual fee trigger. The effect on share price is the same either way. * Charged regardless of performance. ## Chamber's 10% protocol cut All four fees are split **90% manager / 10% Chamber protocol**, at the point of minting. You pay one fee; the protocol takes its share onchain, automatically, with no separate action by you or the manager. The protocol cut funds the [treasury](/treasury-and-protocol-economics/overview), which pays for audits, infrastructure, and ongoing development. This 10% cut applies to **all four fee types** (entry, exit, performance, management). The split ratio is set at the factory level and used identically for every fee path. ## How this shows up on your position * Your **share count** stays the same over time (ignoring deposits or withdrawals you make yourself). * The **share price** tracks the vault's NAV minus the dilution from accruing fees. Fees don't appear as a separate charge, they reduce the rate at which your share price rises (or accelerate the rate at which it falls). * You never see a cash deduction in your deposit asset. ## Where to see fees for a vault Every vault page shows its full fee schedule below the performance chart. The deposit modal restates the relevant fees (entry + the annualized view of management/performance) before you sign. ## When fees change Managers can change their fees, but **increases have a 14-day announcement period**. The new rate can't take effect for 14 days after it's announced. You'll see a notice on the vault page during that window, giving you time to withdraw at the old rate if you don't want the change. Fee **decreases** take effect immediately. This rule is enforced by the [Guard System](/security/guard-system), not a trust-based promise. ## Quick reference | Fee | When charged | Typical range | Settled as | Notice on increase | | ----------- | ---------------------------------- | ------------- | ------------ | ------------------ | | Entry | On deposit | 0–2% | Vault shares | 14 days | | Exit | On withdrawal | 0–2% | Vault shares | 14 days | | Performance | Share price above vault high-water | 0–50% | Vault shares | 14 days | | Management | Continuously on total supply | 0–3% / year | Vault shares | 14 days | All four fees are split 90% manager / 10% Chamber protocol onchain. ## Related * [Lockup & withdrawals](/deposit/lockup-withdrawals): how exit fees apply. * [Manage → Fees and performance](/manage/fees-performance): the manager-side mechanics. * [NAV & accounting](/concepts/nav-accounting): how share price is calculated, which is what fees dilute. # Insurance Optional smart-contract cover for Chamber vault deposits, via OpenCover and Nexus Mutual. Depositors can buy optional cover against smart-contract failure on Chamber vaults through [**OpenCover**](https://opencover.com/app/?invite=DH100K\&cover=126\&filter=Protocol+Cover\¤cy=USDC\&amount=50000\&duration=90). Cover is underwritten by **Nexus Mutual** and is purchased and paid for by the depositor; Chamber doesn't buy cover on your behalf. ## What's covered **Protocol cover** is the relevant product. It pays out if a smart-contract failure in the Chamber protocol causes loss of depositor funds. Depeg cover and Custody cover also exist on OpenCover but are not the primary cover for Chamber vault positions. Cover is priced in USDC, runs for up to 90 days at a time, and can be renewed. Cover is available across the same chains OpenCover currently supports for Chamber (Ethereum, Arbitrum, Base, Optimism, Polygon). Chamber chains outside that set are not covered today. ## What's *not* covered Insurance does not protect against: * **Market losses.** If the manager's trades go against you, that's market risk, not a contract failure. No cover pays for this. * **Strategy losses.** Leverage liquidations, LP impermanent loss, oracle drift, stablecoin depegs inside a vault's positions. These are disclosed on the vault page and in [Risks](/deposit/risks). * **Manager abandonment or inactivity.** The Guard System limits what a manager can do with funds, but it doesn't pay out if a manager stops managing. Cover exists specifically for the case where the Chamber contracts themselves fail, the same case that audits, the [Guard System](/security/guard-system), and the [bug bounty](/security/bug-bounty) are designed to prevent. ## How to buy cover 1. Go to [**OpenCover**](https://opencover.com/app/?invite=DH100K\&cover=126\&filter=Protocol+Cover\¤cy=USDC\&amount=50000\&duration=90). 2. Select **Protocol cover**, with Chamber as the covered protocol. If the OpenCover UI still lists the protocol as dHEDGE during the rebrand window, use that entry. 3. Enter the amount you want covered and the duration (up to 90 days). 4. Connect your wallet and pay the cover premium in USDC. Toros vaults sit inside the same protocol, so cover purchased via the same OpenCover listing applies. Toros product pages link to the same cover flow. ## Should you buy cover? That's a personal decision. A few pointers: * Cover makes more sense at larger deposit sizes where the premium is small relative to what's at risk. * It's an **add-on** to Chamber's built-in protections, not a substitute for checking the vault's risk profile before depositing. * If you're relying on cover, read the OpenCover policy terms so you understand what triggers a payout and what the claim process looks like; Chamber is not the underwriter. ## See also * [Risks](/deposit/risks): the full list of what can go wrong, with or without cover. * [Security overview](/security/overview): audits, Guard System, and incident history. * [Incident history](/security/incident-history): actual loss events since launch. # Risks The honest list of smart contract, market, manager, oracle, and liquidity risks in Chamber vaults. Chamber is designed to make vault strategies **safer by default**, not risk-free. Depositors should understand what can still go wrong. This page covers the main risk categories in plain English. For the formal frame, see [Risk model](/security/risk-model). ## Market risk The most common source of losses: the manager's trades move against the market. * A vault trading ETH can lose value when ETH drops. * A leveraged vault can lose multiples of the underlying asset's move. * A stablecoin yield vault can still lose money if an underlying stablecoin depegs or a lending market goes bad. Match the vault's strategy to risk you can actually stomach. Check the [Risk Factor](/concepts/leaderboard-ranking) and the composition before depositing. ## Smart contract risk Chamber vaults are smart contracts. Despite [audits](/security/audits), a [bug bounty program](/security/bug-bounty), and the [Guard System](/security/guard-system), no contract is provably bug-free. A critical bug could lock funds or allow unintended asset movement. Mitigations Chamber applies: * Multiple external audits before deployment. * The Guard System restricts what managers and traders can do onchain. * A public [incident history](/security/incident-history): no loss of depositor funds since launch in October 2020. ## Manager risk The manager makes trading decisions. They cannot take custody or change the vault's rules arbitrarily, but they can still make bad calls: choose poor entries, hold too long, concentrate too heavily in one asset. The Guard System limits what a manager can do (enabled assets, approved protocols, fee caps) but does **not** limit how well or badly they trade within those rules. Evaluate the manager before depositing: track record, communication, other vaults they run. ## Oracle risk Vault NAV is priced via [oracles](/concepts/oracles): Chainlink and Pyth. Oracles can go wrong: * Feed staleness if a provider stops updating. * Manipulated prices on thin markets (rarer with Chainlink/Pyth than alt oracles, but still a consideration). * A feed reporting an incorrect value briefly. Most of the time, oracles are fine. In exceptional cases, a depeg or flash price anomaly can cause mispricing of shares for a short window. ## Liquidity risk When you withdraw, the vault needs to produce assets for you: * **Single-asset withdrawal** may incur slippage if the vault holds illiquid assets it has to swap out. * **Underlying basket withdrawal** hands you a slice of whatever the vault holds, including any illiquid positions, which you'd need to unwind yourself. In extreme market stress, an underlying market being frozen or highly slipped can make withdrawals temporarily painful. Chamber doesn't gate withdrawals; the mechanics just pass the cost of the stressed market to you. See [Lockup & withdrawals](/deposit/lockup-withdrawals) for both methods. ## Tokenized real-world assets Chamber vaults can hold tokenized stocks, ETFs, and commodities via [Ondo Stocks](/concepts/supported-assets) (currently on Ethereum). Alongside ordinary market risk, these carry risks specific to tokenized RWAs: * **Regional access.** Vaults that hold Ondo Stocks tokens are subject to eligibility, offering, and regional access rules, and may not be available in all locations. * **Economic exposure.** The tokens provide economic exposure to the underlying asset under Ondo's terms (subject to its offering and access rules), rather than direct ownership of the share or commodity. ## Regulatory risk Chamber is a decentralized protocol, but the broader regulatory environment for onchain asset management is evolving. Future changes in your jurisdiction could affect your ability to deposit, withdraw, or claim gains from Chamber vaults. Check local rules; Chamber cannot advise on them. ## Risks that are NOT in scope Some things people worry about that the Guard System explicitly prevents: * **The manager rugging your deposit.** Not possible: the manager never has custody of your funds. Shares are yours, withdrawable any time (after the 24-hour lockup). * **The manager changing fees overnight.** Not possible: fee increases have a 14-day announcement period enforced onchain. * **The manager whitelisting a malicious contract on-the-fly.** Not possible: the Guard System's protocol allowlist is protocol-level, not manager-level. The principle applies to human and automated managers alike: *the goal is not to trust the manager more; the goal is to make the vault safer by design*. ## Related * [Security overview](/security/overview) * [Risk model](/security/risk-model) * [Guard System](/security/guard-system) * [Audits](/security/audits) and [Incident history](/security/incident-history) # Overview Integrator's entry point: what you can build, and which surface to use Chamber is a set of onchain vaults plus supporting infrastructure. Everything a manager or depositor does through the app is also available to integrators. This section is the developer reference. If you're building a product that creates vaults, composes trades, reads vault state, or automates a strategy, you're in the right place. ## What you can build * **Vault-backed products:** consumer apps, yield strategies, and managed portfolios that wrap a Chamber vault. This is how [Toros Finance](/ecosystem/toros-finance) is built. * **Automated managers:** bots that trade a vault within the Guard System's rules, via the [SDK](/build/sdk) or direct contract calls. Teams often use an LLM to help write the strategy code. * **Analytics and dashboards:** vault discovery, performance tracking, leaderboards. The [subgraph](/build/subgraph) (per-chain, indexed) is the primary data source; the [Data API](/build/data-api) is a lighter hosted GraphQL that aggregates across chains. * **Deposit and withdrawal flows:** if you're embedding Chamber in another app, the [SDK](/build/sdk) handles quoting and transaction construction in TypeScript; for other languages or lightweight clients, call the contracts directly. ## The surfaces | Surface | Purpose | When to use | | -------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------- | | [Contracts](/build/contract-addresses) | The vault contracts themselves | Direct integration, custom tooling | | [SDK](/build/sdk) (`@dhedge/v2-sdk`) | TypeScript wrapper over the contracts | Building a full manager or wallet flow | | [Subgraph](/build/subgraph) | Indexed vault, position, and transaction data | Analytics, UIs, leaderboards | | [Data API](/build/data-api) | Hosted GraphQL for cross-chain vault lists, prices, analytics | Lightweight read access without running a subgraph | | [MCP server](/build/mcp-server) | Local MCP server that reads vault state from an AI client | Read-only monitoring and analysis | ## Before you start Three things to know up front: 1. **Everything flows through the** [**Guard System**](/build/guard-system)**.** Your integration can only compose calls that a whitelisted contract guard will approve. If you're trying to interact with a protocol Chamber doesn't already support, the call will revert at the vault entrypoint. The integrator-facing guard page covers how to check what's supported on a given chain. 2. **Chains are not uniform.** The set of supported protocols, assets, and guards differs across chains. Always check the [deployment matrix](/build/deployment-matrix) and [contract addresses](/build/contract-addresses) for the chain you're targeting before writing chain-specific logic. 3. **Fees are settled in vault shares.** Performance, management, entry, and exit fees are all minted as shares to the manager and DAO, not deducted from the deposit asset. If your UI shows fee impact, model it as share dilution. See [fees & performance](/manage/fees-performance). ## Quick start The fastest path depends on what you're building: * **"I want to create and manage a vault programmatically"** → [SDK](/build/sdk). * **"I want to query vault data"** → [Subgraph](/build/subgraph). * **"I want my users to deposit into an existing vault from my app"** → [SDK](/build/sdk) if TypeScript, or call the vault's `deposit` function directly (see [contract addresses](/build/contract-addresses)). * **"I want to read vault state from an AI client (Claude, Cursor, …)"** → [MCP server](/build/mcp-server). * **"I want end-to-end examples"** → [Integration examples](/build/integration-examples). ## Repositories All integrator-facing code is open source: * Contracts: [github.com/dhedge/V2-Public](https://github.com/dhedge/V2-Public) * SDK: [github.com/dhedge/dhedge-v2-sdk](https://github.com/dhedge/dhedge-v2-sdk) (`@dhedge/v2-sdk`) * Subgraphs: [github.com/dhedge/dhedge-v2-subgraphs](https://github.com/dhedge/dhedge-v2-subgraphs) * MCP server: [`@dhedge/chamber-mcp`](https://www.npmjs.com/package/@dhedge/chamber-mcp) on npm ## Support * [Discord](https://discord.com/invite/BAWTbRA): `#developers` channel * GitHub issues on the relevant repo * Security disclosures: see [bug bounty](/security/bug-bounty) ## See also * [Guard system](/build/guard-system): the integrator-facing rules for what calls will succeed * [Concepts: vaults as guardrails](/concepts/vaults-as-guardrails): the model your integration is operating inside # Deployment matrix Which chains Chamber is deployed on, and what differs between them Chamber's contracts are deployed on seven public chains. The Guard System, SDK, and subgraph support is not uniform across all of them. Which protocols a vault can use, and which assets it can hold, depends on the chain. ## Supported chains | Chain | Chain ID | Notes | | -------- | -------- | --------------------------------------------------------------------------------------------------------------------- | | Ethereum | 1 | | | Optimism | 10 | | | Polygon | 137 | | | Base | 8453 | | | Arbitrum | 42161 | | | Plasma | 9745 | | | HyperEVM | 999 | Hyperliquid's EVM chain. Perps-native asset support via Hyperliquid guards (see [guard system](/build/guard-system)). | For the canonical list of deployed contract addresses per chain, see [contract addresses](/build/contract-addresses). ## What differs between chains Not every chain supports every protocol. Each deployment ships with its own set of: * **Contract guards:** which protocols a vault can call (Aave, Uniswap, GMX, Velodrome, etc.). A protocol that doesn't exist on a chain obviously isn't supported; a protocol that does exist may still be absent if a guard hasn't been written or whitelisted for it. * **Asset guards:** which asset types a vault can hold (plain ERC20, Aave aTokens, Uniswap V3 positions, GMX perps, etc.). * **Asset allowlist:** the specific token addresses and price feeds that are approved for deposit/trade on that chain. A vault deployed on Base cannot hold positions on Arbitrum. Chamber does not do cross-chain accounting inside a single vault. See [chain capabilities matrix](/manage/chain-capabilities) for the manager-facing version of this (which protocols are available on which chain). For the full list of guards, see the [guard system](/build/guard-system) page. ## Checking support at runtime Rather than hard-coding protocol support in your integration, query it onchain: * `PoolFactory.getAssetGuard(assetAddress)`: returns the asset guard for a given token. Zero address means the asset is not supported. * `PoolFactory.getContractGuard(contractAddress)`: returns the contract guard for a given protocol destination. Zero address means calls to that address will revert with `dh23` at the vault entrypoint. * `PoolManagerLogic.isSupportedAsset(address)` and `isDepositAsset(address)`: check per-vault support and deposit eligibility. These are the source of truth. Governance can add or swap guards at any block, so cached allowlists can go stale. ## SDK chain coverage The [`@dhedge/v2-sdk`](/build/sdk) exposes a `Network` enum covering the supported EVM chains. Coverage moves with releases, so pin a version and check the enum on it. ## Subgraph chain coverage The [subgraph](/build/subgraph) is deployed per chain. Each chain has its own GraphQL endpoint. The hosted chains are the same set of EVM chains listed above; check the subgraph repo for the current endpoint per network. ## See also * [Contract addresses](/build/contract-addresses): canonical per-chain addresses * [Guard system](/build/guard-system): how to enumerate supported protocols and assets * [Chain capabilities matrix](/manage/chain-capabilities): manager-facing view of what's available where # Contract addresses Canonical Chamber contract addresses per chain The canonical source of truth for deployed contract addresses is the [`publish/{chain}/prod/versions.json`](https://github.com/dhedge/V2-Public/tree/master/publish) file in the contracts repo. This page summarizes the contracts you are most likely to need and points you at that source. **Don't hard-code addresses from stale docs.** Governance can swap implementations via proxy upgrades, and new chains are added periodically. Read the deployment data at build time or at runtime. ## Core contracts per chain Most Chamber deployments share this core set; a few contracts ship only where the feature is enabled. Contract names are stable across chains; only the addresses differ. | Contract | Role | | ------------------ | --------------------------------------------------------------------------------------------------------------------------- | | `PoolFactory` | Creates new vaults; owns the Guard System registry; exposes `getAssetGuard()` and `getContractGuard()` view functions | | `PoolLogic` | Implementation contract for every vault. Handles `deposit`, `withdraw*`, `execTransaction` | | `PoolManagerLogic` | Implementation contract for every vault's manager/permissions surface. Handles `changeAssets`, fee settings, privacy toggle | | `AssetHandler` | Central pricing registry. Resolves USD value for every supported asset | | `EasySwapperV2` | Convenience contract for simplified deposit/swap routing | | `Governance` | Admin contract that registers new contract and asset guards | ## Where to get addresses **Source of truth:** the [`publish/`](https://github.com/dhedge/V2-Public/tree/master/publish) directory in the contracts repo. * `publish/ethereum/prod/versions.json` * `publish/ovm/prod/versions.json` (Optimism) * `publish/polygon/prod/versions.json` * `publish/base/prod/versions.json` * `publish/arbitrum/prod/versions.json` * `publish/hyperevm/prod/versions.json` * `publish/plasma/prod/versions.json` Each file is a JSON object containing the full set of contract addresses, asset configurations, and guard registrations for that chain. If you're using the [SDK](/build/sdk), these are wired in for you. You shouldn't need to read them directly unless you're doing raw contract calls. ## Vault addresses Every vault is a `PoolLogic` proxy deployed by the `PoolFactory`. Vault addresses are not listed here. They are created over time by managers. Discover vaults via: * [**Subgraph**](/build/subgraph)**:** the most ergonomic way to list vaults, filter by chain, manager, or denomination asset. * **App UI:** vault discovery via search and leaderboard. * **Factory events:** the `PoolFactory.FundCreated` event logs every new vault. ## Guard addresses Contract guards and asset guards are not hard-coded in the SDK or docs. Resolve them at runtime: ```solidity // Is this protocol callable from a vault? address guard = PoolFactory(factory).getContractGuard(targetProtocol); require(guard != address(0), "not whitelisted"); // Is this asset supported? address assetGuard = PoolFactory(factory).getAssetGuard(asset); require(assetGuard != address(0), "asset not supported"); ``` Or from TypeScript via the SDK, which wraps these calls. ## Upgrades and proxies `PoolLogic` and `PoolManagerLogic` are implementation contracts behind per-vault proxies. Implementation upgrades apply to every vault immediately. Upgrades are `onlyOwner` on the factory, which is controlled by Chamber governance. See [Governance](/governance-and-token/overview) for the current custody arrangement. ## See also * [Deployment matrix](/build/deployment-matrix): which chains ship with which features * [Guard system](/build/guard-system): how to enumerate supported protocols and assets * [SDK](/build/sdk): the typed wrapper over these contracts # Guard system (integrator reference) How to write calls that pass the Guard System, and how to handle rejections For the risk-model framing (what the Guard System prevents and why), see [Security: guard system](/security/guard-system). This page is the integrator's side: how to write calls that don't revert, how to enumerate what's supported, and how to surface failures back to users. ## Call flow Every vault interaction flows through `PoolLogic.execTransaction(address to, bytes data)`: 1. The vault looks up the **contract guard** registered for `to` via the factory. 2. The guard's `txGuard(poolManagerLogic, to, data)` is called. It decodes the calldata, enforces protocol-specific rules, and returns a `txType` plus `isPublic` flag. 3. If the contract guard returns `txType == 0` (no match or rejection), or isn't registered, the vault falls back to the **asset guard** for `to`. If no asset guard is registered either, it defaults to the governance-configured `ERC20Guard` as a last resort. A revert with `dh23` means every layer returned `txType == 0`. 4. On approval, the external call executes. 5. Some guards implement `afterTxGuard` to track post-call state (for example, recording open perp positions). The manager/trader permission check happens at the vault layer before the guard runs. The guard itself doesn't distinguish manager from trader. See [trader delegation](/manage/trader-delegation) for how that's enforced. ## Two guard categories **Contract guards**: registered against a destination contract address (a swap router, a lending pool, a position manager). They govern *what calls* can be made to that contract. Examples: `OneInchV6Guard`, `AaveLendingPoolGuardV3`, `UniswapV3NonfungiblePositionGuard`, `GmxExchangeRouterContractGuard`. **Asset guards**: registered against an asset type (a token, an LP NFT, a perp position). They govern *how the vault holds and unwinds that asset*: balance calculation, USD pricing, withdrawal behavior. Examples: `ERC20Guard`, `UniswapV3AssetGuard`, `AaveLendingPoolAssetGuard`, `HyperliquidPositionGuard`. A single vault operation may touch both. A Uniswap V3 mint needs the position manager contract guard to approve the call and an asset guard registered for the resulting LP NFT so the vault can price and withdraw it. ## Enumerating support **Is this protocol callable from a vault?** ```solidity address guard = PoolFactory(factory).getContractGuard(destination); // guard == address(0) → call will revert with dh23 // guard != address(0) → call MAY succeed, depending on the guard's rules ``` **Is this asset supported?** ```solidity address assetGuard = PoolFactory(factory).getAssetGuard(asset); // assetGuard == address(0) → asset cannot be added to a vault ``` **Is this asset enabled on a specific vault?** ```solidity PoolManagerLogic(pml).isSupportedAsset(asset); // can be traded/held PoolManagerLogic(pml).isDepositAsset(asset); // can be used to deposit ``` A guard being registered globally is necessary but not sufficient. The manager also has to have enabled that asset on their vault. ## Common revert codes Vault reverts use `dh`-prefixed strings. The full list of codes with descriptions is maintained in the contracts repo: [`dHEDGEV2ErrorCodes.json`](https://github.com/dhedge/V2-Public/blob/master/readmes/errorCodes/dHEDGEV2ErrorCodes.json) ## Guard registry The exact set of guards differs per chain (see [deployment matrix](/build/deployment-matrix)). The full per-chain lists of contract guards, asset guards, and deprecated guards are maintained in the [`config/`](https://github.com/dhedge/V2-Public/tree/master/config) directory of the contracts repo. Each chain folder contains: * `dHEDGE Governance Contract Guards.csv`: registered contract guards * `dHEDGE Governance Asset Guards.csv`: registered asset guards * `dHEDGE Assets list.json`: supported assets You can also query `getContractGuard()` and `getAssetGuard()` on the factory at runtime. ## See also * [Security: guard system](/security/guard-system): the risk framing * [Contract addresses](/build/contract-addresses): where to find the factory * [SDK](/build/sdk): typed helpers for guard queries * [Deployment matrix](/build/deployment-matrix): per-chain guard availability # SDK TypeScript SDK for creating vaults, trading, and managing positions The Chamber SDK is the TypeScript wrapper over the vault contracts. It covers vault creation, deposits, withdrawals, trading across supported protocols, and LP/lending/perp operations, all composed into guard-compliant transactions. **Package:** `@dhedge/v2-sdk` (npm name is staying; code identifiers don't rebrand) **Install:** `npm install @dhedge/v2-sdk` **Requires:** `ethers` v5 with a signer connected to an RPC for a supported chain. ## Supported chains The SDK tracks contract deployments but typically trails by a release. If you need a chain, asset, or protocol that's live in the contracts but not in the installed SDK version, call the contracts directly. The [deployment matrix](/build/deployment-matrix), [contract addresses](/build/contract-addresses), and [Guard System](/build/guard-system) pages are the authoritative sources for what Chamber supports, not the SDK. The SDK's `Network` enum currently covers **Polygon, Optimism, Arbitrum, Base, Ethereum, Plasma, and HyperEVM** (exposed in code as `Network.HYPERLIQUID`). Pin a version and verify the enum on it before targeting newer chains. ## Quick start ```ts import { Dhedge, Dapp, Network, ethers } from "@dhedge/v2-sdk"; const provider = new ethers.providers.JsonRpcProvider(providerUrl); const wallet = new ethers.Wallet(privateKey, provider); const chamber = new Dhedge(wallet, Network.POLYGON); ``` The `Dhedge` client needs a wallet with a connected provider. A read-only provider is not enough for state-changing calls. ## Creating a vault ```ts const vault = await chamber.createPool( "Alice", // manager name (display) "My Vault", // vault name "MVLT", // token symbol [ // enabled assets: [address, isDepositAsset] [usdcAddress, true], [wethAddress, false], ], 10, // performance fee (percent, 0–50) 2, // management fee (percent/yr, 0–3) 0, // entry fee (percent, 0–2) 0, // exit fee (percent, 0–2) ); ``` See [create a vault](/manage/create-a-vault) for the manager-facing walkthrough of what these parameters mean. Fees are entered as percentages (e.g. `10` = 10%, matching the UI). Respect the [fee caps](/manage/fees-performance#fee-caps). There's no denomination parameter. Every Chamber vault accounts in USD. The `isDepositAsset` flag marks which enabled assets users can deposit; it doesn't set an accounting currency. See [denomination asset](/manage/denomination-asset). ## Loading an existing vault ```ts const vault = await chamber.loadPool(vaultAddress); ``` For non-Chamber contracts (other pools not created by the factory), pass a second argument: `loadPool(address, false)`. ## Core vault operations Every method returns either a sent transaction or, when you pass `sdkOptions`, the prepared calldata so you can sign externally. **Composition and state** ```ts await vault.getComposition(); // current holdings await vault.changeAssets([...]); // add/remove tradeable assets (manager only) await vault.setTrader(address); // delegate trading to another EOA (manager only) ``` A few manager-side contract functions don't yet have SDK wrappers, notably `setMaxSupplyCap` (deposit limit) and `setPoolLogic`. Use the contracts directly for those; the [Chamber app](https://chamberfi.com/) UI also exposes them. See [permissions & access](/manage/permissions-access) and [create a vault](/manage/create-a-vault). **Deposits and withdrawals** ```ts await vault.approveDeposit(usdcAddress, amount); await vault.deposit(usdcAddress, amount); await vault.withdraw(shareAmount); ``` `deposit` and `withdraw` wrap the vault's underlying `deposit` / `withdraw` calls. The SDK's `withdraw` returns a pro-rata slice of the vault's holdings. For withdrawals that involve complex assets (LPs, perps, lending positions), you currently need to call `withdrawSafe` on the contract directly with an encoded `ComplexAsset[]` argument. The SDK doesn't yet wrap this. See [Lockup & withdrawals](/deposit/lockup-withdrawals) for the underlying semantics. **Trading** ```ts await vault.trade(Dapp.ONE_INCH, fromAsset, toAsset, amountIn, slippagePercent); ``` The `Dapp` enum covers the aggregators, DEXes, and protocols the SDK wraps, currently including Uniswap V3, 1inch, Odos, KyberSwap, CoW Swap, Pendle, Aave (V2 and V3), Compound V3, Fluid (via the Compound V3 surface), Velodrome (V2 and CL), Aerodrome (and CL), PancakeSwap CL, Toros, and Hyperliquid. **Flat Money** has contract-level guards but isn't yet wrapped in the SDK. Trades on it go through the contracts directly. Each SDK route is composed into a guard-compliant call. Check `Dapp` in the installed version for the exact list, and the [Guard System](/build/guard-system) page for the full set of protocols Chamber allows at the contract level. **LP, lending, perps** * `addLiquidityUniswapV3`: concentrated liquidity mint (Uniswap V3, Velodrome CL, Aerodrome CL, Pancake CL) * `addLiquidityV2`: Velodrome V2, Aerodrome * `lend` / `withdrawDeposit` / `borrow` / `repay`: Aave V2 / V3 * `lendCompoundV3` / `withdrawCompoundV3` / `harvestCompoundV3Rewards`: Compound V3 and Fluid * `depositHyperliquid` / `perpToSpotHyperliquid` / `spotToPerpHyperliquid` / `withdrawHyperliquid`: Hyperliquid wallet/bridge ops * `openMarketOrderHyperliquid` / `closePositionHyperliquid`: Hyperliquid perps * `approveTorosLimitOrder` / `createTorosLimitOrder` / `modifyTorosLimitOrder` / `deleteTorosLimitOrder`: Toros stop-loss / take-profit * `mintUnitViaFlatMoney` / `redeemUnitViaFlatMoney` / `cancelOrderViaFlatMoney`: Flat Money Method surface and supported protocols move with releases. Check the SDK's exported types on the installed version. ## Getting calldata without sending Most methods take a trailing `sdkOptions` argument for dry-runs. On `trade` it's the **7th** argument. The 6th is a generic tx-`options` slot (gas overrides, etc.); pass `null` there if you don't need it: ```ts const txData = await vault.trade(Dapp.ODOS, fromAsset, toAsset, amountIn, 0.5, null, { estimateGas: true, onlyGetTxData: true, }); ``` Pass `onlyGetTxData: true` to return the encoded transaction rather than broadcasting it. This is how you'd integrate the SDK into a multisig flow, or hand the calldata to a user's wallet to sign. ## Version pinning * The SDK tracks the contracts repo's version tags. Pin to a minor version in production and test across upgrades. * Breaking changes to method signatures are documented in the repo's `CHANGELOG.md`. ## See also * [Contract addresses](/build/contract-addresses): underlying contracts the SDK calls * [Guard system](/build/guard-system): what the SDK's composed calls need to satisfy * [Integration examples](/build/integration-examples): end-to-end SDK flows # Subgraph GraphQL indexes for vault, manager, and transaction data Chamber's subgraphs are The Graph Protocol deployments that index vault state, deposits, withdrawals, trades, and manager activity. They are the primary source for analytics, dashboards, leaderboards, and any UI that needs to list or filter vaults. **Repo:** `dhedge-v2-subgraphs` ## When to use the subgraph * **List or search vaults:** by manager, denomination asset, chain, performance. * **Reconstruct vault history:** deposits, withdrawals, trades, fee events over time. * **Power a leaderboard or directory:** see [leaderboard & ranking](/concepts/leaderboard-ranking). * **Build portfolio views:** a depositor's positions across multiple vaults. For live state (current NAV, open positions), call the contracts directly or use the [SDK](/build/sdk). Subgraphs lag the chain by a few blocks. ## Chain coverage Separate subgraph deployments exist per chain: * Polygon * Optimism * Arbitrum * Base * Plasma * Ethereum * HyperEVM Each chain has its own GraphQL endpoint. There is no single cross-chain endpoint. Aggregate on the client side. **Endpoints:** Per-chain GraphQL URLs are maintained in the subgraph repo README. ## What gets indexed Full schema is in the subgraph repo's `schema.graphql`. The schema evolves with contract upgrades. Pin your integration to a specific subgraph version if you depend on exact field shapes. ## See also * [SDK](/build/sdk): for live onchain reads * [Leaderboard & ranking](/concepts/leaderboard-ranking): how the app uses this data * [Contract addresses](/build/contract-addresses): the contracts the subgraph indexes # Data API Hosted GraphQL API for vault discovery, token prices, and protocol-wide analytics Chamber runs a hosted GraphQL API that exposes vault-level and protocol-wide data. It's separate from the [subgraph](/build/subgraph), which runs per-chain Graph Protocol indexes. Use this API when you want a single cross-chain endpoint for vault lists, token prices, and aggregate analytics without running your own indexer. The endpoint is live, in production use (app backend, internal analytics), and introspection is enabled, so the full schema is self-describing. This page covers the common queries; use introspection (below) for the exhaustive list. ## Endpoint ``` POST https://api-v2.dhedge.org/graphql ``` * GraphQL over HTTPS, POST only * `Content-Type: application/json` * No authentication required. The endpoint is public. Rate limits may apply. ## Known queries Use [introspection](#schema-introspection) for the full list and field-level types. ### Example: list vaults on a chain **`allFundsByBlockchainCode(blockchainCode: String!)`** returns vaults on a given chain. Response fields include: `address`, `managerLogicAddress`, `name`, `managerName`, `totalValue` (wei-scale integer string, 18-decimal USD). ```bash curl -X POST https://api-v2.dhedge.org/graphql \ -H "Content-Type: application/json" \ -d '{"query":"{ allFundsByBlockchainCode(blockchainCode: \"POLYGON\") { address name managerName totalValue } }"}' ``` `blockchainCode` is an untyped string; confirmed working values include `POLYGON`, `OPTIMISM`, `ARBITRUM`, `BASE`, `MAINNET` (Ethereum), and `HYPEREVM`. The value is case-insensitive. Unrecognised codes may silently fall back to a default response rather than erroring, so validate the response before assuming a chain is wired in. ## Schema introspection To get the full list of available queries, run schema introspection: ```bash curl -X POST https://api-v2.dhedge.org/graphql \ -H "Content-Type: application/json" \ -d '{"query":"{__schema{queryType{fields{name description}}}}"}' ``` Introspection is enabled in production. This is the same API powering the Chamber app. For targeted schema exploration, a GraphQL client (GraphiQL, Insomnia, Apollo Sandbox) pointed at the endpoint gives you autocomplete and type info. ## When to use which | Need | Use | | ------------------------------------------------------------- | ------------------------------------------ | | List vaults across chains, single endpoint | Data API | | Deep per-chain indexed history (events, transfers, fee mints) | [Subgraph](/build/subgraph) | | Live vault state (current composition, NAV) | [SDK](/build/sdk) or direct contract calls | | Prepare a deposit/withdraw tx | [SDK](/build/sdk) or direct contract calls | The Data API is the lightest read surface and covers the most chains (including HyperEVM). Reach for the subgraph when you need event-level history or custom GraphQL joins beyond what's exposed here, and the SDK / direct contracts when you need authoritative onchain reads (e.g. per-block NAV). ## See also * [Subgraph](/build/subgraph): per-chain indexes via The Graph * [SDK](/build/sdk): live onchain reads # MCP server Local-first Model Context Protocol server for reading Chamber vault state from an AI client. The Chamber MCP server is a local-first [Model Context Protocol](https://modelcontextprotocol.io) server that lets an AI client (Claude Desktop, Cursor, Windsurf, Cline, VS Code, Gemini CLI, ChatGPT Desktop) **read Chamber vault state**: composition, holdings, NAV, open positions, and trade estimates. Use it to monitor and analyze a vault in natural language. It's a read-and-analysis surface, not an automation path. To automate trading (rebalancing on a schedule or a signal), build on the [SDK](/build/sdk) or call the contracts directly. Many teams pair the SDK with an LLM to help write and maintain that automation. **Package:** [`@dhedge/chamber-mcp`](https://www.npmjs.com/package/@dhedge/chamber-mcp) on npm. **Model:** local-first. There is no hosted server, no user account, no API key. Any keys used are AES-256 encrypted on your machine in `~/.chamber/vaults.json` and never leave it. > Package name and tool names remain `dhedge`/`chamber`-prefixed in code until those surfaces themselves rename. Prose rebrands; code identifiers don't. ## What it reads * Vault composition, holdings, metadata, NAV, and total value. * Open Toros and Hyperliquid positions and orders. * A dry-run estimate of a proposed trade (expected output and gas) without signing anything. ## Supported chains Polygon, Optimism, Arbitrum, Base, Ethereum, Plasma, Hyperliquid. See the [deployment matrix](/build/deployment-matrix) for the full network picture. ## Install and link a vault ```bash # Link a vault npx @dhedge/chamber-mcp vault link --address 0xYourVault --network arbitrum # List linked vaults npx @dhedge/chamber-mcp vault list # Remove a vault npx @dhedge/chamber-mcp vault unlink --address 0xYourVault --network arbitrum ``` ## Configure your MCP client Add the server to your MCP client config. For Claude Desktop: ```json { "mcpServers": { "chamber": { "command": "npx", "args": ["-y", "@dhedge/chamber-mcp", "mcp"] } } } ``` Launched as `mcp` with no `-s` flag, the server is **read-only**. The tools below are all it exposes. Cursor, Windsurf, Cline, VS Code, Gemini CLI, and ChatGPT Desktop accept the same command in their MCP settings. **Prerequisites:** an MCP client (e.g. [Claude Desktop](https://claude.ai/download)) and Node 18+ (`node --version`). **Using `nvm`?** Some clients launch `npx` without your shell environment, so it may not find `npx` or may resolve an old Node. Point `command` at the absolute npx path and pin `PATH`: ```json { "mcpServers": { "chamber": { "command": "/Users/YOU/.nvm/versions/node/v22.12.0/bin/npx", "args": ["-y", "@dhedge/chamber-mcp", "mcp"], "env": { "PATH": "/Users/YOU/.nvm/versions/node/v22.12.0/bin:/usr/local/bin:/usr/bin:/bin" } } } } ``` Find the path with `nvm which current`, then restart the client. Its tools indicator confirms the server loaded. ## Read-only tools | Tool | Purpose | | ------------------------------------- | ----------------------------------------- | | `chamber_list_linked_vaults` | Vaults linked on this machine | | `chamber_get_vault_info` | Name, manager, total value | | `chamber_get_composition` | Current holdings and balances | | `chamber_estimate_trade` | Dry-run a trade (gas and expected output) | | `chamber_get_toros_products` | Browse Toros leveraged token products | | `chamber_get_toros_deposit_assets` | Valid deposit assets for a Toros pool | | `chamber_toros_get_limit_order` | Read active limit order | | `chamber_toros_has_limit_order` | Check if a limit order exists | | `chamber_get_nft_manager_address` | NFT manager address for LP protocols | | `chamber_price_to_tick` | Convert price range to ticks for CL pools | | `chamber_hyperliquid_get_positions` | Perp + spot positions and PnL | | `chamber_hyperliquid_get_open_orders` | Unfilled Hyperliquid orders | ## Beyond read-only The package also ships trade-execution tools behind opt-in `-s` scopes (`-s trade` through `-s all`, see the [package README](https://www.npmjs.com/package/@dhedge/chamber-mcp) for the full flag list). They sign with a delegated [trader wallet](/manage/trader-delegation) and are bounded by the [Guard System](/security/guard-system). The server can never do anything a human trader couldn't. Two things keep this a secondary path rather than the automation story: * **Execution depends on the client.** The scope only *exposes* the tools; whether a trade actually runs is up to the client's assistant, and many decline to execute crypto trades, so in practice they stay read-only regardless of scope. A client or model that *will* sign can drive the full trade surface. * **For reliable automation, use the** [**SDK**](/build/sdk)**.** A headless bot executes deterministically; a chat assistant does not, and the trade tools wrap the same SDK, so anything a scope enables you can also do directly in code. Enable a trade scope only with a client you trust to transact on your vault's behalf. ## Configuration Everything lives under `~/.chamber/`: | File | Purpose | | ------------- | ----------------------------------------------------- | | `.env` | RPC URLs and aggregator API keys (loaded on startup) | | `.key` | Machine-local AES-256 encryption key (auto-generated) | | `vaults.json` | Encrypted keys for any linked vault | Common env vars: | Variable | Description | | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | `ARBITRUM_RPC_URL`, `BASE_RPC_URL`, `POLYGON_RPC_URL`, `OPTIMISM_RPC_URL`, `ETHEREUM_RPC_URL`, `HYPERLIQUID_RPC_URL` | Private RPCs per chain. Public RPCs are used as fallback. | | `ODOS_API_KEY` | Improves trade-estimate routing. Get one at [odos.xyz](https://odos.xyz). | ## Safety model * **Read-only default.** Launched with `mcp` and no `-s` flag, the server exposes only the read tools above. It cannot move funds. * **Local key storage.** Any keys are AES-256 encrypted with a machine-local key in `~/.chamber/` and never transit the agent, the network, or a hosted service. * **Guard System.** Any execution tools are bounded by the [Guard System](/security/guard-system). The server can't do anything a human trader couldn't. * **CLI-only linking.** Keys are entered at the terminal, never typed into the agent chat. ## See also * [SDK](/build/sdk): the automation and execution path (the layer MCP wraps) * [Trader delegation](/manage/trader-delegation): how the manager/trader permission split works * [Guard system](/security/guard-system): the rules every call is subject to # Integration examples End-to-end code samples for the most common Chamber integrations Minimal, runnable examples for the flows integrators hit most often. All SDK examples assume `@dhedge/v2-sdk` and `ethers` v5. Error handling is kept terse. Add production niceties (retries, user prompts, logging) in real code. ## Read a vault's current composition ```ts import { Dhedge, Network, ethers } from "@dhedge/v2-sdk"; const provider = new ethers.providers.JsonRpcProvider(RPC_URL); const chamber = new Dhedge(new ethers.Wallet(PK, provider), Network.POLYGON); const vault = await chamber.loadPool(VAULT_ADDRESS); const composition = await vault.getComposition(); console.log(composition); ``` For read-only analytics across many vaults, use the [subgraph](/build/subgraph) instead. It's faster and doesn't require an RPC per query. ## Deposit into a vault ```ts const vault = await chamber.loadPool(VAULT_ADDRESS); // ERC20 approve → deposit await vault.approveDeposit(USDC_ADDRESS, "1000000000"); // 1000 USDC (6 decimals) const tx = await vault.deposit(USDC_ADDRESS, "1000000000"); await tx.wait(); ``` The deposit asset must be enabled on the vault (manager-controlled). If it isn't, the call reverts with [`dh8`](https://github.com/dhedge/V2-Public/blob/master/readmes/errorCodes/dHEDGEV2ErrorCodes.json). All revert codes (`dh3`, `dh8`, etc.) are cataloged in the [V2-Public error codes JSON](https://github.com/dhedge/V2-Public/blob/master/readmes/errorCodes/dHEDGEV2ErrorCodes.json). That file is the source of truth and may change. See [deposit](/deposit/deposit) for the depositor-facing story, and [fees](/deposit/fees) for how entry fees are settled (in shares, not the deposit asset). ## Withdraw Simple withdrawal (assets fit the basic ERC20 path): ```ts const tx = await vault.withdraw(SHARE_AMOUNT); await tx.wait(); ``` If the vault holds complex assets (LPs, perps, lending positions), the SDK's `withdraw()` may not cleanly unwind them. For those vaults, call the contract's `withdrawSafe(shareAmount, complexAssets[])` directly via an ethers `Contract` instance. Each entry tells the asset guard how to unwind. The SDK doesn't currently wrap this. Note that the depositor's lockup cooldown must have elapsed, or the call reverts with [`dh3`](https://github.com/dhedge/V2-Public/blob/master/readmes/errorCodes/dHEDGEV2ErrorCodes.json). See [lockup & withdrawals](/deposit/lockup-withdrawals). ## Create a vault ```ts const vault = await chamber.createPool( "Mat Finance", // manager name (display name on vault page) "Conservative USD", // vault name "CUSD", // vault share token symbol [ [USDC_ADDRESS, true], // USDC as deposit asset [WETH_ADDRESS, false],// WETH tradeable but not depositable [WBTC_ADDRESS, false], ], 10, // performance fee (numerator, e.g. 10 = 10%) 0, // management fee 0, // entry fee 0, // exit fee ); console.log("new vault:", vault.address); ``` For a walkthrough of the product decisions behind each parameter (denomination asset, fee structure, lockup), see [create a vault](/manage/create-a-vault). ## Execute a trade ```ts import { Dapp } from "@dhedge/v2-sdk"; const tx = await vault.trade( Dapp.ODOS, // aggregator USDC_ADDRESS, // from WETH_ADDRESS, // to "1000000000", // 1000 USDC 0.5, // 0.5% max slippage ); await tx.wait(); ``` Only the manager or delegated trader can execute trades. The aggregator routes must compose into a guard-compliant call. If the destination contract isn't guarded, the transaction reverts with `dh23`. ## Prepare calldata without sending Useful for multisig flows, or handing the tx to a user's wallet to sign: ```ts const txData = await vault.trade( Dapp.ODOS, USDC_ADDRESS, WETH_ADDRESS, "1000000000", 0.5, null, // no extra options { onlyGetTxData: true }, // return prepared tx, don't send ); // txData = { txData, to, minAmountOut } — pass to your signer of choice ``` ## Check if a protocol is supported Before building a call, verify the guard exists: ```ts import { Contract } from "ethers"; const factory = new Contract(FACTORY_ADDRESS, FACTORY_ABI, provider); const guard = await factory.getContractGuard(TARGET_PROTOCOL); if (guard === ethers.constants.AddressZero) { throw new Error("protocol not supported on this chain"); } ``` See [guard system](/build/guard-system) for the full enumeration surface. ## Query the subgraph ```ts const res = await fetch(SUBGRAPH_URL, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ query: `{ pools(first: 20, orderBy: totalSupply, orderDirection: desc) { id fundAddress name manager managerName totalSupply tokenPrice } }`, }), }); const { data } = await res.json(); ``` See [subgraph](/build/subgraph) for schema and per-chain endpoints. ## Set a trader A manager delegates day-to-day trading to a second EOA (hot wallet, bot, or agent): ```ts const vault = await chamber.loadPool(VAULT_ADDRESS); const tx = await vault.setTrader(TRADER_ADDRESS); await tx.wait(); ``` The trader can execute trades and change vault assets (default ON) but cannot change fees or the trader address itself. See [trader delegation](/manage/trader-delegation) for the full permission split. ## See also * [SDK](/build/sdk): full method surface * [Guard system](/build/guard-system): what makes a call succeed or fail * [MCP server](/build/mcp-server): read vault state from an AI client # Vaults as guardrails A Chamber vault is not a wrapper around a manager's wallet. It's a set of onchain rules that bind what any manager, human or bot, can do with deposited funds. Most people picture a "vault" as a container: somewhere funds go to sit safely. In Chamber, the container framing misses the point. A Chamber vault is a **constraint system**. It's a set of rules, encoded in smart contracts, that define what the person or bot running the vault can and cannot do with the money inside. The funds aren't "in" the vault the way money is in a safe. They're *subject* to the vault, bounded by what the vault's rules will let happen to them. ## Why this framing matters Onchain asset management historically offered two options, both bad: * **Custodial.** Hand money to a manager or platform and hope they do right by you. * **Permissionless trading bots.** Give a script full control over your wallet and hope the script is bug-free. Chamber vaults are a third option: the manager has broad operational freedom *within rules nobody can override*. The rules are: * **Which assets can be held.** A manager can't suddenly route the vault into random tokens. Only the vault's [enabled assets](/manage/permissions-access) are allowed. * **Which protocols can be used.** Only the protocols on Chamber's allowlist (Aave, Uniswap, Toros, etc.), never arbitrary contracts. * **What fees can be charged.** Performance, management, entry, and exit fees are capped, and increases require a [14-day announcement](/manage/fees-performance). * **Who can move funds.** Depositors control their own shares. The manager controls trading only. They cannot withdraw depositor funds. Most of these are enforced by the [Guard System](/security/guard-system) at the contract level: every trade the manager submits is checked against the vault's enabled assets and the protocol allowlist, and anything that violates them reverts before it can touch vault funds. Fee caps and the 14-day announcement work slightly differently (they're enforced at the point the manager tries to change fees, not on every trade), but the effect is the same: the manager can't "promise" to follow the rules and then break them. The contract literally won't let them. ## The implication for automated trading This is the reason Chamber can safely host bots and automated strategies. A bot operating on the vault has exactly the same surface area as a human manager: the same enabled assets, the same protocol allowlist, the same fee caps. It cannot do more, cannot do worse, cannot route around the rules. You don't have to trust the automation more than you'd trust a human. You trust the rules, which are the same for both. ## What guardrails don't protect against The vault constrains *what the manager can do with the money*. It does not constrain *whether their decisions are good*. A manager operating entirely within the rules can still: * Lose money on bad trades. * Hold concentrated positions that drop. * Accrue management fees while the vault underperforms. * Run a strategy that simply doesn't work. Guardrails bound the downside caused by malice or bug; they do not bound the downside caused by ordinary market risk or poor judgment. See [Deposit → Risks](/deposit/risks) for the fuller picture. ## A useful mental model Think of a Chamber vault the way you'd think of a managed account at a broker with pre-agreed rules: * The broker can trade within a stated mandate. * They can't move your money to their own account. * They can't change the mandate without notice. * You can withdraw any time. The difference is that Chamber's "broker" is the onchain contract, not a legal entity or a trust relationship. The rules are executable code, and breaking them is impossible rather than punishable. ## Related * [Guard System](/security/guard-system): the technical enforcement layer. * [Permissions & access](/manage/permissions-access): how asset whitelists work. * [Vault tokens & mechanics](/concepts/vault-tokens): what a vault share is, onchain. * [NAV & accounting](/concepts/nav-accounting): how the value of a share is calculated. # Vault tokens & mechanics Vault shares are ERC-20 tokens. Minted on deposit, burned on withdrawal, priced against the vault's NAV. Every Chamber vault issues its own ERC-20 token: the **vault share**, sometimes called the vault token or receipt token. Depositors receive vault shares when they deposit and burn them when they withdraw. The share's value at any point is the vault's NAV divided by the total supply of shares. ## The basics * **ERC-20.** Vault shares are standard ERC-20 tokens. They show up in your wallet, transfer like any other token, and can (in principle) be held in any ERC-20-compatible contract. * **Vault-specific name and symbol.** Both are set by the manager at [vault creation](/manage/create-a-vault) (e.g. `ETHBULL`, `STABLE-YIELD`) and are onchain-immutable: they can't be changed after the vault is deployed. * **Vault-specific contract.** Each vault has its own share contract, tied one-to-one with its vault contract. * **Share claim on the whole vault.** One share represents a proportional claim on everything the vault holds, valued in USD. ## Mint and burn ### Deposit → mint When you deposit, the vault: 1. Accepts your deposit asset. 2. Calculates your deposit's USD value using the [oracle layer](/concepts/oracles). 3. Mints vault shares proportional to the value you added, relative to the vault's current NAV and total supply. 4. If the vault charges an entry fee, a portion of the newly minted shares is routed to the manager and protocol instead of the depositor. You receive the remainder. If the vault has $1,000,000 NAV and 1,000,000 shares outstanding (so one share = $1), a $10,000 deposit mints \~10,000 new shares. With a 0.5% entry fee, the depositor receives \~9,950 shares and \~50 shares are minted to the manager/protocol. ### Withdrawal → burn When you withdraw, the vault: 1. If an exit fee applies, a portion of your shares is routed to the manager/protocol before redemption. 2. Burns your remaining shares. 3. Calculates your pro-rata slice of the vault's holdings from the burned shares. 4. Returns assets to you, either as a single asset or as the underlying basket. See [Lockup & withdrawals](/deposit/lockup-withdrawals). Total supply shrinks. The NAV shrinks proportionally. The price per share stays roughly unchanged (before fees). Everyone else's position is unaffected by one person withdrawing. ## The 24-hour lockup Each deposit starts a lockup of **up to 24 hours**, during which the freshly minted shares can't be withdrawn or transferred. * The lockup is **weighted-average** across deposits, not flat-per-deposit. A top-up deposit extends the blended remaining lockup on your full position. It doesn't start a fresh 24-hour clock only on the new shares while leaving existing shares unlocked. * The purpose is flash-loan and same-block manipulation protection. * Normal holders rarely notice it. See [Deposit → Lockup & withdrawals](/deposit/lockup-withdrawals) for detail. ## Share price ≠ "up only" Your share count usually stays roughly constant (give or take fee accruals). The **price** of each share moves with the vault's NAV: * Vault gains value → share price up. * Vault loses value → share price down. * Manager earns management fee → new shares minted to the manager address → your share **count** stays the same, but your **percentage of total supply** shrinks slightly over time. (The share price view already accounts for this. You see the real economic effect in your share value.) * Performance fee accrual works the same way: new shares are minted to the manager when the vault crosses its high-water mark. ## Transferring vault shares Because vault shares are ERC-20, you can transfer them. Useful for: * Gifting a position to another wallet. * Moving from a hot wallet to a hardware wallet without withdrawing and re-depositing. * Sending shares as settlement in OTC deals. A few things to know: * If the lockup is still active, your shares can't be transferred at all, not to another wallet, not to a contract. Transfers only become possible once the lockup has elapsed. * Transferring shares doesn't realize any gains. The new holder picks up the position at its current cost basis from their perspective. * For [private vaults](/manage/permissions-access), transferring shares doesn't grant deposit rights. A recipient who isn't on the manager's whitelist can hold and withdraw the shares but can't deposit new funds. ## Related * [NAV & accounting](/concepts/nav-accounting): how share price is calculated. * [Oracles](/concepts/oracles): how the underlying positions are priced. * [Deposit → Lockup & withdrawals](/deposit/lockup-withdrawals): the depositor-side view. * [Fees & performance](/manage/fees-performance): how fee accrual mints shares to the manager. # NAV & accounting How Chamber values its vaults. Positions priced via oracles, summed in USD, divided by total shares outstanding. **NAV** (net asset value) is the total USD value of everything a vault holds. The **share price** is NAV divided by the total supply of [vault shares](/concepts/vault-tokens). Every time NAV changes, share price changes; every time shares are minted or burned, they're minted or burned at the current share price. ## How NAV is calculated Canonically, NAV is **the vault's assets minus its liabilities**, and share price is NAV divided by total shares outstanding. In practice, Chamber's vaults mostly hold spot assets and yield positions. Liabilities only matter on leveraged vaults (Aave, Compound, MAI, etc.) where the vault has borrowed against collateral. In those cases the asset guard for that position reports **net** value (collateral − debt), so NAV always reflects real ownership. The contract evaluates NAV by: 1. **Enumerate holdings.** Every asset and position the vault holds, across every protocol it's integrated with. 2. **Price each holding in USD.** Using the [oracle layer](/concepts/oracles): Chainlink, Pyth, and TWAP feeds, selected per asset at the protocol level. Leveraged positions are priced net of debt inside their asset guard. 3. **Sum.** The total is the vault's NAV. 4. **Accrued manager fees mint as shares.** Performance and management fees accrued since the last mint are realized on the next deposit, withdrawal, or manual trigger. New shares go to the manager and the Chamber protocol. NAV itself is unchanged by this; share price takes the hit via dilution. All of this happens onchain. No off-chain accounting; no manual valuation. The contract reads from oracles and protocol adaptors, sums, reports. ## How share price is calculated ``` share price = NAV / total supply of shares ``` At launch, vaults typically start with a 1:1 ratio of USD per share (e.g. the first depositor of $10,000 receives 10,000 shares at $1 each). As the vault gains or loses value, NAV changes while share count stays fixed, so share price moves. The ratio depositors see is the share's real economic value at that moment, priced in USD. ## What affects NAV * **Manager trades.** Swaps, LP entries, lending deposits, leveraged positions. Every trade changes what the vault holds, and NAV reflects the new holdings at current prices. * **Price movements.** Even with no trading, NAV moves as the value of held assets changes. A vault 100% in ETH fluctuates with the ETH price. * **Yield accrual.** Lending positions (Aave, Compound) and yield-bearing tokens (staked assets, Pendle positions) earn yield continuously. NAV rises as yield accrues. * **Fee accrual.** The amounts owed for management and performance fees scale per second (mgmt) and with share-price growth above the HWM (perf). The contract can compute them at any moment. Shares are actually minted on the next deposit, withdrawal, or manual trigger. When they mint, total share count rises and each existing share represents a slightly smaller slice of the same NAV. The fee is paid via socialized dilution, not a NAV deduction. * **Deposits and withdrawals.** NAV rises on deposit, falls on withdrawal. Share count rises or falls in matching proportion, so share price stays roughly constant through the deposit/withdraw itself. ## What depositors see On your vault page: * **Share balance.** How many shares you own. Usually flat, only changes on deposit or withdrawal. * **USD value.** Your share balance × current share price. Rises and falls with the vault. * **Performance chart.** NAV over time (or share price over time, depending on view). Tells you how the vault has done, not your specific entry. * **Your unrealized P\&L.** (USD value now) − (deposit cost basis). Visible in the app. ## Why NAV might seem to "jump" Most of the time NAV updates smoothly. Three things can cause visible jumps: * **An oracle price update on a large holding.** If ETH moves 2% in a block and the vault is 50% in ETH, NAV jumps \~1% when the oracle updates. * **A new position being entered or exited.** Gas costs, slippage, and swap fees create a small, real loss on every trade. Busy managers will show many small dips; quieter vaults show fewer, larger steps. * **Fee accrual crystallising.** Performance fees mint in chunks when the vault crosses a high-water mark. The mint shows up as a small downward nudge in share price (more shares, same NAV), but it's just the fee being taken, not a loss. If you see a large unexplained move, check [trading history](/deposit/find-a-vault#the-vault-page) on the vault page. Every position change is onchain and visible. ## Related * [Oracles](/concepts/oracles): the source of prices used in NAV calculation. * [Vault tokens & mechanics](/concepts/vault-tokens): how shares mint, burn, and transfer. * [Denomination asset](/manage/denomination-asset): why USD and not something else. * [Fees & performance](/manage/fees-performance): how fee accrual affects share price. # Oracles How Chamber prices vault holdings Every USD value Chamber reports (vault NAV, share price, deposit size, performance-fee threshold) comes from an oracle. Chamber uses a mix of **Chainlink**, **Pyth**, and **TWAP** (time-weighted average price) feeds, chosen per asset at the protocol level. Chamber does not run its own price feeds; it reads established third-party oracles. ## Feed types * **Chainlink**: the default for blue-chip assets and standard USD pairs. * **Pyth**: used where Chainlink doesn't have coverage, or where a different update profile suits the asset. * **TWAP**: time-weighted average price derived onchain from trading activity on supported venues. Used for assets without a reliable Chainlink or Pyth feed. Each supported asset has its feed configured at the **protocol level**, not by individual vault managers. Every vault holding asset X on chain Y uses the same feed. ## Oracle risk Oracles are external dependencies. The main risks: * **Staleness**: a feed stops updating. Chamber contracts check staleness thresholds and revert rather than operate on stale prices. Deposits, withdrawals, and trades involving the affected asset will fail until the feed recovers. * **Manipulation**: theoretically possible on illiquid pairs. TWAP feeds resist single-block manipulation by averaging over a time window. Feed selection favors assets with deep liquidity. ## Related * [NAV and accounting](/concepts/nav-accounting): how oracle prices feed into NAV * [Denomination asset](/manage/denomination-asset): why Chamber reports everything in USD * [Risks](/deposit/risks): depositor-side view of oracle risk # Supported assets & protocols What assets and DeFi protocols Chamber vaults can interact with. Per-chain capability with protocol-level allowlisting. A Chamber vault can only hold assets and interact with protocols that are on the **protocol-wide allowlist**. Managers pick from this allowlist at [vault creation](/manage/create-a-vault); the [Guard System](/security/guard-system) enforces the allowlist onchain at every trade. This page explains the shape of the allowlist and how it evolves. ## One vault, many asset classes A single Chamber vault can hold **crypto, tokenized equities, commodities, and stablecoins together**. A manager isn't boxed into one asset class. Tokenized US stocks and ETFs (via Ondo Stocks) sit alongside spot crypto, gold, lending positions, and leverage, all under the same Guard System rules and priced by the same [oracle layer](/concepts/oracles). This is what makes a cross-asset strategy (say, long tech equities hedged with a leveraged crypto short and idle cash earning lending yield) expressible in one onchain vault rather than spread across several venues. Because a vault packages many assets into a single tokenized strategy, a Chamber vault can be a **private portfolio**, a **public strategy**, or a **thematic basket**: AI chips, AI compute, quantum computing, peptide medicines, broad-market ETFs, or a commodities sleeve. The manager builds and maintains it, and chooses whether to keep it private or open it to depositors through one [vault token](/concepts/vault-tokens): managers get a wider asset set to build with, depositors get a simpler way to access the strategy. Ondo Stocks tokens trade against public-market liquidity, so spreads stay tight enough to build and rebalance without heavy trading costs. Tokenized equities and RWAs are currently an **Ethereum** feature; the rest of the categories below vary by chain (see [Chain capabilities](/manage/chain-capabilities)). ## Two allowlists, not one There are two layers: * **Protocol allowlist.** The set of smart contracts (DEXes, lending markets, yield venues) Chamber's Guard System allows any vault to interact with. Protocol-wide and updated by Chamber. * **Vault's enabled assets.** The set of tokens and position types a single vault has turned on. Each vault enables up to **12 assets** at once, chosen from the protocol-wide asset list. A trade has to pass **both**: the target protocol must be allowlisted at the protocol level, and the assets involved must be on the vault's own [enabled assets](/manage/permissions-access). ## Supported categories The allowlist is organized by what kind of position the asset represents: | Category | What it is | Example assets / positions | | ---------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------- | | **Crypto** | Spot ERC-20 tokens | WETH, WBTC, ARB, OP, POL | | **Tokenized equities & RWA** | Tokenized stocks & ETFs (Ondo Stocks, Ethereum) | SPYon, NVDAon, MSTRon, COINon, TQQQon, … | | **Commodities** | Tokenized commodity exposure | Gold, silver, oil, gas via Ondo (GLDon, SLVon, USOon…); XAUt; Toros GOLDBULL | | **Stablecoins** | Fiat-backed or overcollateralised stables | USDC, USDT, DAI | | **Lending** | Lending-market deposit positions | aTokens (Aave), cTokens (Compound) | | **Leverage** | Leveraged spot tokens | Toros leveraged tokens (e.g. ETHBULL3X) | | **Liquidity provision** | LP positions on allowed DEXes | Uniswap v3 LP NFTs, PancakeSwap CL positions | | **Yield** | Yield-bearing positions | Pendle tokens, staked assets | | **Perps (HyperEVM only)** | Perpetual futures | Via Hyperliquid on HyperEVM | Which categories are available depends on the chain. See [Chain capabilities](/manage/chain-capabilities) for the per-chain matrix. The Ondo tokenized-asset set on Ethereum is large and grows over time. The asset selector in the [Chamber app](https://chamberfi.com/) is the live source of truth for exactly what's enabled. The examples above are illustrative, not exhaustive. > **Access.** Vaults that hold Ondo Stocks tokens are subject to eligibility, offering, and regional access rules, and may not be available in all locations. The tokens provide economic exposure to the underlying asset under Ondo's terms. See [Risks](/deposit/risks). ## How assets and protocols get onto the allowlist Not every protocol or asset can be added. The Chamber team (and, via governance, the DAO) evaluates candidates against a rough set of criteria: * **Security.** Established code, multiple audits, production track record. * **Liquidity.** Enough market depth that the asset can be priced and traded without outsized slippage. * **Oracle coverage.** A reliable [oracle feed](/concepts/oracles) exists (Chainlink, Pyth, TWAP, or, for tokenized RWAs, Ondo's attestation oracle). * **Fit.** The asset or protocol solves a real strategy need that isn't already covered. Additions happen iteratively. The list grows more than it shrinks, but nothing is permanent. A protocol can be removed from the allowlist if it's compromised, deprecated, or no longer safe. ## Wrapped vs native Some tokens are only available in wrapped form: * **ETH.** Vaults hold **WETH**, not native ETH. Deposits and withdrawals of ETH are wrapped/unwrapped at the edges. * **BTC.** Vaults hold **WBTC** (or the chain-equivalent wrapped BTC). Chamber has no native-BTC integration. * **Gas tokens.** POL on Polygon, ETH on Arbitrum, etc. The app handles the wrap for you. This is a smart-contract constraint: ERC-20 is the standard Chamber's contracts speak. Native gas tokens aren't ERC-20. ## What's not supported * **Arbitrary ERC-20s.** You can't enable a random memecoin via the app. If it's not on the allowlist, it's not available. * **Arbitrary NFTs.** Vaults can't hold random NFTs as positions. The exceptions are integration-specific NFT positions (Uniswap v3 LPs and similar), which are held directly and priced/unwound by their dedicated [asset guards](/security/guard-system). * **Assets on unsupported chains.** Each vault lives on one chain. If you want exposure on another chain, create (or deposit to) a vault on that chain. ## Related * [Chain capabilities](/manage/chain-capabilities): per-chain support matrix. * [Permissions & access](/manage/permissions-access): how managers set their vault's enabled assets. * [Trading](/manage/trading): what categories and protocols look like in the trade UI. * [Guard System](/security/guard-system): how the allowlist is enforced. # Leaderboard & ranking How Chamber ranks vaults. Vault Score and Risk Factor: what they measure, how they're calculated, and what they don't tell you. Chamber's leaderboard helps depositors compare vaults at a glance. Two metrics do most of the work: **Vault Score** (an ordered performance summary) and **Risk Factor** (a 1–5 downside-volatility rating). Both are backward-looking. Neither predicts future returns. ## Vault Score A single number combining risk-adjusted performance and vault size. ``` Vault Score = Sortino ratio × √(7-day average vault value) ``` Two components: * **Sortino ratio.** A common risk-adjusted return metric: excess return divided by downside deviation. Rewards steady upward performance and penalises downside volatility. Unlike the Sharpe ratio, it ignores upside volatility (because upside volatility is what depositors want). * **√(7-day average vault value).** A size term. Rewards vaults that have actually deployed meaningful capital. ### Why the size term Without the size term, a vault with $100 AUM that got lucky could top the leaderboard. That wouldn't be useful information. The `√(value)` term means: * Size matters, but with diminishing returns: a $10M vault doesn't score 100× a $100k vault; it scores \~10× (all else equal). * A new vault with no meaningful capital scores low even if early performance is good. It has to get capital to get credit. ### Eligibility Not every vault is eligible for a Vault Score. Vaults typically need a minimum track record (in days) and some minimum level of performance before they're ranked. Exact thresholds are set in the app, not onchain, and can change. Check the in-app leaderboard filters for current eligibility rules. ### What Vault Score doesn't capture * **Strategy difficulty.** A stablecoin yield vault and a leveraged ETH vault are scored by the same formula despite being very different products. Both should be evaluated on their own terms. * **Forward returns.** Past Sortino doesn't predict future Sortino. * **Manager changes.** If a vault changes strategy or manager, the score takes weeks to catch up. * **Correlation.** Two vaults with high Vault Scores may hold correlated positions; holding both doesn't diversify you as much as you'd think. ## Risk Factor A 1–5 rating based on **downside deviation**: how much the vault's share price has moved down historically. * **1**: historically low downside volatility. Stablecoin strategies, tight spreads. * **2**: low. Steady yield, diversified exposure. * **3**: moderate. Typical managed crypto strategy. * **4**: high. Concentrated positions, directional bets. * **5**: very high. Leveraged tokens, thinly-traded assets, aggressive strategies. Risk Factor is useful as a **first-pass filter**: if you want something that won't move much, look for 1s and 2s. If you want aggressive alpha, you'll find it at 4s and 5s. ### What Risk Factor doesn't capture * **Tail risk.** A strategy that's stable 99% of the time and catastrophic 1% of the time can show a low Risk Factor despite carrying high real risk. * **Strategy changes.** If a manager pivots to a riskier approach, Risk Factor lags. * **Smart-contract risk.** Contract-level risks (bugs, exploits) don't move with vault share prices and aren't in Risk Factor. See [Deposit → Risks](/deposit/risks) for the full risk picture. ## The leaderboard UI The Chamber app leaderboard lets you: * Filter by **chain**. * Filter by **category** (managed, automated, etc.: a label managers set in vault settings). * Sort by **Vault Score**, AUM, age, or fees. * Filter by **Risk Factor**. ## How to read the leaderboard A few sensible rules of thumb: 1. **Filter by your risk tolerance first.** Don't sort by top Vault Score across the whole board. High scores at Risk Factor 5 are not the same product as high scores at Risk Factor 1. 2. **Filter by track-record length.** Vaults less than a few months old have noisy Vault Scores. Require at least 2–3 months of history for a signal you can rely on. 3. **Don't treat the leaderboard as a recommendation.** It's a sortable directory, not a buy list. Read the vault page before depositing. ## Related * [Deposit → Find a vault](/deposit/find-a-vault): depositor's workflow for browsing. * [NAV and accounting](/concepts/nav-accounting): what share price movements (which Risk Factor reads from) actually represent. * [Risks](/deposit/risks): the fuller risk framing. # Overview Chamber and its sibling brands: Toros, mStable, Flat Money Chamber is the parent brand. A few sibling brands run alongside it: same team, shared resources, shared fees and revenue. They exist as distinct products because each serves a different audience or strategy type, not because they're separate businesses. ## Sibling brands * [**Toros Finance**](/ecosystem/toros-finance): leveraged tokens and options tokens. Largest fee contributor across the group. * [**mStable**](/ecosystem/mstable): yield product, currently a single Pendle-sUSDe vault on Ethereum. * [**Flat Money**](/ecosystem/flat-money): perpetual options contract layer. Currently used internally by Toros for options strategies; no standalone end-user surface right now. ## How they relate to Chamber Each brand is built on the Chamber vault stack: same contracts, same Guard System, same oracle infrastructure, same DAO treasury. Fees generated by any brand flow to the same Chamber DAO treasury under the same 10% split (see [DAO protocol fees](/treasury-and-protocol-economics/dao-protocol-fees)). Practically: a vault on Toros is a Chamber vault with a Toros front-end on top. The audits, incident history, and onchain transparency that apply to Chamber apply to all of them. ## What lives where | Brand | URL | Status | | ------------- | -------------------------------------- | ------------------------- | | Chamber | [chamberfi.com](https://chamberfi.com) | Live | | Toros Finance | [toros.finance](https://toros.finance) | Live | | mStable | [mstable.org](https://mstable.org) | Live (single vault) | | Flat Money | — | V2 in flux; V1 deprecated | Each product has its own docs for strategy-specific detail; this section gives the one-paragraph version and a pointer. # Toros Finance Chamber's tokenized-strategy sibling brand Toros is a Chamber sibling brand that packages automated strategies into ERC-20 tokens. Each Toros token is, under the hood, a Chamber vault running a specific strategy. You hold the token, you get the strategy's exposure. Tokens can be held in any compatible wallet. * Site: [toros.finance](https://toros.finance) * Docs: [docs.toros.finance](https://docs.toros.finance) ## Product lines * **Leveraged tokens**: amplified exposure to crypto and real-world assets. Long and short variants, 1x through 4x leverage, with automated rebalancing. * **1x tokens**: synthetic spot exposure to assets that are otherwise hard to access on a given chain (e.g. SOL, DOGE, XRP on Arbitrum), implemented via perpetual futures. * **Options strategies**: automated options products built on Toros Perpetual Options, including covered-call income strategies and protected leveraged tokens. * **Yield vaults**: automated yield strategies across DeFi lending and liquidity pools. * **Index strategies**: thematic baskets of tokenized equities from Ondo Stocks, each accessible through a single Toros token on Ethereum. See the [Toros docs](https://docs.toros.finance) for the full catalog, available networks, and product-specific behavior. ## Ondo-powered index strategies Toros packages tokenized equities from [Ondo Stocks](/concepts/supported-assets) into thematic index strategies, each accessible through a single Toros token on Ethereum. Ondo provides the tokenized equities, Chamber provides the vault layer, and Toros packages them into strategies you can access in one place. The launch set is four public-market themes: * **CHIP: The Semiconductor Stack.** AI silicon: concentrated exposure to chokepoint companies behind leading-edge AI compute (GPUs, foundries, EUV lithography, networking, and memory). Basket includes NVDAon, TSMon, ASMLon, AVGOon, AMDon, MUon. * **PEPT: The Peptide Stack.** GLP-1 and peptide medicines across the value chain (drug makers, delivery channels, manufacturing support, and related health infrastructure). Basket includes LLYon, HIMSon, MRKon, NVOon, AMGNon. * **NEO: The Neocloud Stack.** AI compute capacity: the cloud platforms, data centers, and power infrastructure those chips need. Basket includes NBISon, CRWVon, APLDon, IRENon, WULFon, CIFRon. * **QNTM: The Quantum Stack.** Equal-weight exposure to listed quantum-computing pure-plays across trapped-ion, superconducting, annealing, and photonic approaches. Basket includes IONQon, RGTIon, QBTSon, QUBTon. The four sit across different levels of risk and maturity: CHIP the most established, QNTM the most speculative. > **Access and risk.** Strategies that hold Ondo Stocks tokens are subject to regional access rules and may not be available in all locations. They can lose value: each stack carries the market risks of the assets it holds, plus risks linked to tokenized assets and onchain vaults. ## Relationship to Chamber Toros vaults are Chamber vaults. Same [Guard System](/security/guard-system), same [audit history](/security/audits), same oracle stack. Fees paid on Toros vaults contribute to the Chamber DAO treasury under the standard [10% split](/treasury-and-protocol-economics/dao-protocol-fees), and Toros is currently the largest single contributor of fee revenue to that treasury. The front-end and strategy library are Toros-branded; the vault infrastructure is Chamber. ## For depositors Deposit into a Toros token from the Toros app, no separate account. Tokens are ERC-20, transferable and composable into other DeFi positions. The [post-deposit lockup](/deposit/lockup-withdrawals) (up to 24 hours, weighted across deposits) that applies to Chamber vaults applies to Toros tokens too. ## See also * [Toros docs](https://docs.toros.finance): strategy-by-strategy detail * [Flat Money](/ecosystem/flat-money): perpetual options contract layer Toros uses for options strategies # mStable Chamber's yield-focused sibling brand mStable is a Chamber sibling brand focused on stablecoin yield. It previously ran a broader product suite; the current live product is a **single Pendle-sUSDe vault on Ethereum**. Check [mstable.org](https://mstable.org) for the current APY. * Site: [mstable.org](https://mstable.org) ## What it is now One vault, on Ethereum, allocating deposits to a Pendle sUSDe strategy. The goal is straightforward: a clean, single-purpose yield product for depositors who want stablecoin exposure with a higher return than plain lending. Like all Chamber vaults, it runs on the same contracts, uses the same [Guard System](/security/guard-system), and contributes fees to the same [DAO treasury](/treasury-and-protocol-economics/overview) under the standard 10% split. ## How to deposit Through mstable.org, or directly via the vault's page in the Chamber app. Vault shares are ERC-20; the [post-deposit lockup](/deposit/lockup-withdrawals) (up to 24 hours, weighted across deposits) and withdrawal mechanics work the same as any other Chamber vault. ## Legacy Older mStable products (mUSD, MTA staking, etc.) are outside the scope of this doc. The current product is the single vault above. # Flat Money Chamber's perpetual options contract layer Flat Money is a Chamber sibling brand. In its current form (v2), it's a **perpetual options contract layer** on Arbitrum that [Toros](/ecosystem/toros-finance) uses as the underlying mechanism for its options strategies. There's no standalone end-user front-end right now. Flat Money sits as infrastructure; depositors interact with it indirectly by holding Toros options tokens. ## Status * **v1: deprecated.** The original Flat Money product (flatcoin / UNIT) is wound down. * **v2: live.** Perpetual options contracts on Arbitrum, used internally by Toros. The standalone product direction is in flux. This page will be rewritten if and when a direct end-user product ships. ## Relationship to Chamber Same team, same treasury, same [10% DAO fee split](/treasury-and-protocol-economics/dao-protocol-fees) on anything that earns fees through the stack. See [Ecosystem overview](/ecosystem/overview) for how the sibling brands fit together. # 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](/security/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](/security/audits) for the full timeline. ## Bug bounty Chamber runs a live bug bounty through [Immunefi](https://immunefi.com/) with payouts up to $50,000 for critical-level vulnerabilities. The program covers core contracts and active integrations. See [Bug bounty](/security/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](/security/risk-model) for the categories Chamber actively reduces vs. those that remain with the depositor, and [Deposit: risks](/deposit/risks) for the depositor-facing view. ## Incident history No loss of depositor funds since launch in October 2020. See [Incident history](/security/incident-history). # Audits Full audit history of the Chamber (formerly dHEDGE) contracts Chamber contracts have been audited by leading security firms since 2020, including **Obsidian**, **Sherlock**, **Santipu**, **iosiro**, **CertiK**, and **Trust Security**. Audits cover both core vault contracts and integrations with protocols such as Aave, Pendle, GMX, Synthetix V3, Ethena, and Hyperliquid. The most recent audits are listed first. The list below covers both **V2 (current)** and earlier **V1 (legacy)** contracts. Recent audits focus on V2, which is the active codebase today. Auditing is an ongoing process. New audits are commissioned alongside major upgrades and new integrations, and the list below is updated as they complete. *** ### 2026 * [**Obsidian** (Mar 2026)](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ff03kK69OTEEthfwi6VoC%2Fuploads%2FcMDxDvDnQyLaTQp0J9T3%2FHyperliquid%20Integration%20.pdf?alt=media\&token=54dde521-a02e-47ea-9562-e3a22db0e4fe): V2 Hyperliquid integration contracts, including HIP-3 trading update. ### 2025 * [**Sherlock** (Sep 2025)](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ff03kK69OTEEthfwi6VoC%2Fuploads%2FoacAphKLdPdHKiU9sPIw%2FSherlock%20Audit%20%E2%80%93%20mStable%20Pendled%20sUSDe%20\(via%20dHEDGE\).pdf?alt=media\&token=b53f3638-0019-48a8-af2a-b8affc8471f5): V2 core and integration contracts for Ethena, Pendle Finance, and Aave V3. * [**Santipu** (Jan 2025)](https://github.com/santipu03/santipu03/blob/main/private-audits/dHEDGE_Aave.md): V2 integration contracts with Aave V3. * [**Santipu** (Jan 2025)](https://github.com/santipu03/santipu03/blob/main/private-audits/dHEDGE_GMX.md): V2 integration contracts with GMX. ### 2024 * [**Santipu** (Oct 2024)](https://github.com/santipu03/santipu03/blob/main/private-audits/dHEDGE_SAW.md): Single-asset withdrawals. * [**Trust Security** (Sep 2024)](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ff03kK69OTEEthfwi6VoC%2Fuploads%2F5G6Izg7noSGT7QsvSeho%2FdHEDGE%20Trust%20Security%20Audit.pdf?alt=media\&token=66115a16-ef90-47af-b01d-f757248ddcea): Cross-chain buyback contracts. * [**Sherlock** (Jun 2024)](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ff03kK69OTEEthfwi6VoC%2Fuploads%2Fo3epQZwV9tbnGp8EclE2%2FSherlock%20dhedge-audit-report.pdf?alt=media\&token=9b5fed38-6f68-4274-9b9b-4eed9920c908): V2 core contracts and integration contracts (review conducted on Optimism; codebase shared across all chains). ### 2023 * [**iosiro** (Dec 2023)](https://iosiro.com/audits/dhedge-synthetix-v3-integration-smart-contract-audit): V2 integration with Synthetix V3. * [**Zach Obront** (Jun 2023)](https://github.com/zobront/audits/blob/main/reports/dhedge.md): MTA token buyback. ### 2022 * [**CertiK** (Dec 2022)](https://skynet.certik.com/projects/dhedge?auditId=dHEDGE%20-%20%E2%85%A3#code-security): DHT Staking V2. ### 2021 * [**CertiK** (Jul 2021)](https://skynet.certik.com/projects/dhedge?auditId=dHEDGE%20V2#code-security): V2 core contracts. ### V1 contracts (legacy) * [**iosiro** (Mar 2021)](https://iosiro.com/audits/dhedge-differential-smart-contract-audit): Core contracts. * [**iosiro** (Sep 2020)](https://iosiro.com/audits/dhedge-platform-smart-contract-audit): Core contracts. *** ## Bug bounty * **Immunefi**: [immunefi.com/bounty/dhedge](https://immunefi.com/bounty/dhedge/) ## See also * [Guard system](/security/guard-system): the architectural layer most audits focus on * [Risk model](/security/risk-model): what audits do and don't cover # Bug bounty The Chamber bug bounty program, hosted on Immunefi Chamber runs a live bug bounty through **Immunefi**. The program pays researchers for finding vulnerabilities in the core vault contracts and their integrations. Payouts go up to **$50,000** for critical-severity findings. **Program page:** [immunefi.com/bounty/dhedge](https://immunefi.com/bounty/dhedge/) ## See also * [Audits](/security/audits): firm-led reviews that run alongside the bounty * [Guard system](/security/guard-system): the architectural surface most bug reports touch # Risk model The risks Chamber reduces at the contract level, and the risks that remain with the depositor A vault's total risk has several layers. Some are addressed by Chamber's architecture: audits, the Guard System, oracle design, fee caps. Others sit with the depositor regardless of how well Chamber is built. This page splits them. For the plain-English depositor-facing version, see [Deposit: risks](/deposit/risks). ## Risk categories ### 1. Smart contract risk **What it is:** A bug in the Chamber core vault contracts or their integration adapters causes loss of funds, incorrect accounting, or unintended asset movement. **What Chamber does:** * Multiple external audits from firms including Sherlock, Santipu, iosiro, CertiK, and Trust Security. See [Audits](/security/audits). * A live [bug bounty](/security/bug-bounty) through Immunefi with payouts up to $50,000. * The [Guard System](/security/guard-system) isolates each integration into an adapter. A bug in one integration doesn't give it arbitrary access to vault assets. * No custom code shipped without review for mainnet deployment. **Residual risk:** Non-zero. No contract is provably bug-free. The audit trail and incident history ([none since October 2020](/security/incident-history)) are the best forward-looking signal, not a guarantee. ### 2. Integration / counterparty risk **What it is:** A protocol Chamber vaults integrate with (Aave, GMX, Pendle, Uniswap, etc.) fails: exploit, governance attack, bad oracle, socialized loss. **What Chamber does:** * Protocol allowlists are governance-controlled, not manager-controlled. A manager cannot add a new protocol to the allowlist on their own. * Each integration ships with an adapter that constrains which functions on the external protocol can be called. * Integrations are audited alongside core contracts. **Residual risk:** Inherited directly. If Aave V3 has a governance exploit, a Chamber vault holding aTokens on Aave is affected. ### 3. Oracle risk **What it is:** The price feed a vault uses for NAV or collateral pricing reports a stale, manipulated, or incorrect value. **What Chamber does:** * Uses established providers: **Chainlink**, **Pyth**, and for some assets **TWAPs**. See [Oracles](/concepts/oracles). * Staleness timeouts on every feed (25 hours default for Chainlink, per-aggregator values for Pyth and hybrids). Stale prices revert the transaction rather than pricing off bad data. * Per-asset feed selection is governance-controlled, not manager-controlled. **Residual risk:** Short-window mispricing during oracle anomalies, depegs, or provider outages. Chamber can reject a stale feed but cannot manufacture a correct one. ### 4. Manager risk **What it is:** The manager makes bad trades inside the vault's rules (bad entries, over-concentration, poor timing) and depositors lose money. **What Chamber does:** * The Guard System limits what a manager *can* trade (assets, protocols, actions). * Public performance, risk factor, and vault score make manager behavior legible before depositing. See [Leaderboard & ranking](/concepts/leaderboard-ranking). * Fee caps and 14-day announcement delays prevent a manager from extracting via fee changes. **What Chamber doesn't do:** Chamber does **not** guarantee a manager trades well. Guards constrain the action space, not the quality of decisions inside it. A depositor picks the manager; Chamber makes that pick safer but not safe. ### 5. Market risk **What it is:** The assets the vault trades move against the strategy. A long-ETH vault loses money when ETH drops. A leveraged vault loses multiples. **What Chamber does:** Nothing, and it shouldn't. Market risk is the product the depositor is buying. Chamber's job is to make sure what you see is what you get, not to hedge the market for you. **Residual risk:** Total. This is always the depositor's. ### 6. Liquidity risk **What it is:** When you withdraw, the vault has to produce assets. If it holds illiquid positions, single-asset withdrawal incurs slippage; underlying-basket withdrawal hands you the illiquid positions directly. **What Chamber does:** * Both withdrawal methods are available. Pick the one that fits. * The basket method removes the vault's need to trade in stressed markets at all. * No withdrawal gating. The cost of stressed markets is passed through, not absorbed. **Residual risk:** In extreme stress, withdrawals are painful but not blocked. ### 7. Governance risk **What it is:** A DAO decision materially changes the protocol (fee split, Guard System parameters, supported assets) in a way that harms existing vaults or depositors. **What Chamber does:** * Material parameter changes go through [meta-proposals](/governance-and-token/meta-proposals) with vDHT-weighted voting and a public Snapshot record. * Certain depositor-hostile actions (retroactive fee changes, forced withdrawals) are not possible at the contract level. **Residual risk:** The DAO exists and can make decisions. Track governance if you're a serious depositor or manager. ### 8. Regulatory risk **What it is:** Your jurisdiction's rules change, affecting your ability to deposit, withdraw, or realize gains. **What Chamber does:** Nothing. The protocol is decentralized. Regulatory exposure sits with the user. *** ## Summary: who carries what | Risk | Chamber reduces | Depositor carries | | -------------------------- | --------------- | ----------------- | | Smart contract | ●●●○ | ● | | Integration / counterparty | ●● | ●● | | Oracle | ●●● | ● | | Manager (inside rules) | ●● | ●● | | Market | — | ●●●● | | Liquidity | ●● | ●● | | Governance | ●● | ●● | | Regulatory | — | ●●●● | The framing is deliberate: **Chamber is a safer wrapper around a risky activity**, not a risk-free wrapper. Treat it that way when sizing a deposit. ## See also * [Deposit: risks](/deposit/risks): plain-English version for depositors * [Guard system](/security/guard-system): how most of the mitigations above are actually enforced * [Oracles](/concepts/oracles): feed selection, TWAP, staleness * [Incident history](/security/incident-history) # 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: 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). ## For integrators If you're building on Chamber (using the [SDK](/build/sdk), the [MCP server](/build/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](/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](/security/audits): the Guard System code has been reviewed repeatedly * [Risk model](/security/risk-model): where Guard System sits in the overall risk picture * [Supported assets](/concepts/supported-assets): the public face of the asset and protocol allowlists * [Build: Guard system](/build/guard-system): integrator-facing details # Incident history Chamber's track record on security incidents since launch **No loss of depositor funds since launch in October 2020.** Chamber's core vault contracts (and the dHEDGE contracts they inherit from) have been live continuously on Ethereum mainnet since October 2020, and later on Polygon, Optimism, Arbitrum, Base, Plasma, and HyperEVM. Across that period, no depositor has lost funds to a contract exploit, oracle failure, or integration bug in Chamber. This isn't a claim that nothing has ever gone wrong in DeFi, or that the ecosystem around Chamber (integrated protocols, bridges, wallets, markets) has been incident-free. It is a claim about the Chamber contracts themselves: no successful exploit, no recovery event, no pause-and-socialize moment. ## What this doesn't mean * **It doesn't mean vaults can't lose money.** Managers can make bad trades. Markets move. See [Risk model](/security/risk-model) and [Deposit: risks](/deposit/risks) for what's actually at stake. * **It doesn't mean future incidents are impossible.** A clean history reduces risk; it doesn't eliminate it. Treat the bug bounty and ongoing audits as the forward-looking defense. * **It doesn't cover third-party protocols.** A vault exposed to an integrated lending market inherits that market's risk. The Guard System restricts what a vault can touch, but it can't prevent a whitelisted protocol from having its own problems. ## How to verify The cleanest way to confirm this is the onchain record. Vault deployments, fee mints, deposits, and withdrawals are all visible from the contract addresses. No emergency pauses, no post-incident redeploys, no retroactive socializations. If Chamber disclosed an incident in future, it would be documented here with date, scope, and response, in that order. ## See also * [Audits](/security/audits): the reviews that have kept the contracts on the track record above * [Bug bounty](/security/bug-bounty): the live program for anyone finding something the audits missed * [Risk model](/security/risk-model): what the track record does and doesn't imply # Overview How Chamber funds itself: treasury, revenue, buybacks, DAO fees, grants Chamber is self-funded. The protocol earns revenue from vault activity, holds it in an onchain treasury, and spends it on buybacks, grants, and operations. This section is the reference for how that works. ## What the protocol earns Chamber takes a **10% cut of every vault fee**: entry, exit, performance, and management. When a vault's fees mint new shares, 10% of those newly-minted shares are sent to the DAO treasury. The manager keeps 90%. This is the protocol's only source of recurring revenue. Chamber does not charge depositors anything beyond what the vault manager sets. See [DAO protocol fees](/treasury-and-protocol-economics/dao-protocol-fees) for the full mechanic. ## What the treasury holds Because fees are paid in vault shares, the treasury's position looks like a cross-section of the platform: shares in every fee-earning vault, plus assets accumulated from earlier periods. Some of that is held as DHT, some as stablecoins, some as redemptions into USDC. Live figures and the full holdings list are on the [Analytics page](https://chamberfi.com/analytics?analyticsType=treasury). See [Holdings](/treasury-and-protocol-economics/holdings). ## What the treasury funds Three main buckets: * **DHT buybacks**: a share of revenue is used to buy DHT on the open market and retire it. This is the primary mechanism for returning value to token holders. * **Grants**: targeted allocations to vault managers, ecosystem builders, and early-access programs (e.g. HyperEVM). * **Operations**: audits, oracle subscriptions, infrastructure. See [Revenue and buybacks](/treasury-and-protocol-economics/revenue-buybacks) and [Grants](/treasury-and-protocol-economics/grants). ## Governance over the treasury The treasury is controlled by the DHT DAO. Allocation, buyback cadence, and fee parameters can be changed through the [meta-proposal process](/governance-and-token/meta-proposals). vDHT holders vote; the 10% protocol fee itself is a governance parameter and can in principle be moved, but has stayed at 10% since launch and is not expected to change. ## Transparency Everything above is visible onchain. The treasury address, fee splits, and buyback transactions are all verifiable without asking Chamber for anything. The [Analytics page](https://chamberfi.com/analytics?analyticsType=treasury) is the best starting point. # Holdings What sits in the Chamber treasury and how to verify it onchain The Chamber protocol treasury holds the DAO's accumulated revenue plus direct holdings allocated by governance. It sits onchain, multisig-controlled, and is fully visible. ## Live view The canonical source (total balance, composition, per-asset holdings, and per-protocol positions) is the Analytics page: * [chamberfi.com/analytics?analyticsType=treasury](https://chamberfi.com/analytics?analyticsType=treasury) Treat it as the source of truth. Figures drift with market prices and ongoing inflows, and the app always reflects the live state. ## What's in there The treasury's composition reflects how Chamber earns. Because every fee is paid in vault shares, the treasury accumulates shares in every fee-earning vault across the protocol, alongside whatever the DAO chooses to hold directly. Broadly, holdings fall into three categories: * **Vault shares**: 10% of every vault fee (entry, exit, performance, management) is minted to the DAO as vault shares. The treasury holds shares across the platform's fee-earning vaults. * **Stablecoins**: realized revenue redeemed from vault shares, plus assets held for operations and grant payouts. * **Volatile assets**: BTC, ETH, and a smaller allocation of alt exposure, held directly or through yield-earning positions. The Analytics page splits this into **App Holdings** (positions inside Chamber vaults and partner protocols) and **Token Holdings** (direct token balances). ## Revenue concentration Worth being explicit: revenue is concentrated. A large share of fee flow currently comes from [Toros Finance](/ecosystem/toros-finance) vaults, with the remainder from market-making and yield-farming vaults. Depositor-driven retail flow is a smaller slice than it looks from the front page. This matters for how the DAO thinks about treasury sustainability. A large drop in any one vault's AUM would move revenue noticeably. Buyback and grant programs are sized against this, not against an assumed steady flow. See [Revenue and buybacks](/treasury-and-protocol-economics/revenue-buybacks). ## Verifying onchain Every transaction into and out of the treasury is visible onchain. Multisig addresses and per-chain treasury contracts are documented alongside the deployment addresses; follow the addresses directly from the [Analytics page](https://chamberfi.com/analytics?analyticsType=treasury). # Revenue & buybacks How Chamber earns, and how that revenue flows back to token holders > Coming with the Chamber token rollout. Mechanics for buybacks and revenue distribution are being finalized alongside the tokenomics update. This page will be rewritten once those land. Until then: * **How Chamber earns**: a 10% protocol cut of every vault fee, paid in vault shares. See [DAO protocol fees](/treasury-and-protocol-economics/dao-protocol-fees). * **Where revenue sits**: [Holdings](/treasury-and-protocol-economics/holdings) and the live [Analytics page](https://chamberfi.com/analytics?analyticsType=treasury). * **Historical DHT buyback activity**: visible onchain from treasury transactions. # DAO protocol fees The 10% protocol cut of vault fees: what it is, what it applies to, and where it goes Chamber takes a **10% cut of every vault fee**. This is the protocol's only source of recurring revenue and the mechanism that funds the treasury, grants, and any future buyback programs. ## The rule When a vault's fees mint new shares, **10% of those newly-minted shares** are sent to the Chamber DAO treasury. The manager keeps 90%. This is enforced by the vault contract itself. It's not a withdrawal, a transfer, or something the manager has to remember to do. It happens at the same moment the fee is minted. ## Which fees it applies to All four: | Fee | DAO cut | | --------------- | ------- | | Entry fee | 10% | | Exit fee | 10% | | Performance fee | 10% | | Management fee | 10% | The cut is identical across all four. Older documentation that suggested the DAO cut applied only to performance and management fees is out of date. The contracts split every fee the same way. ## Paid in vault shares Like all Chamber fees, the DAO's cut is paid as vault shares, not as the vault's underlying asset. The treasury therefore accumulates **shares in every fee-earning vault across the protocol**. If the DAO wants those shares in stablecoins, it withdraws from the vault like any other holder. This is intentional: the DAO's exposure tracks the vaults it's hosting. Good vaults appreciate; poorly-performing vaults don't contribute as much. For the fee-share mechanic in depth, see [Manager: fees and performance](/manage/fees-performance). ## What it doesn't touch * **Depositors**: the 10% comes out of the manager's share, not the depositor's. A depositor in a vault with a 20% performance fee pays 20% to the vault; the manager sees 18%, the DAO treasury sees 2%. The depositor's cost is unchanged. * **The underlying assets**: fees mint new shares, which dilute all holders slightly. They don't move assets out of the vault. ## Governance The 10% rate is a governance parameter. DHT holders can in principle move it through the [meta-proposal process](/governance-and-token/meta-proposals). It has stayed at 10% since launch and isn't expected to change, but the mechanism exists. Any change would apply going forward only. Existing accrued fees aren't retroactively re-split. ## Where it goes The treasury receives the shares. From there, governance allocates the proceeds across: * Grants to managers and ecosystem builders * Operations: audits, infrastructure, oracle subscriptions * Buybacks (in future) See [Overview](/treasury-and-protocol-economics/overview) and [Holdings](/treasury-and-protocol-economics/holdings) for the current picture, and the [Analytics page](https://chamberfi.com/analytics?analyticsType=treasury) for live figures. # Grants How Chamber funds managers, integrators, and ecosystem projects Chamber runs discretionary grant programs out of the DAO treasury. They're aimed at people building things that grow the protocol: new managers launching vaults, integrators putting Chamber into front-ends and agents, and early-access programs on new chains. ## What grants cover Three broad buckets: * **Manager allocations**: direct capital or fee rebates for managers launching serious vaults, particularly in strategies or chains the DAO wants to seed. Often paired with referral program setup (see [Manager programs](/manage/manager-programs)). * **Ecosystem builds**: integrators using the [SDK](/build/sdk) or [MCP server](/build/mcp-server) in production front-ends, trading bots, or analytics tools. * **Early-access programs**: targeted allocations tied to new-chain launches, e.g. the HyperEVM early-access cohort. ## How to apply Grants are not a formal scheme with a published rubric. The process is: 1. Reach out via the [Chamber Discord](https://discord.com/invite/BAWTbRA) or email the team. 2. Describe what you're building, how much capital or support you need, and the timeline. 3. If it fits, the DAO reviews and allocates. Larger grants may go through a [meta-proposal](/governance-and-token/meta-proposals). This is deliberately lightweight. Chamber prefers shipping-then-funding over extensive application cycles. ## What it's not * Not a retail airdrop or yield program. Grants are targeted, not broadcast. * Not a guaranteed track for every manager. AUM and track record matter. * Not an ongoing salary. Grants are discrete, usually tied to a specific launch or milestone. ## See also * [Manager programs](/manage/manager-programs): referral fees and existing incentive layers for managers * [Overview](/treasury-and-protocol-economics/overview): how grants sit alongside buybacks and operations in the treasury budget # Overview How Chamber is governed and how the token works Chamber inherits its governance framework from dHEDGE. Until the Chamber token (CHMR) goes live, DHT remains the governance token and everything in this section describes the system as it runs today. ## How decisions are made * **Meta-Proposals (DMPs)** are the canonical mechanism for changing how governance itself works, or for authorizing protocol-level decisions. DMPs are written on [forum.dhedge.org](https://forum.dhedge.org), discussed in the thread, then voted on via Snapshot. See [Meta-Proposals (DMP)](/governance-and-token/meta-proposals). * **Voting** runs on Snapshot, weighted by vDHT accrued in legacy DHT Staking v2 on Optimism. Staking rewards have ended, but vDHT is still the voting weight. See [Legacy staking](/governance-and-token/dht-staking). * **Execution** is performed by the DAO multisig acting on the outcome of a passing vote. There is no onchain governor contract with automatic execution today. ## What governance controls * The protocol admin fee (currently 10% of manager fees, set by token holders) * Treasury allocations, reallocations, and liquidations * Additions and changes to the governance process itself (via DMPs) * Strategic decisions at the DAO level: grants, partnerships, major product direction ## The token * **DHT**: fixed supply of 100,000,000. Launched September 2020. Used for voting and revenue share. See [DHT (legacy)](/governance-and-token/dht-legacy). * **CHMR (Chamber token)**: placeholder. Most mechanics will inherit from DHT. See [Chamber tokenomics](/governance-and-token/chamber-tokenomics). ## What changes at rebrand Mechanics carry over. The token symbol, the DAO name, and the governance surfaces (forum, Snapshot space) may be renamed alongside the rebrand, but the DMP process and revenue share continue to work the way they do on dHEDGE today. # Meta-Proposals (DMP) The DMP process for changing governance and protocol-level decisions Meta-Proposals, DMPs, are the mechanism for changing how governance itself works. They are also used for protocol-level decisions that need a formal onchain signal from token holders. > DMPs are suggested changes to the governance process. The purpose is to make governance self-correcting while keeping the process transparent. ## Where DMPs live * **Written and discussed:** [forum.dhedge.org](https://forum.dhedge.org) * **Voted on:** Snapshot (vote must link back to the DMP, and the DMP back to the vote) ## Format Each DMP is a forum post with this structure: * **Title:** `DMP-X` where X is the next sequential number * **Header fields:** Author, Created (YYYY-MM-DD), Status * **Sections:** Motivation, Description Discussion happens in the comments on the forum post. ## States A DMP is always in one of five states: | State | Meaning | | ------------ | ------------------------------- | | Draft | Proposal made, but not voted on | | Under Review | A vote is ongoing | | Included | Passed vote | | Rejected | Failed vote | | Superseded | Replaced by a new proposal | Once voting concludes, DMPs are immutable. Any change requires a new DMP that supersedes the old one. ## Voting * Minimum voting period: **2 days** * Voting power: **vDHT** accrued in legacy DHT Staking v2, read on Snapshot * Voting happens on Snapshot by connecting the wallet that holds the stake ## How to propose 1. Draft the proposal on forum.dhedge.org with the title `DMP-X` and the required header fields 2. Let the community discuss it in the thread 3. Move it to a Snapshot vote once the thread has converged 4. Link the vote back to the DMP and the DMP back to the vote 5. On pass, the DAO multisig executes ## What DMPs are used for * Changes to the DMP process itself * Changes to fee structure or fee split * Treasury actions: reallocations, liquidations, major spends * Grants programs and partnerships * Anything that needs a formal, recorded token holder signal # Legacy staking DHT staking rewards have ended, but vDHT still carries governance voting weight DHT staking rewards are no longer running. Two versions existed historically: * **Staking v1**: the original DHT staking contract. * **Staking v2**: replaced v1 and introduced vDHT (voting power accrued linearly over time), paired DHT + vault-token staking, and NFT-represented stakes. DHT emissions from both contracts have ended. Staking v2 is still deployed, and vDHT accrued in it is still the voting weight Snapshot reads for governance. ## Withdrawing staked DHT (Staking v2) If you still have DHT in Staking v2, you can withdraw it: 1. Go to [chamberfi.com/dht/governance?governanceType=stakingV2](https://chamberfi.com/dht/governance?governanceType=stakingV2), or navigate from the Chamber app: **Footer → Gov → Legacy DHT → DHT Holders → Governance**. 2. Connect the wallet that created the stake. Stakes cannot be transferred, so they are always in the original wallet. 3. If your stake also holds vault tokens, unstake those first. Your DHT is automatically moved to a new stake, and you unstake the DHT from that new stake. 4. Follow the prompts to unstake. Your DHT is returned to your wallet once the transaction confirms. There is no lock-up or waiting period. Withdrawing removes the vDHT attached to the stake, which is your governance voting power. ## What this means for governance today * Governance votes run on Snapshot, weighted by vDHT accrued in Staking v2 on Optimism. * Unstaking DHT reduces your vDHT, and your voting power along with it. * Any future staking or voting-power system will be proposed via a [Meta-Proposal (DMP)](/governance-and-token/meta-proposals) before launch. ## What this means for the Chamber token Chamber token design is unfinalized. If it includes a staking or lock-for-voting mechanism, that will be documented when the DMP is posted. See [Chamber tokenomics](/governance-and-token/chamber-tokenomics). # Chamber tokenomics Chamber token design: placeholder until finalized The Chamber token (working ticker: **CHMR**) is not yet launched. Design is unfinalized and will be proposed via a DMP before any change is executed. ## What is known today * Most mechanics are expected to **inherit from DHT**: vDHT-weighted voting on Snapshot, revenue share, and the DMP governance process all continue to work as they do on dHEDGE today. See [DHT (legacy)](/governance-and-token/dht-legacy). * Any change to supply, distribution, or staking rules will be proposed as a [Meta-Proposal (DMP)](/governance-and-token/meta-proposals) and voted on before execution. * DHT is not being deprecated ahead of the token decision. It remains the governance token. ## What is not yet decided * Total supply of CHMR * Distribution: how DHT holders, the DAO, and new recipients are treated * Migration path, if any, between DHT and CHMR * Whether a new staking or lock-for-voting mechanism is introduced * Emissions schedule for CHMR This page will be updated when a DMP with the Chamber token design is posted. # DHT (legacy) The current dHEDGE token, its role, and what happens at rebrand DHT is the dHEDGE DAO token. It is the governance token today and will remain so until the Chamber token (CHMR) launches. This page documents DHT as it exists now. ## Basics * **Total supply:** 100,000,000 DHT (fixed) * **Launched:** September 2020 (token generation event) * **Ticker:** DHT ## What DHT does * **Governance.** DHT votes on [Meta-Proposals (DMP)](/governance-and-token/meta-proposals) via Snapshot, weighted by vDHT accrued in [legacy Staking v2](/governance-and-token/dht-staking). * **Fee authority.** DHT holders set the protocol admin fee (the DAO's cut of manager fees). Currently 10%. * **Revenue share.** Admin fees and direct DAO investments are collected in the protocol treasury. * **Staking.** An earlier staking-for-rewards system existed (v1 and v2) and is no longer active. See [Legacy staking](/governance-and-token/dht-staking). ## Allocation Unlocking has happened over a three-year schedule from launch. All base allocations are unlocked today. ## What happens to DHT at rebrand The Chamber token design is not yet finalized. Most likely outcomes, subject to DAO approval via a DMP: * DHT continues to exist and functions unchanged * A new CHMR token launches; DHT holders get a path to migrate, swap, or otherwise participate Details will be published in a DMP before any migration goes live. See [Chamber tokenomics](/governance-and-token/chamber-tokenomics) for placeholder information. ## Contract Use the contract address shown in the Chamber app or the canonical token listing for the chain you are using. # FAQ Short answers to the most common Chamber questions. Follow the links for detail. ## Is Chamber custodial? No. A Chamber vault is a smart contract that holds depositor assets under the manager's trading rules. The manager can trade within the vault's [enabled assets](/manage/permissions-access) but cannot withdraw depositor funds. That's enforced at the contract level by the [Guard System](/security/guard-system). ## Can a vault hold real stocks? Yes, as tokenized stocks and ETFs issued by Ondo Stocks, on Ethereum. A single vault can hold them alongside spot crypto, commodities, and stablecoins, which is what makes a cross-asset strategy expressible in one vault. The tokens give economic exposure under Ondo's terms rather than direct share ownership, and vaults holding them are subject to eligibility and regional access rules. See [Supported assets](/concepts/supported-assets) and [Risks](/deposit/risks). ## What does it cost to deposit? Whatever the vault manager sets: entry (0–2%), exit (0–2%), performance (0–50%), and annualized management (0–3%). Chamber takes a 10% cut of each fee; the rest goes to the manager. Fees are paid in vault shares, not the deposit asset. See [Fees and performance](/manage/fees-performance). ## How do I withdraw? Two methods: **single-asset** (the vault liquidates a pro-rata slice of its holdings and returns your chosen asset, may incur slippage) or **underlying basket** (you receive a pro-rata slice of every asset the vault holds, no vault-side swaps). See [Lockup and withdrawals](/deposit/lockup-withdrawals). ## Is there a lockup? Yes, up to 24 hours after a deposit, weighted across deposits. Top-ups extend the remaining lockup proportionally; they don't reset it. Shares can't be transferred or withdrawn during the lockup. See [Lockup and withdrawals](/deposit/lockup-withdrawals). ## How are vault prices calculated? The vault contract enumerates every holding, prices each via oracles (Chainlink, Pyth, or TWAP, chosen per asset at the protocol level), sums them, and divides by total shares outstanding. All onchain. See [NAV and accounting](/concepts/nav-accounting) and [Oracles](/concepts/oracles). ## What happens if a manager behaves badly? Bad trades within the vault's rules are possible and the depositor carries that risk. Bad actions outside the rules (trading non-allowlisted assets, calling non-allowlisted protocols, extracting depositor funds) are blocked at the contract level. See [Risk model](/security/risk-model). ## How do I integrate Chamber into my app? Public integrator surfaces: [SDK](/build/sdk), [Data API](/build/data-api), [Subgraph](/build/subgraph), [MCP server](/build/mcp-server), or the contracts directly. Start with [Build overview](/build/overview). ## Where do I ask something not answered here? [Discord](https://discord.com/invite/BAWTbRA) for general questions. For security issues, **use the** [**Immunefi bug bounty**](https://immunefi.com/bounty/dhedge/)**, not Discord**. # Glossary Chamber-specific terms and how they're used in these docs Terms used across Chamber docs. Alphabetical. ### Enabled assets The set of assets a specific vault is permitted to hold. Manager-configurable up to 12 at once, bounded by the [global asset list](#global-asset-list). ### Asset guard A per-asset-type contract that knows how to price, track the balance of, and unwind a given class of asset (plain ERC-20, Aave position, LP token, perp position, etc.). See [Guard system](/security/guard-system). ### Chamber DAO The DHT-governed DAO that owns the [protocol treasury](/treasury-and-protocol-economics/overview), controls the [Guard System](/security/guard-system) allowlists, and decides parameter changes via [meta-proposals](/governance-and-token/meta-proposals). ### Chamber token The Chamber token is in development. Details on governance role, supply, and mechanics will be published alongside the token launch. ### Contract guard A per-protocol contract that decodes and validates calls from a vault to an external protocol (Aave, Uniswap, Pendle, etc.). Calls that don't match the guard's rules revert. See [Guard system](/security/guard-system). ### Denomination asset The asset the vault's NAV and share price are quoted in. For Chamber vaults this is always **USD**, not a per-vault choice. See [Denomination asset](/manage/denomination-asset). ### Depositor whitelist On a private vault, the list of addresses permitted to deposit. Removing an address stops new deposits; it does **not** force existing positions out. ### DHT The dHEDGE DAO token, current Chamber governance token until CHMR launches. Used on Snapshot for meta-proposal voting. Historical staking/rewards programs are discontinued. See [DHT (legacy)](/governance-and-token/dht-legacy). ### Entry fee Optional fee charged on deposit, 0–2%. Paid in vault shares. 10% goes to the Chamber DAO. See [Manager: fees and performance](/manage/fees-performance). ### Exit fee Optional fee charged on withdrawal, 0–2%. Paid in vault shares. 10% goes to the Chamber DAO. ### Global asset list The protocol-wide allowlist of assets that can be added to any vault. An asset is on this list when it has a registered price feed in the protocol's AssetHandler. Governance-controlled (DAO multisig / onlyOwner), not manager-controlled. ### Guard System Chamber's contract-level layer that restricts which protocols a vault can call and which assets it can hold. See [Guard system](/security/guard-system). ### High-water mark (HWM) The highest NAV per share a vault has reached. Performance fees only mint when NAV exceeds the HWM. Vault-level and socialized across all holders (not per-depositor). See [Manager: fees and performance](/manage/fees-performance). ### Lockup The post-deposit cooldown during which those shares cannot be transferred or withdrawn, up to 24 hours, **weighted across deposits** (top-ups extend the remaining lockup proportionally, not reset it). Flash-loan protection. See [Lockup and withdrawals](/deposit/lockup-withdrawals). ### Management fee Annualized fee on AUM, 0–3%. Paid in vault shares, minted on deposit/withdrawal/manual trigger. 10% goes to the Chamber DAO. See [Manager: fees and performance](/manage/fees-performance). ### Manager The address that controls a vault's trading decisions, enabled assets, fees, and trader delegation. Cannot take custody of vault assets. See [Manage: overview](/manage/overview). ### Manual trigger A transaction the manager can send to force the vault to mint accrued fees and refresh state without a deposit or withdrawal. ### MCP server Chamber's Model Context Protocol server: a local-first npm package ([`@dhedge/chamber-mcp`](https://www.npmjs.com/package/@dhedge/chamber-mcp)) that lets Claude Desktop, Cursor, and other MCP clients read vault state (composition, holdings, NAV, positions). See [Build → MCP server](/build/mcp-server). ### Meta-proposal A Chamber DAO governance proposal. Discussed on the forum, voted on Snapshot weighted by vDHT. See [Meta-proposals](/governance-and-token/meta-proposals). ### NAV (Net Asset Value) Vault assets minus liabilities, divided by total shares. Priced using oracles. See [NAV accounting](/concepts/nav-accounting). ### Ondo Stocks The issuer of the tokenized US stocks, ETFs, and commodities a Chamber vault can hold (SPYon, NVDAon, GLDon, and others). Ethereum only. The tokens give economic exposure to the underlying asset under Ondo's terms rather than direct ownership of the share or commodity, and are subject to eligibility and regional access rules. See [Supported assets](/concepts/supported-assets) and [Risks](/deposit/risks). ### Oracle A price feed used to value a vault's holdings. Chamber uses **Chainlink**, **Pyth**, and (for some assets) **TWAPs**. Staleness timeouts apply per feed type (25-hour default for Chainlink; per-aggregator values for Pyth and hybrids). See [Oracles](/concepts/oracles). ### Performance fee Fee charged on gains above the [HWM](#high-water-mark-hwm), 0–50%. Vault-level and socialized. Paid in vault shares. 10% goes to the Chamber DAO. ### Private vault A vault with a depositor whitelist. Only whitelisted addresses can deposit; anyone on the list can withdraw as normal. ### Public vault A vault open to deposits from any address. ### Risk Factor A 1–5 rating of a vault's downside volatility, surfaced on the vault directory. See [Leaderboard and ranking](/concepts/leaderboard-ranking). ### Share (vault token / DHVT) The ERC-20 token representing a claim on a vault's assets. Transferable after the lockup (up to 24 hours, weighted across deposits) clears. See [Vault tokens](/concepts/vault-tokens). ### Single-asset withdrawal Withdrawal method that auto-liquidates the vault's positions and returns a single asset (usually the deposit asset). May incur slippage. ### Tokenized equities & RWA Onchain tokens tracking real-world assets: US stocks, ETFs, and commodities. On Chamber these are issued by [Ondo Stocks](#ondo-stocks) and available on Ethereum only. ### Trader An optional second address delegated by the manager to place trades. One trader per vault. Two permission toggles: "can change vault assets" (ON by default) and "can toggle vault privacy" (OFF by default). See [Trader delegation](/manage/trader-delegation). ### TWAP Time-weighted average price. One of the oracle types Chamber uses for assets where a single spot feed would be too manipulable. ### Underlying basket withdrawal Withdrawal method that returns a pro-rata slice of every asset the vault holds, including illiquid positions. No vault-side swaps, no slippage. You unwind the basket yourself. ### Vault A Chamber smart contract that holds assets under a manager's trading rules, with shares as receipts. Non-custodial. ### Vault Score A ranking metric: Sortino × √(7-day average vault value). See [Leaderboard and ranking](/concepts/leaderboard-ranking). ### vDHT Voting power earned by staking DHT in legacy Staking v2, accrued linearly over time. Staking rewards have ended, but vDHT is still the voting weight Snapshot reads for governance. See [Legacy staking](/governance-and-token/dht-staking). # Brand kit Chamber logos, wordmarks, colors, and usage guidelines > **Coming with the rebrand.** Logos, wordmarks, color values, typography, and usage guidelines will be published here by the design team ahead of the public announcement. Until then, for brand-usage questions reach out via [Discord](https://discord.com/invite/BAWTbRA). # Media kit Press assets, boilerplate copy, and company facts > **Coming with the rebrand.** Press kit, boilerplate copy, key facts, and press contact will be published here by the team ahead of the public announcement. For brand assets, see [Brand kit](/resources/brand-kit). For press inquiries in the meantime, reach the team via [Discord](https://discord.com/invite/BAWTbRA). # Legal & disclaimers Terms of use and general disclaimers The canonical terms of use are maintained at [**chamberfi.com/terms-of-use**](https://chamberfi.com/terms-of-use). Chamber-specific terms will be published here as part of the rebrand. Nothing in this documentation is financial, investment, tax, or legal advice. Depositing into a Chamber vault carries risk of loss. See [Deposit: risks](/deposit/risks). # Analytics Where to find live data on Chamber: TVL, revenue, treasury, vault activity Everything Chamber does is onchain. A few dashboards present the data in readable form. ## Official * [**chamberfi.com/analytics**](https://chamberfi.com/analytics): the app's built-in analytics page. Protocol overview, treasury composition (see [Holdings](/treasury-and-protocol-economics/holdings)), available assets, and manager stats. This is the source of truth for live figures. ## Third-party * **DeFiLlama**: TVL across chains and historical flows where available. * **Dune**: community-maintained dashboards where available. ## Onchain directly If you want raw data, the contract addresses for each chain are on the [deployments page](/build/contract-addresses). Vault state, fee mints, deposits, and withdrawals are all readable without an indexer. For indexed data, see the [subgraph](/build/subgraph) in the Build section. # Support How to get help with Chamber ## Getting help * **Support Chat**: the chat widget in the [Chamber app](https://chamberfi.com/). Best route for vault, access, and account questions. The team replies within 24 hours. * [**Discord**](https://discord.com/invite/BAWTbRA): community discussion. ## Before you ask * Check the [FAQ](/resources/faq) and [Glossary](/resources/glossary). * Search these docs. The sidebar covers most mechanics. * For live figures (treasury, TVL, APYs), the [Analytics page](https://chamberfi.com/analytics) is usually faster than asking. ## Reporting a security issue **Do not post security issues in Discord or public channels.** Use the [bug bounty on Immunefi](https://immunefi.com/bounty/dhedge/). Submissions filed there are covered by the program, and Immunefi handles triage.