> ## Documentation Index
> Fetch the complete documentation index at: https://v3.docs.derive.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# New features

> Methods and capabilities that v3 adds on top of the v2 surface.

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

<video autoPlay muted loop playsInline className="w-full aspect-video rounded-xl" src="https://mintcdn.com/derive-a0490cef/BhszcT-bQHpTuFnc/vaults/vault-intro.mp4?fit=max&auto=format&n=BhszcT-bQHpTuFnc&q=85&s=71fd65e91d816c7139decdc6d15883f5" data-path="vaults/vault-intro.mp4" />

See the [Vaults](/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.

<Frame>
  <img className="bg-black" src="https://mintcdn.com/derive-a0490cef/BhszcT-bQHpTuFnc/trading/risk-universes.png?fit=max&auto=format&n=BhszcT-bQHpTuFnc&q=85&s=f541ac88185cd2ab25f7d424a46680e6" alt="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." width="2560" height="1260" data-path="trading/risk-universes.png" />
</Frame>

See [Managers & Risk Universes](/trading/managers-and-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](/trading/managers-and-risk-universes#reading-public-get-all-currencies) 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.

<Frame>
  <img className="block dark:hidden bg-white" src="https://mintcdn.com/derive-a0490cef/BhszcT-bQHpTuFnc/authentication/protocol-scopes-light.png?fit=max&auto=format&n=BhszcT-bQHpTuFnc&q=85&s=96dc88b66009b358895daa16bfc5c1eb" alt="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." width="1712" height="1534" data-path="authentication/protocol-scopes-light.png" />

  <img className="hidden dark:block bg-black" src="https://mintcdn.com/derive-a0490cef/BhszcT-bQHpTuFnc/authentication/protocol-scopes.png?fit=max&auto=format&n=BhszcT-bQHpTuFnc&q=85&s=b972b12f5a638c813d8357f83d3315a0" alt="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." width="1712" height="1534" data-path="authentication/protocol-scopes.png" />
</Frame>

See [Access scopes](/authentication/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](/trading/transfers-withdrawals).


## Related topics

- [DevEx improvements](/migrating/v3-improvements.md)
- [Place a new order](/api-reference/orderbook/place-a-new-order.md)
- [Create a new curated vault](/api-reference/vault-curators/create-a-new-curated-vault.md)