# Why a custom vault

> Why Tango built its own vault, what a strategy marketplace needs from one, and the design choices that set it apart from common vault frameworks.

Source: https://docs.tango.fun/vaults/why-custom

Tango built its own vault instead of adopting an existing framework. A marketplace where anyone can turn a strategy into a vault asks a lot of the vault underneath. This page sets out what Tango needed, the design choices that followed, and what those choices do not protect against.

> **Key points**
>
> - Tango needed vaults that anyone can create, that keep several strategies apart inside one vault, and that value everything they can onchain.
> - Existing frameworks either trust a reported price, allow open-ended calls, or keep every strategy in one shared pool. Tango's vault does none of these by default.
> - The result is a set of small contracts that cannot be upgraded. They have explicit limits, long delays on anything that adds risk, and an exit path for depositors that does not depend on the manager.
> - These limits narrow what can go wrong, but they do not remove risk.

## What Tango needed

Tango is a marketplace where creators turn trading strategies into vaults, and depositors choose which strategies to back. That puts unusual demands on the vault itself:

- Anyone can create a vault, and a creator is often an individual, not an institution. Each vault comes from a factory, a contract that deploys vaults with fixed ceilings (upper limits). Every vault from the same factory shares the same rules.
- One vault can hold several strategies. A strategy might swap tokens, lend USDC and trade perps at the same time. Each activity needs its own place to hold money, its own limits and its own way of being valued.
- Value should be read onchain wherever possible, from an oracle (an onchain price feed) or a contract. Reported values are kept for venues that cannot be read onchain, such as an exchange account.
- A manager should only be able to take the bounded actions the vault was built to allow, never open calls. Each action should be checked against oracle prices.
- Changes that add risk should take time, so depositors can leave before such a change takes effect.
- Depositors need a way out that does not depend on the manager. A depositor who asked to withdraw and was not served can force their own exit after a fixed wait.

## Design choices

Each need led to a design choice. The table sets each choice beside the common alternative in other vault frameworks.

| Choice in Tango vaults | Common alternative |
| --- | --- |
| NAV is calculated onchain from balances and oracle prices | A valuation manager posts the total value |
| Separate [sub-accounts](https://docs.tango.fun/vaults/sub-accounts.md), each with its own assets and limits | One pool holding every position |
| Built-in [modules](https://docs.tango.fun/vaults/tracked-sub-accounts.md#modules) for swapping, lending and liquidity | A general `execute` function that runs any transaction data |
| Readable [call shapes](https://docs.tango.fun/vaults/attested-sub-accounts.md#approved-call-shapes) for offchain venues | Allowlists stored as a Merkle root |
| Price set when a request is settled | Price fixed when a request is made |
| [Forced exit](https://docs.tango.fun/vaults/withdrawals.md#forced-exit) after 3 days | Withdrawals only when the manager acts |
| [Timelocks](https://docs.tango.fun/vaults/timelocks.md) at least twice the forced-exit wait | Changes take effect at once |
| Contracts that cannot be upgraded | Upgradeable proxies |

Here is why Tango chose each one:

- NAV (net asset value) is the total value of the vault. When it is worked out from balances and oracle prices, there is no price for anyone to choose. Reported values, called attestations, are used only for venues that cannot be read onchain, and only within a set range.
- Separate sub-accounts keep a problem in one part of the strategy inside its own account and its own limits.
- Modules replace open calls because a timelock cannot protect against transaction data that nobody can read. Each module call is checked against oracle prices after it runs.
- A call shape is an approved transaction type: a named target contract, function and fixed arguments. Each shape is readable, so anyone can inspect it, and adding one is timelocked.
- Setting the price at settlement means nobody can lock in a stale price by requesting early.
- The forced exit means a depositor's exit does not depend on the manager's goodwill.
- Long timelocks let a depositor who disagrees with a scheduled change leave before it takes effect.
- Without upgrades, the code a depositor reviews is the code that runs. Changing a ceiling or the way value is measured means deploying a new vault.

Tango made these choices from its own requirements. It studied existing vault designs as evidence, but added no mechanism just because another vault has it.

## Standards

Tango vaults follow established token standards, so wallets, indexers and other integrations can read them. Each ERC below is a published standard for how a token or vault contract behaves.

| Standard | How Tango vaults use it |
| --- | --- |
| ERC-20 | Vault shares are a token with 18 decimals. |
| ERC-7540 | Deposits and redemptions are requests that are settled later, with operator approvals. |
| ERC-7575 | The vault contract is also the share token. |
| ERC-8161 | A pending deposit or redemption request can be transferred to another address. |
| ERC-4626 | The standard vault interface is implemented, with two stated differences. |

ERC-7540's operator approvals let a holder approve another address to manage requests for them.

Tango vaults state two differences from ERC-4626. The preview functions, which estimate a deposit or withdrawal in advance, always revert, meaning the call fails instead of answering. `totalAssets` also reverts while NAV is stale, rather than return a wrong number.

Permissions use OpenZeppelin's AccessManager, a standard access-control contract, with one role for each restricted function. See [Roles and profiles](https://docs.tango.fun/vaults/roles.md).

## What this does not mean

Explicit limits narrow what can go wrong, but they do not remove risk. Smart contracts can have bugs, oracles can fail and venues can lose money. A vault's admin also holds broad powers behind its timelocks. Read [Roles and profiles](https://docs.tango.fun/vaults/roles.md) and [Timelocks](https://docs.tango.fun/vaults/timelocks.md) to see exactly who can do what, and when.