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; the Guard System enforces the allowlist onchain at every trade. This page explains the shape of the allowlist and how it evolves.

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.

Supported categories

The allowlist is organised 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
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 for the per-chain matrix.

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 exists (Chainlink, Pyth, or TWAP).

• 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.

• 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 — per-chain support matrix.

• Permissions & access — how managers set their vault's enabled assets.

• Trading — what categories and protocols look like in the trade UI.

• Guard System — how the allowlist is enforced.