tango.finance
Skip to content

Tango vaults

Sub-accounts and NAV

How a Tango vault splits a strategy into separate sub-accounts, and how their values add up to the vault's NAV and the price of every deposit and withdrawal.

A Tango vault does not keep all of its money in one place. It splits the strategy into sub-accounts: separate contracts that each hold one part of the strategy, with their own assets, limits and way of being valued. The vault adds up what each sub-account is worth to get its NAV (net asset value), and that number sets the price of every deposit and withdrawal.

Key points

  • Each sub-account is its own contract with its own assets and limits, so one activity cannot spill into another.
  • The vault's NAV is its idle USDC plus the value of every sub-account, minus fees it owes. NAV divided by the number of shares is the share price.
  • Tracked sub-accounts are valued from onchain prices. Attested sub-accounts are valued from a reported figure that must stay within strict limits.
  • When any price the vault needs is stale, nothing settles until it is fresh again.

Why sub-accounts

A strategy often does several things at once. It might hold BTC, keep cash in a money market and trade perps on an exchange. If all of that sat in one account, it would share one set of permissions, one way of measuring value and one point of failure.

Sub-accounts keep these activities apart. Each sub-account:

  • is a separate contract that holds its own assets;
  • has a cap on how much of the vault's money it can hold, and a limit on how fast that can grow;
  • has its own list of assets it may hold, or its own list of transactions it may make;
  • has its own trader role, so a key can be limited to a single sub-account;
  • is valued in its own way.

Money never moves straight from one sub-account to another. It goes back to the vault first and is then sent out again, so every move passes the limits of the sub-account receiving it.

How NAV adds up

PartHow it is counted
Vault idle USDCFrom the vault's own records, not its token balance
Tracked sub-accountEach registered asset's tracked quantity times its oracle price, converted to USDC
Attested sub-accountThe last accepted reported value, adjusted exactly for USDC sent in or brought back since
Accrued feesFees earned but not yet minted as shares, subtracted
Not countedPending deposits, USDC already owed to settled withdrawals, and tokens sent to any contract without being asked for

NAV equals idle USDC plus tracked values plus attested values, minus accrued fees. The share price is NAV divided by the number of shares.

The vault works out its NAV fresh every time it settles a deposit or a withdrawal. It never stores an old figure to reuse. A few details make the number hard to push around:

  • The vault and its tracked sub-accounts count what they recorded receiving, not whatever tokens sit at their address. Nobody can move the share price by donating tokens to a vault.
  • Every asset is priced in US dollars, added up, and converted to USDC once using the USDC price feed.
  • NAV leaves out money that belongs to specific people: USDC waiting in a deposit request, and USDC already set aside for a settled withdrawal.

When NAV is stale

A price is stale when it is too old to trust, for example an oracle price past its update deadline, or a reported value that has not been refreshed in time. If any price the vault needs is stale, the whole NAV is stale. While that lasts:

PausedStill works
Settling deposits and withdrawalsRequesting a deposit, and cancelling a request
Forced exitsClaiming requests that were already settled
Swaps and lending in a tracked sub-account whose prices are staleBringing USDC back from a fresh attested sub-account
Reading the vault's total value (it reverts instead of returning a wrong number)Sending USDC to a sub-account that is not frozen

This is a deliberate brake. Nobody can deposit or withdraw at a price the vault cannot stand behind. It also means settlement can pause, for example while tokenized stock prices are frozen over a weekend. See Tokenized stocks.

Tracked and attested

Tracked sub-accountAttested sub-account
Valued fromQuantities of registered assets times oracle pricesA reported value, used only within a set range
Acts throughBuilt-in modules for swapping and lendingA short list of approved transaction types, such as a bridge transfer
Can holdOnly registered assets countAnything; the report values the whole account
Can borrowNoYes, through approved transactions
Each action is checked byAn oracle price check plus policy limitsThe approved-transaction list; the next report shows the result
On tango.financeThe Strategy account: spot, stocks and money marketsThe Perps account, linked to a trading account on Hyperliquid

Read more in Tracked sub-accounts and Attested sub-accounts.

How many, and when they are added

  • Every vault has a maximum number of sub-accounts, fixed when it is deployed. A tango.finance strategy has one sub-account, or two with perps.
  • Sub-accounts are added when the vault is deployed, through the factory.
  • Adding one later is a Critical-tier change, and the vault's maximum still applies. See Timelocks.
  • Removing one takes two steps. It is marked for removal right away, and removed once it holds nothing. A removed sub-account can never be added back, and NAV does not change at either step.

Limits on capital

LimitWhat it capsTo raise itTo lower it
Allocation capHow much USDC can be sent to a sub-account, minus what it has sent back. Gains do not count against it.High-tier change, and never above a ceiling fixed at deploymentImmediate
Sending limitHow fast USDC can be sent in, like a bucket that refills over timeHigh-tier changeImmediate

Both start at zero, which blocks everything until they are set. On tango.finance they are set when the strategy is deployed, and the Advanced tab shows each sending limit as Cash In. See Rate limits.