# Why a Tango vault

> What a private strategy run by agents needs from the contract that holds its cash, and the design choices in the Tango vault that follow from it.

Source: https://app.tango.finance/docs/vault/why-custom

Every strategy you deploy on tango.finance is a Tango vault: a small set of smart contracts on Base that holds the strategy's cash and positions, and enforces its rules. Agents run your strategy for you, so the vault has to limit what they can do, value what it holds without asking anyone, and let you take your cash back without waiting on them. This page sets out those needs, the design choices that follow, and what they do not protect against.

> **Key points**
>
> - Your strategy is its own vault. You hold its top role, and agents act through narrower roles that cannot send cash anywhere but the vault and the venues it was set up with.
> - The vault values everything it can from onchain prices. It uses a posted figure only for an account a contract cannot see, such as a perps exchange account, and only within strict limits.
> - Agents act through built-in modules and approved transaction types, never open-ended calls. Every swap and loan is checked against oracle prices after it runs.
> - These limits narrow what can go wrong. They do not remove risk.

## What a private strategy needs

A strategy on tango.finance is built from your prompt, deployed in your name and run by agents. That puts specific demands on the contract underneath:

- You should hold the top role. Nobody else, including Tango, should be able to change the strategy's limits or take its cash.
- Agents should be able to buy, sell, lend and settle on your behalf, but only inside limits you can see, and never send cash to an address of their choosing.
- One strategy can do several things at once: hold tokens and stocks, park cash in money markets and trade perps. 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 from a contract. A reported value should be kept for venues that cannot be read onchain.
- Changes that add risk should be able to wait, if you want them to, so they are public before they take effect.
- Nothing should be upgradeable, so the code that was deployed is the code that runs.

## Design choices

Each need led to a design choice. The table sets each one beside the common alternative in vaults elsewhere.

| Choice in a Tango vault | Common alternative |
| --- | --- |
| NAV is calculated onchain from balances and oracle prices | A manager posts the total value |
| Separate [sub-accounts](https://app.tango.finance/docs/vault/sub-accounts.md), each with its own assets and limits | One pool holding every position |
| Built-in [modules](https://app.tango.finance/docs/vault/tracked-sub-accounts.md#modules) for swapping and lending | A general `execute` function that runs any transaction data |
| Readable [call shapes](https://app.tango.finance/docs/vault/attested-sub-accounts.md#approved-call-shapes) for offchain venues | Allowlists stored as a Merkle root |
| [Rate limits](https://app.tango.finance/docs/vault/rate-limits.md) on every path money can take into a position | No limit on how fast a key can move money |
| Narrow [profiles](https://app.tango.finance/docs/vault/roles.md) for settling, allocating and trading | One manager key that can do everything |
| [Timelocks](https://app.tango.finance/docs/vault/timelocks.md) chosen per vault and fixed for life | Changes that always take effect at once |
| Contracts that cannot be upgraded | Upgradeable proxies |

Here is why each one matters:

- NAV (net asset value) is the total value of everything the vault holds. When it is worked out from balances and oracle prices, there is no price for anyone to choose. A reported value, called an attestation, is used only for an account the vault cannot read, and only inside 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 nobody, including you, can check transaction data that cannot be 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 pattern of arguments. Each one is readable, and the recipient of a transfer can be fixed byte by byte.
- Rate limits mean even a key that is allowed to act cannot move a strategy's whole balance at once.
- Narrow profiles mean the key agents use can settle, allocate and trade, but not add assets, raise limits or change who holds a role.
- Timelocks let a change that adds risk wait in public. On tango.finance you choose them when you deploy, or leave them off.
- Without upgrades, the code that was reviewed is the code that runs. Changing a ceiling or the way value is measured means deploying a new vault.

## Standards

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

| Standard | How a Tango vault uses 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 stated differences. |

ERC-7540's operator approvals let a holder approve another address to manage requests for them. On tango.finance, your wallet approves your own manager contract this way, so a withdrawal can run as one transaction. See [Withdrawals](https://app.tango.finance/docs/vault/withdrawals.md).

The vault states its 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` and the conversion functions also revert while NAV is stale, rather than return a wrong number. `deposit`, `mint`, `withdraw` and `redeem` claim requests that have already been settled.

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

## Release

Every tango.finance strategy is deployed from contract release 0.15.0, and keeps its release for life. A contract release is a fixed version of the vault's code. These docs describe release 0.15.0. See [Architecture overview](https://app.tango.finance/docs/vault/overview.md#contract-release).

## 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 and money markets can lose money. Agents can make losing trades inside every limit. Your wallet holds the vault's top role, so anyone who controls your wallet holds it too. Read [Roles and profiles](https://app.tango.finance/docs/vault/roles.md), [Timelocks](https://app.tango.finance/docs/vault/timelocks.md) and [Risks](https://app.tango.finance/docs/vault/risks.md) to see who can do what, and when.