Skip to main content

​
Premissionless vaults

v3 bakes vaults natively into the protocol - which means you can launch a sophisticated vault strategy within minutes with no-humnas-in-the-loop. Vaults can be created, managed, and used entirely through the UX or programmatically. See the Vaults guide for more information.

​
Risk universes

v3 introduces risk universes — isolated risk boundaries, each with its own managers, collateral, and open-interest and lending rules. Losses in one universe are contained to that universe and can never socialize onto another, so a new (and potentially riskier) listing lives walled off from the core book. This lets us significantly ramp up new collateral, perp, and option listings — new assets can go live in their own universe without adding risk to existing markets.
Diagram of the breakdown of managers, currencies, instruments, and collaterals in each risk universe. The latest values can be taken from the public/get_all_currencies endpoint.
See Managers & Risk Universes for how to read what’s supported where.

​
2-sided lending on all collaterals

v2 lending was USDC-only. In v3 every collateral has a 2-sided lending pool — you earn supply APY on what you post and can borrow against it, per asset and per risk universe. Live borrow/supply APYs, utilisation, and borrow caps are exposed on each spot asset via public/get_all_currencies (spot[].universes[].lending). See Managers & Risk Universes for how to read lending per asset.

​
Granular session key scopes

In v3, account admins can choose to granular session keys for each type of team member - trading spot vs managing vaults vs purely read-only.
Diagram of the Derive protocol scope tree. The root grant `admin` sits above the branches trade, transfer, withdraw, liquidate, create_session_key, and vault; a grant on any node implicitly covers all of its descendants (for example `trade:all` covers `trade:orderbook:all` and `trade:rfq:option`, and `all` at any level covers its children). The trade branch nests by venue (orderbook, rfq) and then instrument (perp, option, spot), and each node is labeled with the exact wire string a key is granted (e.g. `trade:orderbook:all`, `transfer:existing_subaccount`). A session key with no protocol scopes is read-only. A request is authorized by checking whether one of the key's grants allows the specific scope the action requires.
See Access scopes for more information on session key scopes.

​
External transfers & whitelists

v3 adds the ability to transfer spot to a different owner’s subaccount. Admins can now set allowed recipients for external transfers and withdrawals using the private/update_whitelisted_recipients signed action. See Transfers & Withdrawals.

Related topics

DevEx improvementsPlace a new orderCreate a new curated vault