tango.finance
Skip to content

Tango vaults

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.

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 vaultCommon alternative
NAV is calculated onchain from balances and oracle pricesA manager posts the total value
Separate sub-accounts, each with its own assets and limitsOne pool holding every position
Built-in modules for swapping and lendingA general execute function that runs any transaction data
Readable call shapes for offchain venuesAllowlists stored as a Merkle root
Rate limits on every path money can take into a positionNo limit on how fast a key can move money
Narrow profiles for settling, allocating and tradingOne manager key that can do everything
Timelocks chosen per vault and fixed for lifeChanges that always take effect at once
Contracts that cannot be upgradedUpgradeable 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.

StandardHow a Tango vault uses it
ERC-20Vault shares are a token with 18 decimals.
ERC-7540Deposits and redemptions are requests that are settled later, with operator approvals.
ERC-7575The vault contract is also the share token.
ERC-8161A pending deposit or redemption request can be transferred to another address.
ERC-4626The 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.

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.

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.

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, Timelocks and Risks to see who can do what, and when.