# Tango Docs > Tango (tango.fun) is a marketplace for tokenized trading strategies. Creators turn their strategies into onchain vaults; depositors choose the strategies they want to back. These docs explain how Tango vaults work onchain and how the Tango app uses them. # Introduction > What Tango is, how its vaults and app fit together, and where to start reading, whether you create strategies, back them or ask an AI about them. Source: https://docs.tango.fun/ Tango is the marketplace for tokenized trading strategies. **Creators** turn their strategies into onchain vaults. **Backers** choose the strategies they have conviction in and deposit USDC. Good ideas deserve backing. These docs explain how that works. They cover the smart contracts underneath every strategy, and the choices the Tango app makes on top of them. > **Key points** > > - Every strategy on Tango is a vault: a set of smart contracts that holds the backers' USDC and enforces the strategy's rules. > - Backers deposit USDC and receive shares. Withdrawals are requests, settled at NAV per share. > - The contracts set what is possible. The Tango app uses narrower settings, and sets what Tango users do today. > - Strategies are created by their creators, not by Tango. Read a strategy's Risks tab and these docs before you deposit. ## How it fits together The diagram follows a strategy from the creator's idea to a backer's deposit and withdrawal. ```text Creator -> Tango app: builds a strategy (assets, lending, liquidity, perps, fees) Tango app -> Vault factory: deploys a Tango vault with fixed limits Backer -> Vault: deposits USDC, receives shares Vault -> Tracked sub-account: tokens, tokenized stocks, Morpho lending, Uniswap liquidity, valued by onchain price feeds (oracles) Vault -> Attested sub-account: perps on Hyperliquid, valued by a posted figure that must stay within strict limits Backer -> Vault: requests a withdrawal, settled at NAV per share ``` NAV (net asset value) is the total value of everything the vault holds, in USDC. NAV per share is that value divided by the number of shares. [Key concepts](https://docs.tango.fun/concepts.md) explains these and the other terms these docs use. ## Start here | If you want to | Read | | --- | --- | | See what makes Tango different | [What makes Tango different](https://docs.tango.fun/why-tango.md) | | Understand the vocabulary | [Key concepts](https://docs.tango.fun/concepts.md) | | Know why Tango built its own vault | [Why a custom vault](https://docs.tango.fun/vaults/why-custom.md) | | See the whole system on one page | [Architecture overview](https://docs.tango.fun/vaults/architecture.md) | | Create a strategy | [Create a strategy](https://docs.tango.fun/app/create-a-strategy.md) | | Deposit or withdraw | [Deposits in the app](https://docs.tango.fun/app/deposits.md) and [Withdrawals in the app](https://docs.tango.fun/app/withdrawals.md) | | Trade perps | [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md) | | Hold tokenized stocks | [Tokenized stocks](https://docs.tango.fun/app/tokenized-stocks.md) | | Check who can change what | [Roles and profiles](https://docs.tango.fun/vaults/roles.md) and [Timelocks](https://docs.tango.fun/vaults/timelocks.md) | ## Two layers Tango has two layers: the contracts that hold the money, and the app people use to build and back strategies. **Tango vaults** are the contracts. They enforce the rules for every strategy: which assets it can hold, how it is valued, and how money comes in and goes out. They also decide who can change what, and how long each change takes. The [Tango vaults](https://docs.tango.fun/vaults/why-custom.md) section describes them. **The Tango app** at [app.tango.fun](https://app.tango.fun) is where creators build and run strategies, and where backers deposit. The app deploys vaults with narrower settings than the contracts allow. For example, it fixes a strategy's assets for life. The [Tango app](https://docs.tango.fun/app/overview.md) section describes those choices. When the two differ, the contracts set what is possible, and the app sets what Tango users do today. ## For AI assistants Every page is available as Markdown at its own URL with `.md` added. The full index is at [/llms.txt](https://docs.tango.fun/llms.txt), and the whole site is one file at [/llms-full.txt](https://docs.tango.fun/llms-full.txt). See [For AI assistants](https://docs.tango.fun/reference/for-ai-assistants.md). ## Before you deposit Strategies are created by their creators, not by Tango. Permissions, limits and timelocks constrain what can happen; they do not guarantee returns or protect against every loss. Smart contracts, oracles, venues and bridges can fail. Withdrawals are requests with no fixed settlement time. Read a strategy's Risks tab and these docs, and decide for yourself. Nothing here is investment advice. --- # What makes Tango different > How Tango lets a creator package a strategy that spans many assets and trading venues into one vault, and how that differs from vaults elsewhere. Source: https://docs.tango.fun/why-tango Tango is a marketplace for tokenized trading strategies. A creator can put a whole strategy, spread across several assets and trading venues, into one vault that anyone can deposit into. Vaults elsewhere are usually built around one kind of trade, like lending a single asset, or looping it by borrowing against a deposit and depositing again to multiply the same yield. - A single Tango strategy can trade tokens and tokenized stocks, lend on Morpho, provide liquidity on Uniswap and trade perps on Hyperliquid, and backers hold all of it through one share token. - Each part of a strategy runs in its own sub-account, with its own assets, limits and way of measuring value, so one activity can't reach into another's money. - In many vaults, the manager simply reports what the vault is worth. Tango prices everything it can from onchain data. It only uses a reported figure for venues a contract can't see, like a perps exchange account, and that figure has to stay within strict limits. - Running a vault today usually means jumping between a separate dapp for each protocol, several wallets, and a vault platform to hold it all together. Tango puts all of that in one app. A creator can swap, lend, provide liquidity, trade perps, move cash and settle deposits and withdrawals from one place, without writing any contracts. That lowers the cost and effort of running a strategy, so creators can spend their time on the strategy, on managing it well and on their backers, instead of on operations. - Many vaults let the manager send almost any transaction from the vault. A Tango vault can only use the assets, venues and actions it was set up with, and every swap, loan and liquidity change in its onchain account is checked against oracle prices. - Creators can lock their own money in their strategy for a set time, and backers can see how much is locked and when it unlocks. - The Tango team is building AI help into the app, to support creators as they shape a strategy and as they carry it out. ## What this looks like in practice A creator can buy a Mag7 stock such as NVDA as a tokenized stock, and short the same amount of its perp on Hyperliquid. The two positions cancel out each other's price moves, so what's left is the perp's funding rate: the strategy collects funding while it's positive and pays it if it turns negative. As funding rates shift, the creator can rotate between the Mag7 stocks they picked when setting up the strategy, and keep any cash they aren't using earning interest on Morpho. A creator can provide WETH/USDC liquidity on Uniswap to earn trading fees, and short ETH on Hyperliquid to cancel out the ETH price exposure that comes with the pool. A liquidity position holds more ETH as the price falls and less as it rises, so the creator resizes the short as the price moves to keep the hedge in line. In each case, the creator chooses the assets and venues when they set up the strategy, and those choices are fixed from then on. Backers can see exactly what the strategy is allowed to hold before they deposit. For the technical details, see [Why a custom vault](https://docs.tango.fun/vaults/why-custom.md). --- # Key concepts > The ideas every other page builds on, from strategies, vaults, shares and NAV to sub-accounts, settlement, roles and timelocks, each in a few plain sentences. Source: https://docs.tango.fun/concepts The Tango docs use a small set of ideas again and again. This page explains each one in two or three sentences, so the rest of the docs are easier to follow. Each idea links to the page that covers it in depth. > **Key points** > > - A strategy in the Tango app is a vault onchain. Backers deposit USDC into it and receive shares. > - Shares are priced at NAV per share: the vault's total value divided by the number of shares. > - Deposits and withdrawals are requests that are settled later, and nothing settles while a price is out of date. > - Changes that add risk wait behind a timelock of 3, 7 or 14 days. Changes that reduce risk take effect immediately. ## Strategy and vault A **strategy** is what a creator builds in the Tango app: a set of assets, venues and rules. Onchain, every strategy is a **Tango vault**, a set of smart contracts that hold the money and enforce the rules. The app says strategy and the contracts say vault, but they are the same thing. ## Creator and backer The **creator** builds and runs a strategy, and earns the fees they set. A **backer**, also called a depositor, puts USDC into a strategy. The same person can be both. ## Shares When you deposit USDC, you receive **shares** of the vault, which are an ERC-20 token (the standard token format on Ethereum-style networks). Your shares are your part of everything the vault holds. Withdrawing means redeeming your shares for USDC. ## NAV and share price **NAV** (net asset value) is the total value of what the vault holds, in USDC: its idle cash plus every sub-account's value, minus fees owed. **NAV per share** is NAV divided by the number of shares. Deposits and withdrawals are priced at NAV per share at the moment they are settled. See [Sub-accounts and NAV](https://docs.tango.fun/vaults/sub-accounts.md). ## Stale prices A NAV is **stale** when any price it depends on is out of date. Nothing can be settled until the NAV is fresh again. See [When NAV is stale](https://docs.tango.fun/vaults/sub-accounts.md#when-nav-is-stale). ## Sub-accounts A vault keeps its strategy in **sub-accounts**: separate contracts, each with its own assets and limits. A **tracked** sub-account holds tokens the vault can price onchain, and acts only through built-in modules for swapping, lending and liquidity. An **attested** sub-account reaches offchain venues, such as a perps exchange, and is valued by a posted figure that must stay within strict limits. ## Requests and settlement Deposits and withdrawals start as **requests**. They are **settled** later, at one price for the whole batch. Some vaults also allow **atomic** deposits, which request, settle and deliver shares in a single transaction. See [Deposits](https://docs.tango.fun/vaults/deposits.md) and [Withdrawals](https://docs.tango.fun/vaults/withdrawals.md). ## Forced exit If a withdrawal request is not settled within 3 days, its owner can **force an exit**. The forced exit pays them from the vault's cash and tracked sub-accounts, without the creator. See [Forced exit](https://docs.tango.fun/vaults/withdrawals.md#forced-exit). ## Oracles and attestations An **oracle** is an onchain price feed, such as Chainlink. An **attestation** is a value posted by an authorised service for something oracles cannot see, like an exchange account balance. Tango vaults use oracles wherever they can, and attestations only where they must. ## Roles and timelocks A **role** is the permission to take one restricted action, and roles are grouped into **profiles** such as the VaultAdmin, VaultManager and Sentry. Actions that add risk wait behind a **timelock**, a delay of 3, 7 or 14 days, while actions that reduce risk are immediate. See [Roles and profiles](https://docs.tango.fun/vaults/roles.md) and [Timelocks](https://docs.tango.fun/vaults/timelocks.md). ## Ceilings Many limits have a **ceiling** that is fixed at deployment and can never be raised, such as maximum fees, the maximum deposit cap and maximum slippage. Settings can move below the ceiling, but never above it. ## Releases Each vault is deployed from one **contract release**, a fixed version of the contract code, and keeps it for life. New Tango strategies use release 0.12.0. See [Contract releases](https://docs.tango.fun/vaults/architecture.md#contract-releases). --- # 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. --- # Architecture overview > The contracts that make up a Tango vault, how money and value move between them, and which contract releases are in use today. Source: https://docs.tango.fun/vaults/architecture A Tango vault is not one contract but a small group of them. A share token takes deposits and pays withdrawals, sub-accounts hold the strategy's positions, and supporting contracts value, limit and guard them. This page shows how the pieces fit together, how money moves between them, and which contract releases are in use. > **Key points** > > - A Tango vault is a share token plus a set of sub-accounts. The vault holds idle USDC, and the sub-accounts hold the strategy's positions. > - A NAV oracle adds up the vault's idle USDC and every sub-account's value. Deposits and withdrawals are settled at that NAV. > - One AccessManager controls every restricted function, and anything that adds risk waits behind a timelock. > - Each vault keeps the contract release it was deployed with. New strategies use release 0.12.0. ## How the pieces fit Idle USDC is cash the vault holds but has not yet sent to a sub-account. NAV (net asset value) is the total value of everything the vault holds. The diagram shows each contract and what passes between them. ```text Depositor -> Vault: request deposit (USDC waits in the deposit silo, outside NAV) Vault -> Depositor: claim shares after settlement Vault -> Tracked sub-account: send USDC (capped per sub-account, rate limited) Tracked sub-account -> Modules: swap, lend, provide liquidity; every call checked against oracle prices Tracked sub-account -> Asset registry and price oracle: only registered assets, priced by oracle adapters Vault -> Attested sub-account: send USDC Attested sub-account -> Offchain venue: approved call shapes only (for example a bridge to an exchange account) NAV provider -> Attested sub-account: reported value, accepted only inside a deviation band NAV oracle: vault NAV = idle USDC + sum of sub-account values AccessManager: gates every restricted function, with timelocks by risk tier Factory: deploys and connects every contract, then gives up all of its powers ``` ## Components Each vault is made of the contracts below. The "One per" column shows how many of each a vault has. | Component | One per | What it does | | --- | --- | --- | | Vault | vault | The ERC-20 share token. It takes deposit and redemption (withdrawal) requests, settles them at NAV, charges fees, lists sub-accounts and runs forced exits. It holds idle USDC. | | Deposit silo | vault | Holds USDC from pending deposit requests. Pending deposits are not part of NAV until they settle. | | NAV oracle | vault | Calculates NAV: the vault's idle USDC plus each sub-account's value. It stores nothing and has no admin. | | [Tracked sub-account](https://docs.tango.fun/vaults/tracked-sub-accounts.md) | strategy | Holds registered tokens and positions. It acts only through installed modules, and is valued from balances and oracle prices. | | [Attested sub-account](https://docs.tango.fun/vaults/attested-sub-accounts.md) | strategy | Reaches offchain venues through approved call shapes (approved transaction types). It is valued from a reported figure, used only inside a set range called the deviation band. | | Modules | tracked sub-account | Swap, ERC-4626 lending and concentrated liquidity. They hold nothing between calls. | | Asset registry | vault | Lists which assets each tracked sub-account may hold. | | Price oracle | vault | Points each asset to its pricing adapter (Chainlink, two-feed Chainlink, tokenized-equity, ERC-4626, liquidity position). | | Policies | vault or sub-account | The deposit cap, each sub-account's allocation cap, rate limits on how fast money moves, and slippage ceilings on trades. | | Fee splitter | vault | Receives fees as shares and splits them between the platform, the primary recipient and any other beneficiaries. | | Deposit handler | vault | An optional one-transaction deposit, for vaults without attested sub-accounts. | | Share locker | vault | Optional time locks on shares. | | AccessManager | vault | Holds every restricted function's role and timelock. | Every contract is either a clone that cannot be upgraded or a plain deployment. Nothing can be upgraded in place. ## How a dollar moves 1. A depositor requests a deposit, and their USDC waits in the deposit silo. 2. The vault's settler (whoever holds the role to settle requests) settles the request at the current NAV. The USDC becomes idle cash in the vault, and the vault mints the depositor's shares. 3. The manager sends USDC to a sub-account, within that sub-account's cap and rate limit. 4. The sub-account swaps, lends, provides liquidity or reaches an offchain venue, within its limits. 5. To pay redemptions, the manager brings USDC back from a sub-account to the vault. Money never moves directly from one sub-account to another. 6. A holder requests a redemption, and the settler settles it from idle cash at the current NAV. The holder then claims their USDC. See [Deposits](https://docs.tango.fun/vaults/deposits.md) and [Withdrawals](https://docs.tango.fun/vaults/withdrawals.md) for the full flows. ## How value is measured The vault calculates NAV onchain every time it needs the figure, and never stores an old one to reuse. NAV is: - the idle USDC in the vault, counted from the vault's own records rather than its token balance, so tokens sent to it without being asked do not move NAV; - plus each tracked sub-account's registered tokens and positions, at oracle prices; - plus each attested sub-account's accepted value; - minus fees earned but not yet minted as new shares. A price is stale when it is too old to trust. If any input is stale, the whole NAV is stale, and settlement pauses until it is fresh again. See [Sub-accounts and NAV](https://docs.tango.fun/vaults/sub-accounts.md). ## Contract releases A contract release is a fixed version of the vault's contract code. Each vault is deployed from a factory for one release, and keeps that release for its whole life. | Release | Status in the Tango app | Notable changes | | --- | --- | --- | | 0.5.0 | Previous release: no new deposits, withdrawals continue | The first release. It had no timelocks, and the share locker had an owner who could release locks early. | | 0.10.0 | Previous release | Timelocks (3, 7 and 14 days), clearer profiles, the Sentry and a two-feed price adapter. | | 0.12.0 | Used for new strategies | NAV providers with a guardian, invalidation that holds until the guardian acts, concentrated liquidity, a share locker with no owner, and up to 3 sub-accounts per vault. | | 0.13.0 | Not yet used | Signed atomic deposits, opt-in atomic redemptions, and separate Settler and Trader profiles. | These docs describe release 0.12.0 unless a page says otherwise. --- # 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 share price. Source: https://docs.tango.fun/vaults/sub-accounts 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. > - There are two kinds of sub-account. Tracked sub-accounts are valued from onchain prices. Attested sub-accounts are valued from a reported figure that must stay within strict limits. ## Why sub-accounts A strategy often does several things at once. It might hold tokens, lend USDC on Morpho 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 permission to act, 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 ```text Vault idle USDC: counted from the vault's own records, not its token balance Tracked sub-account: each registered asset's quantity times its oracle price, converted to USDC Attested sub-account: the last accepted reported value, adjusted exactly for USDC sent in or brought back since Accrued fees: management and performance fees earned but not yet paid out, subtracted Vault NAV = idle USDC + tracked values + attested values - accrued fees Share price = NAV / total shares Not counted: pending deposits, USDC already owed to settled withdrawals, tokens sent to any contract without being asked for ``` 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. If someone sends tokens to a vault without being asked, the NAV does not change. Nobody can move the share price by donating 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: | Paused | Still works | | --- | --- | | Settling deposits and withdrawals | Requesting a deposit or a withdrawal | | Forced exits | Cancelling a request | | One-transaction (atomic) deposits | Claiming requests that were already settled | | 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](https://docs.tango.fun/app/tokenized-stocks.md). ## Tracked and attested | | Tracked sub-account | Attested sub-account | | --- | --- | --- | | Valued from | Quantities of registered assets times oracle prices | A reported value, used only within a set range | | Acts through | Built-in modules for swapping, lending and liquidity | A short list of approved transaction types, such as a bridge transfer | | Can hold | Only registered assets count | Anything; the report values the whole account | | Can borrow | No | Yes, through approved transactions | | Each action is checked by | An oracle price check plus policy limits | The approved-transaction list; the next report shows the result | | Reachable by a forced exit | Yes | No | | One-transaction deposits | Allowed | Turned off for the whole vault | Read more in [Tracked sub-accounts](https://docs.tango.fun/vaults/tracked-sub-accounts.md) and [Attested sub-accounts](https://docs.tango.fun/vaults/attested-sub-accounts.md). ## How many, and when they are added - Every vault has a maximum number of sub-accounts, fixed when it is deployed. Factories on release 0.12.0 allow up to 3. - Sub-accounts are usually added when the vault is deployed, through the [factory](https://docs.tango.fun/vaults/factory.md). - Adding one later is a Critical-level change, which waits 14 days on Tango's production factories. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md). - Removing one takes two steps. It is marked for removal right away, and removed once it holds nothing. NAV does not change at either step. ## Limits on capital | Limit | What it caps | To raise it | To lower it | | --- | --- | --- | --- | | Allocation cap | How much USDC can be sent to a sub-account, minus what it has sent back. Gains do not count against it. | High-level change (7 days), and never above a ceiling fixed at deployment | Immediate | | Sending limit | How fast USDC can be sent in, like a bucket that refills over time | High-level change (7 days) | Immediate | Both start at zero, which blocks everything until they are set. See [Rate limits](https://docs.tango.fun/vaults/rate-limits.md) for how these limits work and which settings can be adjusted. --- # Tracked sub-accounts > How tracked sub-accounts hold only registered assets, price each one with an oracle, and check every swap, loan and liquidity move against oracle prices. Source: https://docs.tango.fun/vaults/tracked-sub-accounts A tracked sub-account is the part of a vault that holds tokens the vault can price onchain. It may hold only assets on an approved list, it prices each one with an onchain price feed, and it acts only through a few built-in tools. Because every asset it can hold has a price, its value can be worked out entirely onchain. That value counts toward the vault's NAV (net asset value), the total value of everything the vault holds. > **Key points** > > - A tracked sub-account can only hold assets listed in its vault's asset registry. Anything else is never recorded and never counted. > - An oracle adapter prices every registered asset. If a price goes stale, the vault's NAV goes stale and settlement pauses. > - The sub-account acts only through modules. After each action, it measures what it actually spent and received, prices both with the oracle, and reverts if the loss is above a fixed ceiling. ## The asset registry Each vault has one asset registry: for every tracked sub-account, it lists the assets that sub-account may hold. USDC is always registered. An asset is in one of three states, and it only ever moves forward through them: | State | Can be acquired | Can be spent | Counted in NAV | | --- | --- | --- | --- | | Unregistered | No | No | No | | Registered | Yes | Yes | Yes | | Deregistering | No, except when unwinding a position into it | Yes | Yes | To register an asset, its balance must be readable, and its oracle must price one whole unit at a fresh price above zero. Registering is a Critical-tier action, the longest timelock, so on Tango's production factories it waits 14 days. Deregistering an asset takes two steps. Starting it is immediate, and from then on the sub-account may only reduce that asset. Finishing it requires a tracked balance of exactly zero. NAV does not change at either step, so nobody can use deregistering to reprice redemptions that are waiting to settle. Each sub-account has a maximum number of registered assets, set when the vault is deployed. ## Only registered assets This rule is what makes the valuation complete. Every asset the sub-account can hold has an oracle price, and nothing else can enter NAV. A tracked sub-account cannot hold anything outside its registry in any way that matters: - It cannot acquire one, because every output of every action must be a registered asset or the action reverts (fails and is undone). - It cannot spend one, because every input must be a registered asset, within the quantity the sub-account has tracked. - It does not count one, because NAV is calculated from the tracked quantities of registered assets, not from token balances. - Tokens sent straight to the sub-account without being asked are not tracked and sit outside NAV. They can only leave through the admin's rescue function, which is limited to the untracked amount. ## Oracles An oracle is an onchain price feed. The vault's price oracle maps each registered asset to an adapter, a small contract that knows how to price that kind of asset, along with its settings. Binding (connecting) an adapter is Critical tier. Removing one is immediate, except for USDC's. | Adapter | Prices | | --- | --- | | Chainlink | An asset with a USD price feed | | Chainlink two-feed | An asset priced by multiplying two feeds, such as WBTC/BTC times BTC/USD | | Tokenized equity | A tokenized stock with a Chainlink feed. It also checks the issuer's registry for pauses and corporate-action multipliers. | | ERC-4626 | Shares in another vault, at what they redeem for, priced through the underlying asset's feed | | Concentrated liquidity | A liquidity position, at the token amounts implied by oracle prices plus its fees, never at the pool's own price | ### When a price is stale A price is stale when it is too old or too broken to trust. A Chainlink reading is stale when: - the answer is zero or negative; - it was carried over from an older round (an earlier update); - its timestamp is zero or in the future; - it is older than the feed's heartbeat (its promised update interval) plus 90 seconds. On Base and other layer 2 networks, every price is also stale while the network's sequencer is down, and for one hour after it comes back. The sequencer is the service that orders the network's transactions. A stale price for an asset the sub-account holds makes the whole vault NAV stale, which pauses settlement (see [When NAV is stale](https://docs.tango.fun/vaults/sub-accounts.md#when-nav-is-stale)). An asset with a zero balance is skipped, so a dead feed for something the vault does not hold does not stop it. ## Modules A module is a built-in tool for one kind of action, such as swapping. A tracked sub-account acts only through the modules installed on it. Installing a module is Critical tier; removing one is immediate. | Module | Does | Bounded by | | --- | --- | --- | | Swap | Swaps one registered asset for another through a router | An oracle check at the swap policy's slippage ceiling, plus per-asset rate limits in and out | | ERC-4626 lend | Supplies to and withdraws from ERC-4626 vaults, such as Morpho vaults | An oracle check at the lend policy's ceiling, plus a supply rate limit for each venue | | Concentrated liquidity | Adds and removes Uniswap V3 and V4 liquidity positions | An oracle check on the whole position's value, plus its own ceiling and rate limits | A slippage ceiling is the most any single action may lose against oracle prices. A rate limit caps how much can flow in or out over time, like a bucket that refills. Modules hold nothing between calls. They cannot borrow or loop (borrow against a position to build a bigger one), because the debt would be invisible to a NAV built from token quantities. ### How an action is checked For each action, the manager names a tolerance: the most value this action may lose against oracle prices. It can be no higher than the policy's slippage ceiling. The sub-account then checks the result itself, after the action runs. ```text Manager -> Sub-account: execute a module with inputs, expected outputs and a tolerance Policy check: the tolerance must be at or below the policy's fixed slippage ceiling Sub-account -> Module: hand over the inputs Module -> Router or venue: perform the swap, supply or liquidity change Module -> Sub-account: send back every asset; the module must end holding nothing Sub-account: measure what was spent and received from its own balance changes, not from what the module reports Oracle check: value received must be at least value spent times (1 - tolerance), at oracle prices read after the action Rate limits: spent and received amounts are charged to the outbound and inbound buckets Any stale price, excess loss or empty bucket reverts the whole action ``` The check happens after the action, using the sub-account's own balances. It works like a minimum output priced by the oracle. A route that loses more than the tolerance against oracle prices reverts, whatever the router claims. Each policy's slippage ceiling is fixed when the policy is created. Changing it means binding a new policy, which is Critical tier. ### Limits that remain - The ceiling applies to each action on its own. Repeated actions can each lose up to the tolerance. The rate limits cap how much value can pass through in a window, but there is no total loss budget. - Lending positions are valued at the venue's own `convertToAssets` figure. A venue that misreports its share price would misstate NAV. That is why lending venues are reviewed before they are admitted. - A lending venue is admitted only by giving it a supply bucket above zero. It must also be a registered asset with an ERC-4626 adapter. --- # Attested sub-accounts > How attested sub-accounts reach offchain venues through approved transaction types, and how the reported value behind their NAV is limited, checked and frozen. Source: https://docs.tango.fun/vaults/attested-sub-accounts Some strategies use venues that a contract cannot see, such as an account on a perps exchange. An attested sub-account is the part of a vault that reaches those venues. The vault cannot read that balance itself, so the account's NAV (net asset value) comes from a figure that a separate service reports, called an attestation. Strict rules decide when the vault will use that figure. > **Key points** > > - An attested sub-account holds money that cannot be valued onchain, such as an exchange account or funds on another chain. > - It can only make transactions that match its call shapes, a short list of approved transaction types. Approving a new shape takes 14 days on Tango's production factories. > - Its value comes from a NAV provider. A figure is used only if it was observed after the account's latest activity, is fresh, and falls inside a deviation band (a set range around a reference value). > - A drop below the band freezes the account until a guardian re-anchors it. Nobody can set the value directly. ## When an attested sub-account is used Tracked sub-accounts can only hold tokens the vault can price onchain. Some strategies need venues that live elsewhere, such as a perps exchange account, an options account or money moving between chains. A contract on the vault's chain cannot read those balances. An attested sub-account covers that case. Everything that can be valued onchain still is, and only the offchain part is attested. ## Approved call shapes An attested sub-account has no modules. Instead, it makes direct calls, and each call must match an approved shape in its verifier. A call shape is an approved transaction type: it describes exactly which contract may be called, which function, and with which arguments. The verifier is the contract that checks every call against those shapes. - A shape fixes the target contract, the ETH value and the function selector (which function is called) exactly. - Arguments can be fixed byte by byte or left open, and which bytes are open is part of the shape. A wider shape counts as a different shape, and needs its own approval. - Approving a shape is Critical tier (14 days on Tango's production factories), except for the first shapes approved during deployment. Revoking a shape is immediate. In the Tango app, the perps sub-account has exactly two shapes. One approves USDC to Circle's bridge, and the other sends USDC through it to the strategy's own trading account. See [Bridging](https://docs.tango.fun/vaults/bridging.md). The verifier checks each call on its own. It cannot stop approved calls from being repeated or combined. An approval (permission to spend) granted to a third party also outlives the shape's revocation. That is why shapes are kept narrow. ## Where the value comes from Each attested sub-account reads its value from a NAV provider contract. The diagram shows the checks a reported value must pass before the vault uses it. ```text Offchain venue: balances the vault cannot read onchain NAV manager (attester) -> NAV provider: attest(value, observedAt), the account's whole net worth in USDC Attested sub-account -> NAV provider: read the latest attestation (gas capped) Check 1: observed after the last USDC sent in or brought back and the last call batch (plus the stale period after calls) Check 2: not older than the heartbeat Check 3: inside the deviation band around the window's anchor Within band: accepted and used in vault NAV Above band: ignored; the last accepted value stands Below band: account invalidated and held until the NAV guardian re-anchors ``` Three separate keys share the work: - **NAV managers** post attestations. Each attestation is a value and the time it was observed. The value is the account's whole net worth in USDC, including USDC it holds directly, and is never below zero. - **The NAV admin** appoints and removes NAV managers. It is fixed when the provider is created. - **The NAV guardian** can invalidate (freeze) the account's NAV and re-anchor it. It cannot post attestations. Keeping these keys separate matters. A key that could both attest and re-anchor could set any NAV. Any contract that implements the provider interface can be used, such as an oracle network's feed. Replacing the provider is Critical tier. ## Safeguards These safeguards decide when the vault will use a reported value. Each attested sub-account has four settings, fixed when it is created: | Setting | What it does | Bounds | | --- | --- | --- | | Deviation band | How far a new value may move from the window's anchor (its reference value) and still be used | Above zero | | Deviation window | How often the band's anchor can roll forward | At least the heartbeat | | Heartbeat | How old an accepted value may be before NAV is stale | Above zero, at most 7 days | | Stale period after calls | How long NAV stays stale after the account makes calls | Below the heartbeat | The vault applies these rules to every reading: - A reading counts only if it was observed after USDC was last sent in or brought back, and after the last accepted value. It must also come after the last call batch plus the stale period. A reading taken before the account's latest activity can never be used. - After the account makes calls, its NAV stays stale until a reading from after the stale period arrives. Nobody can settle deposits or redemptions against a value that predates the account's own trades or transfers. - USDC sent in or brought back is added or subtracted exactly, so moving money does not need a new attestation. - A value above the band is ignored, and the last accepted value stands. A sudden gain is not recognised until it is confirmed inside the band. - A value below the band invalidates the account and keeps it invalidated. The vault's NAV stays stale until the guardian re-anchors to a specific reading the provider has posted. The re-anchor opens a new band, and the next reading inside it is used. - No function sets the account's value. Every accepted value comes from the provider's posted readings. ### While the account is invalidated or stale - The vault's NAV is stale, so settlement and forced exits pause (see [When NAV is stale](https://docs.tango.fun/vaults/sub-accounts.md#when-nav-is-stale)). - USDC cannot be sent into an invalidated account. - The account brings nothing back to the vault while it is stale. While it is fresh, it brings back at most the lesser of its USDC balance and its NAV. - Approved calls still run, so positions can be reduced. ## What it means for deposits and withdrawals - While any attested sub-account is listed, the vault refuses one-transaction (atomic) deposits. See [Why not atomic](https://docs.tango.fun/vaults/deposits.md#why-atomic-deposits-are-off-with-an-attested-sub-account). - A forced exit pays from the vault and its tracked sub-accounts only. It never reaches an attested account. - Every deposit and withdrawal is settled by the vault's settler after a fresh value is accepted. ## What attestation does not protect against An attested value is a figure someone posted. The band, the freshness rules and the guardian limit how far and how fast it can move. Even so, a NAV manager can post any value inside the band. Depositors in a vault with an attested sub-account rely on the attester as well as the contracts. For the Tango app, [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md) describes how often values are posted and what is checked before posting. --- # Rate limits > How Tango vaults limit how fast money can move into sub-accounts, through swaps, into lending and into liquidity positions, and which settings can be adjusted. Source: https://docs.tango.fun/vaults/rate-limits A rate limit caps how much money can move along one path in a vault over a period of time. Tango vaults use them so that even a key with permission to act cannot move a strategy's whole balance at once. Each limit works like a bucket that refills: every move takes from it, it fills back up at a set rate, and a move larger than what is left is refused. > **Key points** > > - Rate limits can cover USDC sent into sub-accounts, swaps, supplies to lending venues and changes to liquidity positions. Each has its own bucket for each sub-account, and for each asset or venue. > - Every bucket has two settings, a capacity and a refill rate. They can be set differently for each direction of each asset, so moves towards cash can be allowed more room than moves that add exposure. > - Some moves are never limited, such as withdrawing from a lending venue or bringing USDC back to the vault. Deposits and withdrawals have no rate limit. > - Raising a limit is a timelocked change. Lowering a limit, or closing it to zero, takes effect immediately. ## How a bucket works Each bucket has two settings: - its capacity, which is the most that can move before the bucket has to refill; - its refill rate, which is how much room comes back each second. Say a bucket has a capacity of 100 and refills completely over a day. If a swap uses 60, there are 40 left, and room comes back steadily until the bucket is full again. A swap of 50 straight after the first one would be refused, and the whole swap would revert. Because a full bucket can be emptied and then used again as it refills, up to twice the capacity can pass through in the time the bucket takes to refill. That is the most a limit ever allows. Every bucket starts at zero, which refuses everything until a limit is set. A bucket can also be set to unlimited, which turns it off. ## What can be limited | Path | One bucket for each | What uses it up | What is never limited | | --- | --- | --- | --- | | Sending USDC from the vault to a sub-account | Sub-account | Each amount sent | Bringing USDC back from the sub-account to the vault | | Swaps | Sub-account and asset, one bucket for each direction | What actually left and arrived, measured after the swap | Nothing in a swap is exempt | | Lending | Sub-account and lending venue | Each amount supplied to the venue | Withdrawing from the venue | | Liquidity positions | Sub-account and asset, one bucket for each direction | Tokens put into a position and taken out of it | Nothing in a liquidity change is exempt | Swaps and liquidity changes are charged from the amounts that actually moved, not the amounts a manager asked for. A swap that spends less than its maximum only uses up what it spent. A swap uses two buckets at once. Swapping USDC for WETH takes from the USDC outbound bucket and the WETH inbound bucket. Swapping WETH back into USDC takes from the WETH outbound bucket and the USDC inbound bucket. Both must have room, or the swap reverts. Because each direction has its own bucket, a vault can give moves towards cash, such as selling an asset back into USDC, more room than moves that add exposure, such as buying an asset. Moves towards cash are the ones a manager needs to pay withdrawals or to leave a position that is going wrong. Withdrawals from a lending venue are never limited, so a strategy can always leave a venue. If a venue goes bad, its supply bucket can be lowered to zero, which stops new supplies while withdrawals keep working. A holder's [forced exit](https://docs.tango.fun/vaults/withdrawals.md#forced-exit) does not use these buckets. When it unwinds a position through the onchain account's modules, these limits do not hold it back. The reported value of an [attested sub-account](https://docs.tango.fun/vaults/attested-sub-accounts.md#safeguards) has a limit of its own. A new value can only move within its deviation band in each window, which caps how fast that account's value can change. ## Deposits and withdrawals Deposits and withdrawals have no rate limit. Other settings bound them instead: - The [deposit cap](https://docs.tango.fun/vaults/deposits.md#deposit-cap) limits the total a vault accepts, after withdrawals. - The settlement batch size limits how many requests the settler can settle in one transaction. - The minimum deposit and minimum withdrawal set the smallest request the vault accepts. ## The levers | Setting | Set for each | To raise it | To lower it | | --- | --- | --- | --- | | Bucket capacity | Bucket | VaultAdmin, High tier timelock | Sentry or VaultAdmin, immediately | | Bucket refill rate | Bucket | VaultAdmin, High tier timelock | Sentry or VaultAdmin, immediately | | Allocation cap, the most USDC a sub-account can hold from the vault | Sub-account | VaultAdmin, High tier timelock, never above a ceiling fixed at deployment | Sentry or VaultAdmin, immediately | | Deposit cap | Vault | VaultAdmin, High tier timelock, never above a ceiling fixed at deployment | VaultManager, Sentry or VaultAdmin, immediately | | Settlement batch size | Vault | Fixed at deployment | Fixed at deployment | | Minimum deposit and withdrawal | Vault | Fixed at deployment | Fixed at deployment | Closing a bucket to zero is the quickest way to stop one path, such as new supplies to a lending venue, while everything else keeps working. Setting a bucket to unlimited is only possible while its refill rate is zero. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md) for how long each tier waits, and [Roles and profiles](https://docs.tango.fun/vaults/roles.md) for who holds each role. In the Tango app, the limits are set when a strategy is deployed, and the app does not offer raising them afterwards. See [Fixed configuration](https://docs.tango.fun/app/fixed-configuration.md). --- # Deployment through the factory > How the Tango vault factory builds and connects a vault in stages, what is fixed forever at deployment, and how the factory gives up its powers. Source: https://docs.tango.fun/vaults/factory Every Tango vault is built by a factory: a contract that deploys all of a vault's parts and connects them. The factory checks every limit the creator asks for against its own maximums, hands control to the vault's own roles, and then gives up all of its powers. Deployment is also when a vault's permanent limits are set, so it shapes what can and cannot change later. > **Key points** > > - Every Tango vault comes from a factory for one contract release. The factory deploys every contract, sets up every role, then gives up all of its own powers. > - Ceilings such as maximum fees, the maximum number of sub-accounts and the deposit cap's ceiling are fixed at deployment and can never be raised. > - The deployer cannot be the vault's admin, and nothing is upgradeable. ## How a vault is deployed The factory's deployer builds a vault in four stages. The vault stays paused until the last one, called finalize. ```text 1. Deploy: clone the vault, price oracle, asset registry, policies, fee splitter, handlers and share locker; check every limit against the factory's maximums. The vault starts paused. 2. Add sub-accounts: tracked sub-accounts with their modules, assets, caps and rate limits; attested sub-accounts with their verifier and NAV provider. 3. Approve first call shapes: attested sub-accounts get their first shapes with no delay, before any role is set up. 4. Finalize: requires at least one sub-account, unpauses the vault, installs every role and timelock, and the factory gives up all of its powers. After finalize: the vault is live, and every later change goes through the vault's own roles and timelocks. ``` 1. The factory deploys by cloning (creating new instances of) the vault and its supporting contracts. It checks every requested limit against its own maximums. Each address is derived from a salt (a value the deployer picks) and the deployer, so nobody can deploy to those addresses first. 2. The factory creates the tracked sub-accounts with their modules, registered assets, caps and rate limits. Attested sub-accounts get their verifier and NAV provider. 3. Attested sub-accounts receive their first call shapes (approved transaction types). This is the only time shapes can be approved without a timelock. 4. The factory finalizes the vault. It checks that there is at least one sub-account, unpauses the vault and installs every role at its timelock. It then renounces (gives up) its admin roles. Finally, it checks that neither it nor the installer, the helper contract that set up the roles, still holds any admin role. ## What the creator chooses At deployment, the creator chooses settings in five groups. Some are permanent limits. Others are starting values that can change later, within those limits. | Group | Examples | | --- | --- | | Identity | Name, symbol, the underlying asset (USDC) | | Limits (permanent) | Fee ceilings, deposit cap ceiling, sub-account cap ceiling, maximum sub-accounts, maximum assets per sub-account, settlement batch size, minimum deposit and redemption, lock duration bounds | | Starting settings | Deposit cap, fee rates, whether atomic deposits are on, platform fee | | Profiles | Who holds the VaultAdmin, VaultManager, Settler, Trader, Sentry, NAV guardian and NAV admin roles; who receives platform fees | | Sub-accounts | Each sub-account's type, assets, modules, caps, rate limits, slippage ceilings and, for attested ones, call shapes and attestation settings | ## Fixed forever After deployment, these can never change: - the name, symbol and underlying asset; - every fee ceiling, and the round-trip fee ceiling; - the maximum number of sub-accounts, the settlement batch size, the minimum deposit and redemption, and the forced-exit wait; - the deposit cap's ceiling and each sub-account's allocation ceiling; - each policy's slippage ceiling; - each attested sub-account's band, window, heartbeat and stale period, and its provider's NAV admin; - the share locker's minimum and maximum lock durations; - the timelock tiers in the factory's roles table. Values inside those ceilings, such as the current deposit cap or fee rates, can change through the vault's roles and [timelocks](https://docs.tango.fun/vaults/timelocks.md). Changing a ceiling means deploying a new vault. ## Factory guarantees The factory enforces these rules for every vault it deploys: - The factory refuses to deploy a vault whose admin is the deployer itself. - After finalize, the factory and the installer hold no role on the vault. - Every limit must sit at or below the factory's maximums. For example, entry, exit and one year of management fees together cannot be more than the round-trip ceiling. - A factory with timelocks requires its High delay to be at least twice the forced-exit wait. See [Exit before governance](https://docs.tango.fun/vaults/timelocks.md#exit-before-governance). - From release 0.13.0, the factory refuses to finalize a vault that turns on atomic (one-transaction) redemptions alongside an attested sub-account. ## Adding a sub-account later The contracts let a vault's admin add sub-accounts after deployment, up to the vault's maximum. Expansion kits create and initialise (set up) the new contracts in a single step, so nobody else can initialise them first. Connecting them to the vault uses Critical-tier actions: adding the sub-account, installing modules, registering assets and approving shapes. So on Tango's production factories, the change takes at least 14 days. Adding an attested sub-account to a live vault immediately turns off atomic deposits for the whole vault. The Tango app does not offer additions after deployment. See [Fixed configuration](https://docs.tango.fun/app/fixed-configuration.md). --- # Roles and profiles > Who can do what in a Tango vault, what each profile can and cannot do, and the keys that sit outside the vault's access manager. Source: https://docs.tango.fun/vaults/roles A Tango vault decides who may do what through roles and profiles. A role is the permission to call one restricted function. A profile is a fixed bundle of roles for one job, such as the admin, the day-to-day manager or the emergency brake. Knowing the profiles tells a depositor who can change a vault, and how fast. > **Key points** > > - Every restricted function has its own role in the vault's AccessManager, and roles are bundled into profiles. > - The VaultAdmin holds every role, each behind its timelock. The VaultManager runs the vault day to day, and can hand settling or trading to narrower Settler and Trader keys. > - The Sentry can only apply brakes, and the NAV guardian can only freeze and re-anchor attested values. > - No profile can upgrade the contracts or set a NAV value directly. None can move money anywhere except between the vault, its sub-accounts and the venues they are allowed to use. ## How access works Each vault has one OpenZeppelin AccessManager, a standard contract that controls who can call what. Every restricted function on every contract in the vault has its own role, and each role has: - a **tier**, which sets its timelock, the delay before the action can run (see [Timelocks](https://docs.tango.fun/vaults/timelocks.md)); - a **direction**: it increases risk, reduces risk or is neutral; - a **scope**: either one role for every instance of a contract type, or one per instance, as with each sub-account's execute role. A **profile** is a fixed bundle of roles. Profiles are assigned when the vault is deployed. Profiles run by automation use an owned multicall contract, which lets one key batch several actions together. Its owner never changes, and a key that is both a Settler and a Trader gets a single multicall for both. This page describes the latest contract code. Strategies deployed on release 0.12.0 have a single Operator profile instead of the Settler and Trader, which can settle, send and bring back USDC, and execute on sub-accounts. They also have no withdrawal handler or signed handlers. ## Profiles Each profile has one job. The table gives the short version, and the sections below list what each one can and cannot do. | Profile | Its job | | --- | --- | | VaultAdmin | The top authority | | VaultManager | Runs the vault day to day | | Settler | Settles deposit and withdrawal requests | | Trader | Trades on the sub-accounts it is named for | | Sentry | Applies brakes | | NAV guardian | Guards reported values for attested sub-accounts | | Deposit and withdrawal handlers (contracts) | Perform one-transaction deposits and redemptions | ### VaultAdmin The VaultAdmin is the top authority. It holds every role in the vault, each at its own timelock, along with the AccessManager's admin roles: - It is the admin of the AccessManager itself, at the Critical delay. Granting a new admin also waits the Critical delay, so someone who took over the VaultAdmin key would need two Critical windows to replace it, which gives holders time to leave. - It can cancel any scheduled operation, including one a VaultManager scheduled. - It can grant or revoke any role that has no delay, at once. That lets it remove a compromised key's routine permissions immediately, and add a Settler or Trader immediately. - It can unpause, and add sub-accounts, modules, assets, oracles and call shapes, each after its timelock. - It can rescue tokens sent to the vault without being asked. It cannot skip a timelock or upgrade contracts. It also cannot set an attested value directly, or release locked shares early. ### VaultManager The VaultManager runs the vault day to day, through its own multicall. It can: - settle deposits and redemptions; - add USDC to the vault as a donation that counts towards its value; - send USDC to sub-accounts and bring it back; - execute modules and approved calls on every sub-account; - raise any fee within its ceiling at the Medium tier, and lower any fee immediately; - lower the deposit cap; - deregister assets; - pause any deposit or withdrawal handler; - edit the fee splitter's secondary beneficiaries, within their cap; - grant or revoke the Settler's roles and any sub-account's execute role, immediately. That last power reaches every holder of those roles, including other VaultManagers, the handlers and the VaultAdmin. The VaultAdmin can always grant itself a revoked role back and take this power away from the VaultManager at once. The VaultManager cannot unpause anything or rescue tokens. It also cannot add sub-accounts, assets, modules, oracles, call shapes or signers, or raise caps or rate limits. ### Settler A Settler is a key for an automation service, an agent or an integrator that settles requests. It can decide which deposit and withdrawal requests are filled, and by how much. It cannot move money between the vault and its sub-accounts, trade, change fees, caps or the fee split, or pause anything. ### Trader A Trader is a key that trades on specific sub-accounts. It holds the execute role only on the sub-accounts whose configuration names it, so it can run modules or approved calls there. It cannot settle requests, move money in or out of a sub-account, or do anything else. ### Sentry The Sentry is an emergency brake. It can: - pause the vault, any sub-account and any deposit or withdrawal handler; - remove a signer from a signed handler, which is permanent; - lower any rate limit, any sub-account's allocation cap and the deposit cap. It cannot unpause, raise anything or move money. A vault can be deployed without a Sentry, in which case only the VaultAdmin holds these brakes. ### NAV guardian The NAV guardian guards the reported values of attested sub-accounts. It can invalidate (freeze) an attested sub-account's NAV, and re-anchor it to a reading the provider has posted. It cannot post an attestation, or choose a value of its own. ### Deposit and withdrawal handlers The handlers are contracts, not people. A deposit handler performs one-transaction deposits, and can settle only the single deposit request it just opened. A withdrawal handler performs one-transaction redemptions, and can settle only the single redemption it just opened, in full. Signed versions of each also require an approved signer's signature. See [Deposits](https://docs.tango.fun/vaults/deposits.md) and [Withdrawals](https://docs.tango.fun/vaults/withdrawals.md). ## Keys outside the AccessManager A few keys live in other contracts, outside the vault's AccessManager. Each has a narrow job. | Key | Lives in | Can | | --- | --- | --- | | NAV admin | Each attested sub-account's NAV provider | Decide who may report values, by appointing and removing NAV managers. It is fixed when the provider is created. | | NAV managers | The NAV provider | Post attestations (reported values). Each one is a value and the time it was observed, and must be observed later than the last. | | Platform fee recipient | The fee splitter | Set the platform's share of fees, up to the hard cap of 5% of fee inflows, and change where it is paid. | | Fee recipient | The vault | This is the fee splitter itself. Changing it is Critical tier. | ## Who can freeze what Brakes act immediately, but only the VaultAdmin can release them, and only after a delay. | Action | Who | Delay | | --- | --- | --- | | Pause the vault (stops new requests and sending USDC to sub-accounts) | Sentry, VaultAdmin | Immediate | | Pause a sub-account (stops sending and execution; bringing USDC back still works) | Sentry, VaultAdmin | Immediate | | Pause a deposit or withdrawal handler | VaultManager, Sentry, VaultAdmin | Immediate | | Remove a signer from a signed handler | Sentry, VaultAdmin | Immediate, and the signer can never be added back | | Lower the deposit cap | VaultManager, Sentry, VaultAdmin | Immediate | | Invalidate an attested NAV | NAV guardian, VaultAdmin | Immediate | | Unpause anything | VaultAdmin only | High tier (7 days on Tango's production factories) | Pausing the vault does not stop settlement, claims, cancellations, bringing USDC back or forced exits. But a holder who has not yet requested a redemption cannot start one until the vault is unpaused. ## What no one can do No profile can: - upgrade any contract, because nothing sits behind a proxy (the usual way to make a contract upgradeable); - set an attested sub-account's value, because values only come from posted readings that pass the [band and freshness checks](https://docs.tango.fun/vaults/attested-sub-accounts.md#safeguards); - make a tracked sub-account hold or count an unregistered asset; - move a tracked sub-account's assets anywhere except through its installed modules or back to the vault; - go above a fee, cap or limit ceiling fixed at deployment; - release locked shares before their unlock time, on release 0.12.0 and later. ## What Tango can do on its own This applies to strategies created in the Tango app. Tango deploys each strategy through its factory, and the factory gives up every power once the vault is finalized, so Tango's deployer holds no role on the vault afterwards. The creator's wallet holds the top roles. Tango keeps only a few narrow powers on its own: - Tango is the platform fee recipient. It can set the platform's share of the creator's fees, up to the contract's cap of 5% of fee inflows, and change where that share is paid. The share comes out of fees the vault has already charged, not out of depositors' balances. - On strategies with perps, Tango holds the NAV admin key, so it decides which keys may post values for the Hyperliquid account. Tango's NAV service posts those values. The vault only uses a value that passes its [freshness and band checks](https://docs.tango.fun/vaults/attested-sub-accounts.md#safeguards), and Tango cannot set a value directly. - On strategies with perps, every Hyperliquid action needs Tango's co-signature. Tango can refuse to co-sign, which stops trades and transfers back from Hyperliquid. It cannot trade or move funds there alone, unless the creator has turned on automatic trading for an agent. See [Hyperliquid trading wallets](https://docs.tango.fun/app/venues/hyperliquid-wallets.md). Tango cannot, on its own: - settle deposits or withdrawals, or move USDC between the vault and its sub-accounts; - trade, lend or provide liquidity from the onchain account; - pause or unpause a strategy; - change the creator's fees, caps or rate limits; - add assets, venues, sub-accounts or call shapes; - freeze or re-anchor an attested value, since the creator holds the NAV guardian role; - touch locked shares, or upgrade any contract. ## Trust that remains The VaultAdmin holds broad powers. Its risk-increasing actions are delayed by timelocks, not vetoed. Once the delay passes, it can add assets, modules, sub-accounts and call shapes, or raise caps. The timelocks give depositors time to see a change coming and leave. They do not stop the change. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md). --- # Timelocks > How Tango vaults make changes that add risk wait 3, 7 or 14 days, let changes that reduce risk happen at once, and give depositors time to leave first. Source: https://docs.tango.fun/vaults/timelocks A **timelock** is a waiting period between announcing a change to a vault and making it. Tango vaults put one on most changes that add risk, such as adding a new asset or raising a fee. The scheduled change is public while it waits, so a depositor who disagrees has time to withdraw before it takes effect. Changes that reduce risk do not wait. > **Key points** > > - Changes that add risk must wait. Fee raises wait 3 days, raising limits or unpausing waits 7 days, and adding assets, oracles, modules, call shapes or sub-accounts waits 14 days. > - Changes that reduce risk, such as pausing, lowering a limit or lowering a fee, take effect immediately. > - A depositor whose withdrawal is not settled within 3 days can force their own exit. Every delay of 7 days or more is at least twice that wait. > - A depositor who requests a withdrawal when a change is scheduled can therefore be out before it lands. ## How a timelock works Each vault has an **AccessManager**, the contract that decides who may call each restricted function. Every restricted function has its own role there. A timelock is a delay attached to one of those roles. The role holder cannot make a delayed change straight away. Instead: 1. The role holder schedules the change. The schedule is public onchain, so anyone can see it. 2. The delay passes. 3. The role holder carries out the change. If they do not do so within one week of it becoming ready, the scheduled change expires. A scheduled change can be cancelled by whoever scheduled it, by the VaultAdmin, or by the role's guardian. Every role that increases risk has an admin-level canceller. Two changes to the AccessManager itself also wait behind a delay. One is giving a delayed role to a new holder. The other is letting the VaultAdmin's admin role act faster. ## How long each change waits Every role belongs to a tier, and the tier sets its delay. Tango's production factories use the tiers below for releases 0.10.0 and later. Release 0.5.0 had no timelocks. | Tier | Delay | Used for | | --- | --- | --- | | None | Immediate | Day-to-day running and anything that reduces risk | | Medium | 3 days | Raising a fee, within its fixed ceiling | | High | 7 days | Raising the deposit cap, a sub-account cap or a rate limit; unpausing; resetting the performance fee's high-water mark (at most once a year); adding a signer to a signed handler | | Critical | 14 days | Adding a sub-account, module, asset, oracle adapter, NAV provider or call shape; changing the deposit or holder policy or the fee recipient; admin changes to the AccessManager | A call shape is an approved transaction type for an [attested sub-account](https://docs.tango.fun/vaults/attested-sub-accounts.md). A NAV provider is the contract that supplies an attested sub-account's reported value. The factory's roles table fixes these delays. They cannot be changed for a vault that already exists. ## Which changes wait Every role has a direction. It either increases risk, reduces risk or is neutral. Most changes that increase risk wait, so depositors have time to react. Changes that reduce risk, and routine work, take effect at once. ```text Day 0: the VaultAdmin schedules a change that adds risk (High tier, 7 days) Day 0: a depositor who disagrees requests a redemption Day 3: the forced-exit wait ends; if the request is not yet settled, the depositor can force their own exit Day 7: the earliest the High-tier change can run Day 14: the earliest a Critical-tier change scheduled on day 0 can run Changes that reduce risk (pause, lower a cap, lower a fee, revoke a call shape, invalidate NAV) take effect at once ``` | Direction | Examples | Delay | | --- | --- | --- | | Increases risk | Register an asset, bind an oracle adapter, install a module, approve a call shape, add a sub-account, raise a cap or rate limit, raise a fee, unpause | Medium, High or Critical | | Reduces risk | Pause, lower a cap or rate limit, lower a fee, start deregistering an asset, start removing a sub-account, revoke a call shape, invalidate an attested NAV, remove a signer | Immediate | | Neutral | Settle requests, send USDC to sub-accounts and bring it back, act within existing limits | Immediate | A few actions count as increasing risk but still take effect immediately. Each one is narrowly limited: - **Rescuing tokens** that were sent to a contract without being asked. Only the untracked amount can be rescued. - **Removing an oracle adapter**, the contract that supplies an asset's price. The asset then reads as stale, which pauses settlement instead of mispricing it. - **Re-anchoring by the NAV guardian**, which can only re-anchor to a reading the provider has posted. - **Editing the fee splitter's beneficiaries**, within their fixed cap. ## Exit before governance A depositor can force their own exit if their withdrawal request is still unsettled after the [forced-exit wait](https://docs.tango.fun/vaults/withdrawals.md#forced-exit). The factory requires the High delay to be at least twice that wait. With a 3-day wait, this means: - A depositor who sees a High or Critical change scheduled can request a redemption and wait 3 days. They can then force their own exit before the change can run. - A fee raise (Medium, 3 days) can land inside that window. It can only go up to the fee ceilings fixed at deployment. No change waits for pending redemptions to clear first. The guarantee is time to leave, not a veto. ## Watching for changes The AccessManager emits an event for every scheduled change. The event shows the target contract and the calldata, the encoded call the change will make. Anyone can index these events to see what is coming. In the Tango app, creators are not offered any timelocked change after deployment. See [Fixed configuration](https://docs.tango.fun/app/fixed-configuration.md). --- # Deposits > The three ways to deposit into a Tango vault (settled, atomic and signed atomic), how the price is set, and why atomic deposits are off with an attested sub-account. Source: https://docs.tango.fun/vaults/deposits A deposit turns USDC into shares of a vault. A Tango vault can take deposits in up to three ways. Every deposit is priced at the vault's **NAV** per share at the moment it settles. NAV (net asset value) is the total value of everything the vault holds. Which ways are open depends on the vault's release and on whether it has an attested sub-account. > **Key points** > > - Every deposit is priced at the vault's NAV when it is settled, never when it is requested. > - In a settled deposit, the depositor makes a request and the vault's settler fills it later, in a batch. This way is always available. > - An atomic deposit requests, settles and delivers the shares in one transaction. It only works in vaults with no attested sub-account. > - A signed atomic deposit (release 0.13.0) is an atomic deposit that also needs a signature from an approved signer. ## Three ways to deposit ```text Settled: the depositor requests -> USDC waits in the deposit silo -> the settler settles a batch at NAV -> shares are delivered or claimed Atomic: the depositor calls the deposit handler -> the handler requests, settles that one request and claims, all in one transaction Signed atomic: as atomic, plus an EIP-712 signature from an approved signer naming the depositor, amount, nonce and deadline Atomic and signed atomic deposits are refused while any sub-account is attested ``` | | Settled | Atomic | Signed atomic | | --- | --- | --- | --- | | Transactions for the depositor | One request; shares arrive at settlement | One | One, with a signature obtained beforehand | | Price | NAV at settlement, one price per batch | NAV at that moment | NAV at that moment | | Available with an attested sub-account | Yes | No | No | | Available from | All releases | All releases | 0.13.0 | ## Settled deposits A settled deposit happens in three steps. The **settler** is whichever key settles requests: the VaultManager, a Settler or the VaultAdmin. 1. The depositor requests a deposit by calling `requestDeposit`, or an operator calls it for them. An operator is an address the depositor has approved to act for them. The amount must meet the vault's minimum. The USDC moves to the vault's **deposit silo**, a holding contract where it waits outside NAV. 2. The settler settles a batch of requests, up to the vault's batch size. Settlement first accrues fees, then values the vault. It fills every request in the batch at the same price. 3. Anyone can then deliver settled shares to their owner, so the settler can settle and deliver in one batch. The owner can also claim the shares themselves. ### Deposit cap The deposit cap limits the vault's net principal. Net principal is the deposits settled, minus the redemptions settled and the forced exits paid. The vault accepts every request and applies the cap at settlement. If the requests in a batch add up to more than the room left, each one is filled in proportion and the rest stays pending. The cap can be lowered immediately. Raising it is a [High-tier](https://docs.tango.fun/vaults/timelocks.md) change, and it can never go above a ceiling fixed at deployment. ### Fees at deposit If the vault sets an entry fee, it is taken in shares at settlement. A depositor can cancel a pending request and get back the USDC still waiting. If the vault sets a deposit cancellation fee, that fee is taken first. Both fees are capped by ceilings fixed at deployment. ### How long can a request wait? A pending request has no expiry. It waits until it is settled or cancelled. Before it is settled, it can also be transferred to another address. Settlement needs a fresh NAV. While NAV is stale, requests wait. This happens, for example, while a tokenized stock's price is frozen or an attested value is out of date. See [When NAV is stale](https://docs.tango.fun/vaults/sub-accounts.md#when-nav-is-stale). ## Atomic deposits An atomic deposit does all three steps in one transaction, through a contract called the **deposit handler**. The handler opens a request for the depositor and settles only that request. It requires the request to be filled in full, with at least the minimum number of shares the depositor asked for. It then delivers the shares. The price and the entry fee are the same as a settled deposit at that moment. The vault refuses an atomic deposit when: - the handler or the vault is paused; - NAV is stale; - the room left under the cap would only allow a partial fill; - **any sub-account in the vault is attested**. The handler can also deposit and lock the new shares in the same transaction. See [Share locking](https://docs.tango.fun/vaults/share-locking.md). ## Why atomic deposits are off with an attested sub-account An atomic deposit lets the depositor choose the exact moment their price is set. With tracked sub-accounts, that price comes from oracles. With an [attested sub-account](https://docs.tango.fun/vaults/attested-sub-accounts.md), part of the price is a figure someone posted. A posted value lags behind reality. Suppose the account has gained since its last accepted value. The vault's NAV is then too low for a while. Anyone who could deposit atomically at that moment would get shares too cheaply, at the expense of existing holders. The party posting values could even time this. Settled deposits avoid the problem. The settler decides when to settle, after a fresh value has been accepted. The handler checks for attested sub-accounts on every call, so adding one to a live vault turns atomic deposits off at once. Oracle prices also update in steps, even without attested accounts. So an atomic depositor can sometimes buy into a gain the price feed has not shown yet. An entry fee larger than the typical gap caused by feed lag removes that edge. ## Signed atomic deposits From release 0.13.0, a vault can require a signature for atomic deposits. The signature decides who may skip the queue and deposit at the live price. It does not decide who may deposit at all: the settled path stays open to everyone. - An approved signer signs an EIP-712 message, a standard format for signed data. The message names the depositor, the amount, a nonce (a number that can be used once) and a deadline. The depositor submits it with their deposit. - Each nonce can be used once, and the deadline is enforced. - Adding a signer is a High-tier change. Removing one is immediate and permanent: a removed address can never be added again. - Like any atomic deposit, a signed deposit is refused while the vault has an attested sub-account. The Tango app does not use release 0.13.0 yet. See [Deposits in the app](https://docs.tango.fun/app/deposits.md). --- # Withdrawals > How a withdrawal from a Tango vault is requested, funded, settled and claimed, how a forced exit works, and why there is no atomic withdrawal. Source: https://docs.tango.fun/vaults/withdrawals A withdrawal turns a holder's shares back into USDC. The contracts call it a **redemption**. Most of a vault's money is working in its strategy rather than sitting as cash, so a Tango vault does not pay out instantly. The holder makes a request, and the vault's settler brings back enough USDC. The request is then settled at the vault's NAV (net asset value, the total value of everything the vault holds). If that takes too long, the holder can force their own exit. > **Key points** > > - Withdrawals are settled. The holder requests, the vault's settler brings cash back from sub-accounts and settles at NAV, and the holder receives USDC. > - The vault promises no settlement time. If a request is not settled within 3 days, the holder can force their own exit from the vault's cash and its tracked sub-accounts. > - Release 0.12.0 has no atomic (one-transaction) withdrawals. A vault's cash sits in its strategy. An instant exit would let one holder take cash meant for others, at a price that may already be out of date. ## How a withdrawal works ```text 1. Request: the holder calls requestRedeem; the shares move into escrow in the vault 2. Fund: the settler brings USDC back from sub-accounts to the vault's idle cash 3. Settle: the settler names how many shares to fill for each request; the whole batch gets one NAV price 4. Claim: the USDC is set aside for the holder; anyone can deliver it, or the holder claims it Forced exit: after 3 days unsettled, the holder exits alone from the vault's cash and tracked sub-accounts ``` The **settler** is whichever key settles requests: the VaultManager, a Settler or the VaultAdmin. A withdrawal goes through four steps: 1. The holder requests a withdrawal by calling `requestRedeem`, or an operator calls it for them. An operator is an address the holder has approved to act for them. The shares move into escrow: the vault holds them until the request is settled or cancelled. The request must be worth at least the vault's minimum at the last known price. 2. The settler funds the payout by bringing USDC back from sub-accounts. Settlement pays only from the vault's **idle USDC**, the cash the vault holds itself rather than in its sub-accounts. For example, the settler might sell positions, withdraw from a lending venue or bring funds back from an exchange. 3. To settle, the settler fills each request by naming how many shares to redeem. Every request in the batch gets the same price: NAV at settlement. A request can be filled in part and finished later. If the vault sets an exit fee, it is taken in shares. 4. Once a request is settled, the USDC is set aside for the holder and no longer counts in NAV. Anyone can deliver it to the holder, or the holder can claim it. Redemptions are always paid in USDC, never in the vault's other assets. ### Can a holder cancel? Yes. A holder can cancel the unfilled part of a request and get those shares back. If the vault sets a redemption cancellation fee, it applies only during the forced-exit wait. After that, cancelling is free. ### How long does settlement take? The vault promises no settlement time. It depends on the settler, and on how quickly positions can be turned into USDC, which depends on the venues. Settlement also needs a fresh NAV, so it pauses while any price is stale. The forced exit is the backstop. ## Forced exit If a request is still unsettled 3 days after it was made, the holder can settle it alone. This is a **forced exit**. - Only the request's owner can force it, not an operator. - A forced exit pays from the vault's idle USDC first, then from a tracked sub-account's idle USDC. After that, it pays through one unwind route the holder supplies, meaning a way to turn a position into USDC. An example is selling a position through the sub-account's own modules. - It never reaches an attested sub-account. Funds on an exchange or on another chain are out of its reach. - It charges no exit fee. The holder sets a minimum amount to receive and bears any slippage, the gap between the expected and actual trade price. - Like any settlement, a forced exit needs a fresh NAV. It still works while the vault is paused. The wait is fixed at deployment, and every High and Critical timelock is at least twice as long. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md#exit-before-governance). ## Why there is no atomic withdrawal An atomic withdrawal would pay a holder instantly, in one transaction, at the current NAV. Tango vaults do not offer one in release 0.12.0, for three reasons: - The cash is in the strategy, since most of a vault's value sits in sub-accounts rather than as idle USDC. An instant exit could only pay from idle cash the settler brought back for requests already in the queue. The fastest holder would take it. - The price can be behind, because NAV reflects the last oracle update or the last accepted attestation. Suppose the vault has made a loss it has not seen yet. An instant exit would pay the old, higher price, and the holders who stay would absorb the difference. - With an attested sub-account, part of the price is a claim: a figure someone posted. That account sends nothing back to the vault while its value is stale. An instant exit priced on it would rest on a claim rather than an oracle. Release 0.13.0 adds an optional atomic redemption handler, for vaults whose cash and pricing make it reasonable: - It is deployed paused unless the vault asks for it. - It pays only from idle cash, and it charges its own atomic redemption fee. - It is refused whenever any sub-account is attested. The factory will not finalize a vault that enables it alongside an attested sub-account. The Tango app does not use it. See [Withdrawals in the app](https://docs.tango.fun/app/withdrawals.md). --- # Bridging > How Tango vaults move funds to other chains and venues through attested sub-accounts, and how NAV stays correct while funds are in transit. Source: https://docs.tango.fun/vaults/bridging Some strategies need money somewhere other than the vault's own chain, such as an account on a perps exchange. **Bridging** means moving funds from one chain to another. A Tango vault has no bridge of its own. Funds can only leave through an attested sub-account, using transfers approved in advance. While money is in transit, the vault will not settle deposits or withdrawals until it has a value that counts that money. > **Key points** > > - The vault has no bridge of its own, and every sub-account lives on the vault's chain. > - Funds leave the chain only through an attested sub-account, using call shapes (approved transaction types) set for it. One example is a Circle CCTP transfer to one fixed recipient. > - While funds are in transit, the attested value must count them. The vault's NAV stays stale until it accepts a reading taken after the transfer. ## Which sub-accounts can bridge? A [tracked sub-account](https://docs.tango.fun/vaults/tracked-sub-accounts.md) can only hold registered tokens on the vault's chain, so it never bridges. Bridging is a call that an [attested sub-account](https://docs.tango.fun/vaults/attested-sub-accounts.md) makes. That call must match one of the account's approved call shapes. A call shape can fix a call's arguments byte by byte. So a bridge shape can pin down: - the bridge contract and function; - the destination chain; - the recipient on the other side; - any hook data the bridge forwards, meaning extra instructions it passes on at the destination. The amount can be left open, but the destination cannot. Adding a new route means approving a new shape. That is a Critical-tier change, which waits 14 days on Tango's production factories. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md). ## How NAV stays correct in transit The vault's NAV (net asset value) is the total value of everything it holds. An attested sub-account's part of NAV comes from an **attestation**, a value that an attester posts for the account. While money is moving, it has left the sub-account but has not yet arrived at the destination. ```text Attested sub-account on Base -> Circle CCTP: approve USDC, then burn it with a fixed recipient (an approved call shape) Circle CCTP -> Trading account on the destination venue: minted and credited, usually in seconds Destination venue -> Attested sub-account on Base: withdrawals can only be sent back to the sub-account NAV during transit: the attester counts funds in flight or waits; the vault's NAV is stale until a reading from after the transfer is accepted ``` Three rules keep the value honest during that time: 1. The attester counts everything or waits. An attestation is the account's whole net worth, including funds in transit. If the attester cannot see part of it yet, it must report an earlier observation time or skip the reading. 2. After the account makes a call, such as a bridge transfer, its NAV is stale, meaning too old to use. It stays stale until the vault accepts a reading observed at least the stale period later. Vaults set this period longer than a transfer takes on the bridge's slow path. 3. USDC that the vault sends to the sub-account, or that comes back, is tracked exactly. It never needs an attestation and never makes NAV stale on its own. While NAV is stale, deposits and withdrawals wait. Nobody can settle against a value taken in the middle of a transfer. ## The route the Tango app uses Perps strategies in the Tango app use an attested sub-account on Base and a trading account on Hyperliquid: - On the way out, the sub-account makes a fast transfer through Circle's Cross-Chain Transfer Protocol (CCTP), which burns USDC on one chain and mints it on another. The transfer is forwarded to the strategy's own trading account on HyperCore, Hyperliquid's trading layer. The sub-account has only two approved shapes: the USDC approval to Circle's bridge, and this transfer, with the recipient fixed. - On the way back, the trading account can only send USDC to the strategy's attested sub-account on Base. The trading wallet's signing policy enforces this, not the vault. - After each transfer, new NAV values must wait out the account's stale period before they can be used. See [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md) for fees and timing, and [Hyperliquid trading wallets](https://docs.tango.fun/app/venues/hyperliquid-wallets.md) for how the trading account is controlled. --- # Fees > The fees a Tango vault can charge, how each one builds up and is paid in shares, the ceilings that cap them, and how the fee splitter divides them. Source: https://docs.tango.fun/vaults/fees A Tango vault can charge its holders several kinds of fee. Every fee is paid in vault shares, so fees never compete with withdrawals for the vault's USDC. Each fee also has a **ceiling**, the highest it can ever be set, fixed when the vault is deployed. > **Key points** > > - A vault supports six fees: management, performance, entry, exit, deposit cancellation and redemption cancellation. Release 0.13.0 adds an atomic redemption fee. > - Every fee is paid in vault shares to the vault's fee splitter. Fees never compete with redemptions for USDC. > - Each fee has a ceiling fixed at deployment. Raising a fee waits 3 days, and lowering one is immediate. ## Fee types In the table below, NAV (net asset value) is the total value of everything the vault holds. The **high-water mark** is the highest share price on which a performance fee has been charged. | Fee | Charged on | How | | --- | --- | --- | | Management | The vault's NAV, per year | Builds up every second on NAV, including when the vault loses value | | Performance | Gains above the high-water mark | A percentage of the rise in share price above the vault's highest settled price | | Entry | Each deposit | A percentage of the newly minted shares, at settlement | | Exit | Each redemption | A percentage of the redeemed shares, at settlement | | Deposit cancellation | Cancelling a pending deposit | A percentage of the USDC still waiting | | Redemption cancellation | Cancelling a pending redemption within the forced-exit wait | A percentage of the shares still waiting; free after the wait | | Atomic redemption (0.13.0) | Atomic redemptions only | A percentage of the redeemed shares | A forced exit pays no fee. ## How fees are paid Fees build up continuously. The vault subtracts them from NAV as they build up, so the share price always reflects them. It turns them into real shares at every settlement, at every fee-rate change and at a few other events. The contracts call this step **crystallising**. - The **management fee** is NAV times the rate times the time elapsed, as a fraction of a year. - The **performance fee** is measured after management fees. If the share price is above the high-water mark, the fee is the rate times the gain times the supply (the number of shares). The mark then rises to the new price. There is one mark for the whole vault, not one per holder. - The vault pays fees in shares by minting new shares to the fee splitter. This dilutes every holder by the fee amount. No USDC leaves the vault, so fees never compete with redemptions. The high-water mark starts at the first share price. It can be reset lower at most once a year, as a High-tier change. ## Ceilings Each fee's ceiling is fixed at deployment and can never be raised. There is also a round-trip ceiling: entry plus exit plus one year of management fees cannot add up to more than it. Tango's release 0.12.0 vaults deploy with these ceilings: | Fee | Ceiling | | --- | --- | | Management | 2% a year | | Performance | 20% | | Entry | 1% | | Exit | 1% | | Deposit cancellation | 0.5% | | Redemption cancellation | 1% | | Entry + exit + one year of management | 4% | ## Changing a fee - Raising a fee is a Medium-tier change. It waits 3 days on Tango's production factories, and the fee can only go up to its ceiling. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md). - Lowering a fee is immediate. - Fee changes are never back-dated. Before any change, the vault turns the fees built up so far into shares at the old rate. A new rate never applies to time that has already passed. ## The fee splitter Every vault sends its fees to its own **fee splitter**, a contract that divides them between recipients in this order: 1. A part of every fee inflow goes to the platform first. The contract caps this platform fee at 5%. It is 0% on Tango's vaults today. 2. Next come any secondary beneficiaries, which are optional extra recipients. Together, they are capped at a share fixed at deployment, which is 20% on Tango's factories. 3. Everything left goes to the primary recipient. Anyone can trigger a payout. Before the split changes, the fees built up so far are turned into shares and paid out under the old split. ## Other costs Vault fees are not the only costs. Swaps pay pool fees and slippage, bridges and venues charge their own fees, and transactions cost gas. In the Tango app, these costs are shown where a creator or depositor makes a decision. See [Fees in the app](https://docs.tango.fun/app/fees.md). --- # Share locking > How each Tango vault's share locker holds shares for a fixed term that nobody can shorten, and how the Tango app uses locks for creator commitments. Source: https://docs.tango.fun/vaults/share-locking A **share locker** is a contract that holds vault shares until a set date. Anyone can lock their shares in it. On release 0.12.0, nobody can end a lock early once it is made, so a lock is a commitment that others can check onchain. In the Tango app, creators use locks to show backers that they have money in their own strategy. > **Key points** > > - Each vault has a share locker. Anyone can lock their shares in it for a term within bounds fixed at deployment. > - From release 0.12.0, the locker has no owner. Nobody can release a lock early, and once a lock is due, anyone can release it, always to its owner. > - The Tango app uses locks so creators can show backers, onchain, that they have money in their own strategy. ## How a lock works - A holder locks shares by moving them into the locker for a duration they choose, between the vault's minimum and maximum. Each lock records its owner, its shares and its unlock time. - While the lock is held, the owner can extend it by moving the unlock time later. A lock can never be shortened. - At or after the unlock time, anyone can release the lock. The shares always go to the lock's owner. - The atomic deposit handler can deposit and lock the new shares in one transaction. Locked shares are still vault shares. Their value moves with NAV (net asset value, the total value of everything the vault holds), and they bear fees like any other share. While they are locked, they cannot be transferred, redeemed or used in a forced exit. ## Can a lock end early? No, not on release 0.12.0. The locker has no owner and no admin functions. Nobody, including the vault's admin or the platform, can release a lock before its time. A holder with a lock in a vault that is failing must wait out the term. Earlier releases worked differently: | Release | Lockers | Early release | | --- | --- | --- | | 0.5.0 | One per factory | The locker's owner could release early | | 0.10.0 | One per vault | The locker's owner could release early | | 0.12.0 | One per vault | Nobody | ## What a lock shows The locker reports two figures for each holder: - **Committed shares** are shares in locks that have not reached their unlock time. - **Held shares** are all shares still in the locker, including locks that are due but not yet released. A lock is onchain evidence of commitment for its term. It is not a guarantee of returns, an endorsement, or a promise to keep money in the vault after the term ends. ## How the Tango app uses it In the app, creators can lock their own shares as a **creator commitment**: - Deposit and Lock is an optional final step when a creator sets up a strategy. Creators can lock more later from Manage. - Each vault's shortest and longest lock term are set when it is deployed, and the app shows them when a creator locks. - Adding to a commitment creates a new lock and extends the earlier ones, so they all end together. - Atomic deposits are off in perps strategies, so the creator requests a deposit, settles it, and then locks the delivered shares. - The strategy page shows backers the amount locked and the unlock dates. It shows a **Creator locked** badge while a commitment is active. Larger commitments earn the **Skin in the Game** badge. - Locks earn no rewards. See [Create a strategy](https://docs.tango.fun/app/create-a-strategy.md). --- # How the app works > What creators and backers do in the Tango app, how every strategy is a Tango vault, and which networks and contract release the app uses. Source: https://docs.tango.fun/app/overview The Tango app is where people build investment strategies and put money into them. A **creator** builds and runs a strategy. A **backer** deposits USDC into a strategy they choose. Behind every strategy is a Tango vault: the contracts that hold the money and record who owns what. > **Key points** > > - In the app, a strategy is a Tango vault. Creators build and run strategies, and backers deposit USDC into the ones they choose. > - The app deploys new strategies on contract release 0.12.0, on Base and Ethereum. Perps are available on Base only. > - The app allows fewer changes than the contracts do. It fixes a strategy's assets and accounts when the strategy is deployed, and it offers no timelocked changes afterwards. ## Who does what | Role | What they do in the app | | --- | --- | | **Creator** | Builds and deploys a strategy, trades and rebalances it within its limits, settles deposits and withdrawals, and earns the fees they set. | | **Backer** | Deposits USDC into a strategy, receives shares, and requests withdrawals. | | **Agents** | Claude or ChatGPT, connected by the creator, propose actions. The creator reviews and signs them. | | **Platform** | Tango deploys strategies through its factory, then hands control to the creator. It covers network fees for app wallets, posts values for perps accounts, and co-signs every Hyperliquid action to enforce its limits. | The same person can be a creator and a backer. An agent can only carry out actions on its own if the creator gives it a separate, explicit permission for one strategy. Tango provides the tools. It does not manage strategies, and it does not judge whether a strategy suits anyone. Creators decide what a strategy does, and backers decide for themselves. ## What is a strategy? Every strategy is a [Tango vault](https://docs.tango.fun/vaults/architecture.md). A vault splits its money into **sub-accounts**, separate contracts that each hold one part of the strategy. A strategy has one or two of them, and the app gives them its own names: | Account in the app | Vault sub-account | Used for | | --- | --- | --- | | Swap & Lend Account (or LP Account, LP & Lend Account) | [Tracked](https://docs.tango.fun/vaults/tracked-sub-accounts.md) | Trading tokens and tokenized stocks, lending on Morpho, Uniswap liquidity | | Hyperliquid Account | [Attested](https://docs.tango.fun/vaults/attested-sub-accounts.md) | Perps on Hyperliquid | On a strategy's Risks tab, these accounts are called the **Onchain Vault Account** and the **Delegated Vault Account**. ## Networks and releases You can create a strategy on Base or Ethereum. Base is the default. | Network | What a new strategy can use | | --- | --- | | Base (default) | Tokens, tokenized stocks, Morpho lending, Uniswap liquidity, perps on Hyperliquid | | Ethereum | Tokens, tokenized ETFs, Morpho lending, Uniswap liquidity | A **contract release** is a version of the Tango vault contracts. New strategies deploy on release 0.12.0. Strategies on older releases (0.10.0 and 0.5.0) carry a **Previous release** label, and they keep working for the backers already in them. ## Moving money in and out - **Fund account** puts USDC in your Tango wallet, by transfer, by card or from another crypto asset. It never deposits into a strategy on its own. - **Deposit** moves USDC from your wallet into a strategy. See [Deposits in the app](https://docs.tango.fun/app/deposits.md). - **Withdraw** asks for your USDC back from a strategy. See [Withdrawals in the app](https://docs.tango.fun/app/withdrawals.md). If you use a Tango app wallet, tango.fun covers the network fees for deposits, withdrawal requests, claims and strategy setup. If you use an external wallet, you pay your own network fees. ## Where to go next - **If you create strategies:** start with [Create a strategy](https://docs.tango.fun/app/create-a-strategy.md), then read [Fees in the app](https://docs.tango.fun/app/fees.md) and [Fixed configuration](https://docs.tango.fun/app/fixed-configuration.md). - **If you back strategies:** read [Deposits in the app](https://docs.tango.fun/app/deposits.md), [Withdrawals in the app](https://docs.tango.fun/app/withdrawals.md) and [Tokenized stocks](https://docs.tango.fun/app/tokenized-stocks.md). - **If a strategy trades perps:** read [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md) and [Hyperliquid trading wallets](https://docs.tango.fun/app/venues/hyperliquid-wallets.md). --- # Create a strategy > How you build and deploy a strategy in the Tango app, and how each choice of assets, lending, liquidity and perps becomes part of a vault. Source: https://docs.tango.fun/app/create-a-strategy As a creator, you build a strategy in the app's strategy builder. You choose what it can trade, how it should be split, what fees it charges and how it is run. When you deploy it, Tango creates a vault with those choices built in. Many of them can never change afterwards, so it helps to know what each one becomes. > **Key points** > > - The builder has six steps: Start, Configure, Allocation, Fees, Management, and Review & Confirm. After that, you deploy the strategy. > - Your trading, lending and liquidity choices go into one tracked sub-account. Choosing perps adds a second, attested sub-account for Hyperliquid. > - Everything you choose in Configure is fixed once the strategy is deployed. Deploying creates the strategy, but it does not deposit any money or make any trades. ## The steps ```text Start: from scratch, from a template, or by copying a live strategy's setup Configure: the network, then assets to trade, Morpho vaults to lend into, Uniswap pools and perp markets Allocation: a target split across positions and cash, shown to backers as a guide Fees: management and performance fees, within fixed maximums Management: manage it yourself, or connect an agent that proposes or carries out trades within the strategy's rules Review & Confirm: check what stays fixed, then deploy Deploy: pay the setup fee, create the vault and its accounts, and hand control to the creator Optional: Deposit and Lock as a creator commitment ``` ### 1. Start You can start from scratch, pick a template, or copy a live strategy's setup. Templates include a basket of five tokenized stocks, blue-chip lending on Morpho, and a crypto core mix. Copying a strategy copies its configuration only. Your strategy never follows the original creator's trades. ### 2. Configure First choose the **network**. Base is the default. Then choose what the strategy may use. USDC is always the deposit asset. Each choice becomes part of a **sub-account**, a separate contract inside the vault that holds one part of the strategy. A **registered asset** is one the sub-account is allowed to hold and counts in its value. | Choice | What you pick | What it becomes | | --- | --- | --- | | Trading | Tokens and tokenized stocks from the network's catalogue | Registered assets in the tracked sub-account, traded through the swap module | | Lending | Morpho vaults for USDC and selected assets, such as WETH and cbBTC on Base | Registered vault shares, used through the lending module | | Liquidity pools | Uniswap V3 and V4 pools of catalogue tokens. The pool's tokens are added to Trading. | The liquidity module and position receipts, installed at deployment | | Perps | Markets on Hyperliquid (Base only) | A dedicated attested sub-account and a trading account on Hyperliquid | A strategy can register a limited number of assets, which the builder shows as you pick them. Each token, lending venue and pool position counts as one. USDC does not count. Lending venues are Morpho Vault V2s above a minimum size. You don't set swap slippage or lending tolerance yourself. Tango deploys its own ceilings for both. Options and prediction markets appear as coming soon. They are not available. ### 3. Allocation Set a target percentage for every asset, every lending vault and the cash reserve. The percentages must add up to 100%. The target is a guide for backers. The strategy does not invest deposits or rebalance automatically. You trade to reach the target. ### 4. Fees Set a management fee of 0% to 2% a year, and a performance fee of 0% to 20% of gains above the strategy's previous high. See [Fees in the app](https://docs.tango.fun/app/fees.md). ### 5. Management Choose how the strategy is run: - **Manage myself:** you choose and carry out every trade. - **Assisted:** an agent proposes allocations, and you review, approve and sign them. - **Fully managed:** an agent carries out trades within the strategy's rules, after you grant it permission. ### 6. Review & Confirm Check everything, including what stays fixed. The network and the deposit asset can never change. Neither can the assets, venues, pools and perp markets you chose in Configure. See [Fixed configuration](https://docs.tango.fun/app/fixed-configuration.md). ### Deploy Deployment runs as a short series of transactions: 1. You pay the one-time setup fee. 2. The deployment creates the access controls, which decide who may do what. 3. It creates the strategy and its accounts. 4. It sets up each action you chose. 5. It gives you control of the strategy. A strategy with perps also gets its Hyperliquid Account, with limits on where that account can send USDC. The strategy is published once deployment confirms. You can only add tokenized stocks while their prices are fresh. If US markets are closed and a stock's price is stale or close to it, setup asks you to try again during market hours or to continue without stocks. ## How choices map to sub-accounts ```text Tokens, tokenized stocks, Morpho lending, Uniswap liquidity -> Swap & Lend Account (tracked sub-account) Perp markets on Hyperliquid -> Hyperliquid Account (attested sub-account) -> trading account on Hyperliquid Strategies without perps: one sub-account; backers deposit in one transaction (atomic deposits on) Strategies with perps: two sub-accounts; the creator settles deposits and withdrawals ``` A strategy without perps has one **tracked** sub-account. Its value comes entirely from onchain price feeds (oracles), so backers can deposit in a single transaction. A strategy with perps also gets an **attested** sub-account on Base, linked to a trading account on Hyperliquid. No contract on Base can read that account directly, so Tango's NAV service posts its value instead. For this reason, the creator settles deposits and withdrawals after a fresh value is posted. See [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md). ## After deployment - You run the strategy from **Manage**. There you can trade, lend, add liquidity, move cash between accounts, trade perps, settle waiting deposits and withdrawals, and claim fees. - You can edit the name, description, artwork and target allocation. None of these edits move money. - You can lock your own shares as a commitment to backers. See [Share locking](https://docs.tango.fun/vaults/share-locking.md#how-the-tango-app-uses-it). --- # Tokenized stocks > Which tokenized stocks the Tango app offers, how strategies price them, their risks, and why they can delay deposits and withdrawals by 2+ days. Source: https://docs.tango.fun/app/tokenized-stocks A tokenized stock is a token, issued by a third party, that is designed to follow the price of a share. Strategies in the Tango app can hold them. Their prices only update while US stock markets are open. After markets close, a strategy that holds them can stop settling deposits and withdrawals until markets reopen. It is worth understanding them before you create or back one. > **Key points** > > - Strategies on Base can hold tokenized US stocks, and strategies on Ethereum can hold tokenized ETFs. These are third-party tokens that follow a share price. They are not the shares themselves. > - Strategies value them with price feeds that update during US market hours. Outside those hours the prices go stale, and a strategy holding any of them cannot settle deposits or withdrawals until markets reopen. > - Because of this, settlement can take 2+ days over weekends and holidays. ## Which stocks are available? | Network | Tokens | Issuer | | --- | --- | --- | | Base | AAPL, AMZN, GOOGL, META, MSFT, MSTR, NVDA, SNDK, SPCX and TSLA, as Coinbase tokenized equities (for example NVDAc) | Coinbase | | Ethereum | SPY and QQQ, as Ondo tokenized ETFs (SPYon, QQQon) | Ondo | A strategy can trade tokenized stocks, but it cannot lend them. ## How are they priced? Each tokenized stock is a [registered asset](https://docs.tango.fun/vaults/tracked-sub-accounts.md#the-asset-registry), one of the assets the strategy's vault counts and prices. An **oracle adapter**, a contract that supplies the vault with a price, values each one: - **Base:** the adapter reads a Chainlink price feed for the stock, plus the issuer's onchain registry. It checks the registry every time it values the stock, so it catches a paused token or a corporate action (such as a split multiplier) straight away. - **Ethereum:** the adapter reads a Chainlink price feed for the ETF. The Base feeds update during US equity trading hours. Overnight, at weekends, on market holidays and during corporate-action pauses, they hold their last value. Each Base feed has a 24-hour **heartbeat**, the longest a price can go without an update before it counts as stale. So a held stock's price reads as stale within a day of the market closing, or immediately during a pause. The Ethereum ETF feeds keep updating within their heartbeat through weekends. The strategy values each stock at its feed price, not at the price the token trades for onchain. The two can differ, especially outside market hours. ## How do stocks affect deposits and withdrawals? ```text US market open: stock feeds update, the strategy's NAV is fresh, deposits and withdrawals can settle Market closes: feeds hold their last value Within about a day: a held stock's price passes its heartbeat and reads as stale Strategy NAV stale: settlement, forced exits and swaps pause for the whole strategy Requests and cancellations still work while settlement is paused Market reopens: feeds update, NAV is fresh again, settlement resumes ``` A strategy's **NAV** (net asset value) is the total value of everything it holds. If any stock the strategy holds has a stale price, the whole NAV is stale (see [When NAV is stale](https://docs.tango.fun/vaults/sub-accounts.md#when-nav-is-stale)). Until prices are fresh again: - deposits and withdrawals cannot be settled, and the app turns off Deposit; - forced exits, where a backer settles their own overdue withdrawal, cannot run; - swaps in the strategy pause, because the vault checks every trade against oracle prices. You can still request a withdrawal or cancel a request. Prices do not go stale the moment markets close, so settlement can continue for a while afterwards. Over weekends and holidays, deposits and withdrawals can take **2+ days** to settle. When held stocks are the only stale prices, the app shows **Settlement paused until US stock markets reopen**. Otherwise it shows **Settlement paused while this strategy's pricing is out of date**. The app treats a strategy as one that can hold stocks when a tokenized stock is among its registered assets, even if it holds none right now. Creators can only add stocks at setup while their prices are fresh. ## Risks - A tokenized stock is not the stock itself. A third party issues each one and designs it to follow a share price. Holding one does not make you a shareholder. It gives you no voting rights or dividends unless the issuer's terms say so. - Each issuer decides the token's backing, rights and redemption terms. Issuers can approve or restrict which addresses may hold or move their tokens. A restriction could leave a position unable to move. - The tokens trade onchain at any hour, but there is less liquidity when US markets are closed. Swaps can cost more, and prices can jump when markets open. - Feeds lag behind the market because they update in steps. Valuations and settlement use the last update, not the live market price. - Tokenized stocks may not be available everywhere or to everyone. Whether you can hold them depends on the laws that apply to you. Tango does not issue these tokens, does not hold them for you, and does not stand behind their issuers' claims. ## Not the same as stock perps Perps on stocks, indices, commodities and FX are a different instrument. A perp is a contract on the price, not the asset itself. These trade on Hyperliquid's xyz exchange and sit in the strategy's Hyperliquid account. The exchange prices them around the clock, so they do not pause settlement at weekends. See [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md). --- # Fees in the app > The fees a creator sets in the Tango app, when they are charged, the maximums that cap them, and the network, swap and venue costs around them. Source: https://docs.tango.fun/app/fees A strategy's creator can earn two fees from it: a management fee and a performance fee. As a creator, you set both when you create the strategy, within fixed maximums. As a backer, you pay them through the strategy's share price, so higher fees leave less for you. This page also covers the other costs around a strategy, such as setup, swaps, network fees and moving USDC to and from Hyperliquid. > **Key points** > > - Creators set two fees. The management fee is up to 2% a year, and the performance fee is up to 20% of gains above the strategy's previous high. > - Fees are paid to the creator in strategy shares, not to tango.fun. They build up every second, and the vault mints (creates) them as new shares each time the strategy settles deposits or withdrawals. > - After deployment, the app has no screen for changing fees. The only exception is stopping them when you close a strategy. ## Fees the creator sets | Fee | What it charges | Maximum | | --- | --- | --- | | Management | A percentage of the strategy's value per year, including when the strategy loses value | 2% a year | | Performance | A percentage of gains above the strategy's previous high | 20% | The creator picks each rate in the builder. Higher fees leave less for backers. The vault has other fees too: entry, exit, deposit cancellation and redemption cancellation. The contracts have ceilings for them, but the app does not charge them. See [Vault fees](https://docs.tango.fun/vaults/fees.md). ## How are fees charged? - Fees build up every second, and the strategy's share price already reflects what has built up. - Each time the strategy settles a deposit or a withdrawal, the fees built up so far become shares the creator can claim. - Creators claim these shares from **Manage**, under Fees Earned, and can withdraw them like any other shares. - The performance fee is only charged on gains above the strategy's previous high, called its high-water mark. There is one high-water mark for the whole strategy. ## Can fees change after deployment? The app does not let you change fees after deployment. The one exception is **Stop fees**, which lowers both fees to zero when a creator closes a strategy. The contracts themselves allow more. The creator's wallet can lower fees at any time. It can also raise them, up to their fixed maximums, after a 3-day grace period. Nobody can ever raise the maximums. A strategy's page shows these rules in its fee details. ## Platform fee The vault's fee splitter, the contract that divides fees between their recipients, reserves a platform share of the creator's fees. The contract caps that share at 5% of fee inflows. ## Other costs A strategy has other costs besides the creator's fees. In the table, a **builder fee** is a fee an app adds to the orders it sends to Hyperliquid. A **fill** is an order, or part of one, that executes. | Cost | Who pays | Amount | | --- | --- | --- | | Setup fee | The creator, once at deployment | A one-time fee, shown before the creator confirms | | Swap fee | The strategy, on the creator's trades | An integrator fee, shown inside **Max Slippage + Fees**, plus pool fees and slippage | | Manage operation fee | The creator, on Manage actions | The network cost in USDC, estimated from gas with no markup | | Network fees for backers | tango.fun, for app wallets | Covers deposits, withdrawal requests and claims | | Perps builder fee | The strategy, on each Hyperliquid fill | Set by Tango, never above Hyperliquid's maximum | | Bridging and venue fees | The strategy, when moving USDC to and from Hyperliquid | Circle's transfer fees, Hyperliquid's account activation on the first deposit, and Hyperliquid's withdrawal fee. See [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md#moving-usdc) | --- # Fixed configuration > Why the Tango app fixes a strategy's assets, venues, pools, perp markets and sub-accounts at deployment, and what creators can still change later. Source: https://docs.tango.fun/app/fixed-configuration When a creator deploys a strategy in the Tango app, its assets, venues and markets are set for good. The app gives the creator no way to add to them later. So as a backer, you can see what a strategy is able to hold and where it can trade. The app will not add to that list. > **Key points** > > - Once a strategy is deployed, the app does not let its creator add assets, lending venues, pools, perp markets or sub-accounts. > - Backers can review a strategy knowing what it is able to hold and where it can trade, for its whole life. > - The name, description, artwork, target allocation and agent connections can still change. None of them move money. ## What is fixed? | Fixed at deployment | Enforced by | | --- | --- | | Network and deposit asset (USDC) | The contracts | | Registered assets: tokens, tokenized stocks, lending venues, pool positions | The app (the contracts allow additions behind a 14-day timelock) | | Installed liquidity pools | The app | | Perp markets | Tango's co-signature on every Hyperliquid action | | Number of sub-accounts: one, or two for perps | The contracts (maximum fixed at deployment) and the app | | Fee maximums | The contracts | | Slippage and lending ceilings | The contracts | The app does not remove assets from release 0.12.0 strategies either. The asset list stays exactly as it was deployed. ## Why fix the configuration? The contracts do allow changes after deployment. A vault's admin can add assets, modules, sub-accounts and approved transaction types (call shapes). Each of these changes must wait behind a 14-day [timelock](https://docs.tango.fun/vaults/timelocks.md), a delay during which the change is public before it can take effect. The app never offers these timelocked actions. Every strategy keeps the configuration it was deployed with. This has three effects: - A backer who reads a strategy's assets and markets today knows the app will not add to that list. - Any change made outside the app is a public timelocked operation that backers can see coming. - Tango's defaults can improve for new strategies without changing existing ones. If a creator wants a different set of assets or markets, they create a new strategy. ## Perp markets The creator chooses perp markets when creating the strategy. A market that was not chosen, or that Hyperliquid later delists, can only be closed. It can never be opened. The vault contracts do not know about markets, so this limit is enforced offchain. Every Hyperliquid action needs Tango's co-signature, and Tango refuses actions outside the chosen markets. See [Hyperliquid trading wallets](https://docs.tango.fun/app/venues/hyperliquid-wallets.md). ## What can still change? | Change | Does it move money? | | --- | --- | | Name, description and artwork | No | | Target allocation percentages | No. They are a guide and never trade. | | Connected agents and their permissions | Not by itself. Agents act within the strategy's limits. | | Stop funding, close the strategy, or stop fees when closing | No new risk. These can only reduce. | | Locking more of the creator's own shares | It moves the creator's own shares into the locker. | ## What about changes outside the app? The creator's wallet holds the vault's top admin role. The contracts would let it schedule a timelocked change directly, without the app. Any such change is public onchain while it waits. For High and Critical changes, backers have at least 7 days, which is longer than the 3-day wait for a forced exit (a backer settling their own overdue withdrawal). See [Exit before governance](https://docs.tango.fun/vaults/timelocks.md#exit-before-governance). --- # Deposits in the app > How you deposit USDC into a strategy in the Tango app, why strategies with perps settle deposits later, and how long it takes. Source: https://docs.tango.fun/app/deposits When you deposit into a strategy, you send USDC and receive shares of its vault. How that happens depends on the strategy. Most strategies give you shares straight away. Strategies that trade perps take your deposit as a request, and the creator settles it a little later. > **Key points** > > - In a strategy without perps, you deposit in one transaction and receive your shares immediately. > - In a strategy with perps, you request a deposit. Your USDC waits until the creator settles the request, and your shares then arrive in your wallet. > - Either way, you pay the strategy's NAV per share at that moment, and nothing settles while the strategy's prices are out of date. ## Two ways to deposit | | Strategies without perps | Strategies with perps | | --- | --- | --- | | What you do | Approve the exact USDC amount, then Deposit | Approve, then Request deposit | | When your shares arrive | In the same transaction | When the creator settles your request | | Price | NAV per share now | NAV per share when it settles | | How the vault handles it | [Atomic deposit](https://docs.tango.fun/vaults/deposits.md#atomic-deposits) | [Settled deposit](https://docs.tango.fun/vaults/deposits.md#settled-deposits) | ## Depositing into a strategy with perps ```text You: Request deposit; your USDC moves to the strategy's deposit holding area, outside its value Tango NAV service: posts a fresh value for the Hyperliquid account Creator: settles waiting requests from Manage in batches, oldest first, each in full Settlement: shares are created at NAV per share and sent to your wallet Before settlement: you can cancel and get your USDC back ``` 1. When you request a deposit, your USDC leaves your wallet and waits in the strategy's deposit holding area. It is not part of the strategy yet, and the creator cannot trade with it. 2. You wait while the creator settles waiting requests together from Manage, in batches. Settlement waits until Tango has posted a fresh value for the strategy's Hyperliquid account. 3. Settlement sends your shares to your wallet, and you don't need to do anything else. You can have one open deposit request per strategy. A request is refused if it is larger than the room left under the strategy's deposit cap. ### Why do strategies with perps settle deposits later? Part of a perps strategy's money sits in its account on Hyperliquid, and no contract on Base can read that balance directly. Tango's NAV service checks the account and posts its value onchain. The vault only uses a posted value when it is recent and passes its checks (see [Attested sub-accounts](https://docs.tango.fun/vaults/attested-sub-accounts.md#safeguards)). A posted value always lags slightly behind the live account. If deposits settled instantly, someone could deposit right after a gain on Hyperliquid, before the new value was posted, and buy shares too cheaply at the expense of existing backers. To prevent this, the vault turns off instant deposits whenever a strategy has an account like this. The creator settles deposits instead, after a fresh value is posted. ### How long does it take? - Your request usually confirms within a few minutes. - The creator decides when to settle. There is no fixed time. - Tango posts the Hyperliquid account's value regularly, and asks for a fresh one when the creator prepares a settlement. After USDC moves to or from Hyperliquid, the vault waits a set period before it accepts a new value. - Strategies that hold tokenized stocks can take 2+ days over a weekend. See [Tokenized stocks](https://docs.tango.fun/app/tokenized-stocks.md). ### Can I cancel? Yes. You can cancel a request while your USDC is still waiting. Cancelling gives it back, minus any cancellation fee. Tango's strategies charge none. ## Limits - **Minimum:** each deposit must meet the app's minimum and the strategy's own minimum. - **Deposit cap:** each strategy accepts deposits up to its deposit cap, after withdrawals. When a strategy is full, Deposit is unavailable until someone withdraws. - **Out-of-date prices:** while any of the strategy's prices are stale, Deposit is turned off and the app tells you why. ## Network fees If you use a Tango app wallet, deposits, requests and claims cost you no network fees: tango.fun covers them. If you use an external wallet, you pay your own network fees. ## What a deposit is not A deposit buys shares of the strategy's vault at its current value. It does not buy the strategy's target allocation for you. Your USDC arrives as cash, and the creator decides when to invest it. Before you deposit, read the strategy's Risks tab and [Withdrawals in the app](https://docs.tango.fun/app/withdrawals.md). --- # Withdrawals in the app > How you request a withdrawal in the Tango app, how the creator settles it, why there is no instant withdrawal, and what can delay settlement. Source: https://docs.tango.fun/app/withdrawals When you withdraw from a strategy, you hand back your shares and receive USDC. In the Tango app, every withdrawal is a request. The creator settles it, and the USDC then goes straight to your wallet. This page explains why withdrawals work this way and what can make them take longer. > **Key points** > > - Every withdrawal is a request that the creator settles. When it is settled, USDC goes straight to your wallet. > - You receive the NAV per share at the moment of settlement, so the amount can differ from the estimate you saw when you asked. > - There is no fixed settlement time. Weekends (for strategies with stocks), funds held on Hyperliquid and stale prices can all add time. ## How a withdrawal works ```text Request withdrawal: choose 10%, half, all or an amount; your shares move into escrow Creator: brings USDC back into the vault, for example by selling, withdrawing from lending, or bringing USDC back from Hyperliquid Creator: settles from Manage, in the Withdrawal Queue, at NAV per share Receive cash: USDC arrives in your wallet as part of the settlement ``` 1. Request a withdrawal by choosing an amount or a shortcut (10%, Half, All out). Your shares leave your wallet and wait in escrow, where the vault holds them until settlement. You can have several open requests. 2. You wait while the creator makes sure the vault has enough USDC, then settles. Each request is settled in full. 3. You receive your cash when the settlement pays USDC to your wallet. The price is the strategy's **NAV per share** when it settles. NAV (net asset value) is the total value of everything the strategy holds, and NAV per share is that value divided by the number of shares. If you use a Tango app wallet, tango.fun covers the network fees for your requests. Tango's strategies charge no exit fee. ## Why can't I withdraw instantly? A strategy's money is invested, not sitting as cash. To pay a withdrawal, the creator first has to turn positions into USDC. That takes trades, withdrawals from lending, or bridge transfers. The vault also settles every withdrawal at one fresh price. This stops anyone leaving at an outdated value at the expense of the backers who stay. See [Why there is no atomic withdrawal](https://docs.tango.fun/vaults/withdrawals.md#why-there-is-no-atomic-withdrawal). ## What can delay settlement? | Cause | Why it delays settlement | | --- | --- | | The creator has not settled yet | Settlement is the creator's action, and there is no fixed time | | Tokenized stocks outside US market hours | The strategy's prices are stale until markets reopen, which can take 2+ days. See [Tokenized stocks](https://docs.tango.fun/app/tokenized-stocks.md) | | Funds on Hyperliquid | The creator must bring USDC back to Base first. After each transfer, the account's value waits for a fresh posting | | A frozen Hyperliquid account value | If a posted value falls outside its allowed band, settlement waits until the value is re-anchored | | Not enough cash in the vault | Settlement pays only from the vault's idle USDC | ## Can I cancel? Yes. You can cancel a request until any part of it is settled. Your shares come back to your wallet, minus any cancellation fee. Tango's strategies charge none. ## Forced exit A **forced exit** lets you settle your own request if the creator has not. The vault contracts allow it once a request has been unsettled for 3 days. It pays you from the vault's cash and its Swap & Lend Account. It cannot reach funds in the Hyperliquid Account. The app does not offer forced exits yet. You can use them directly on the contracts. See [Forced exit](https://docs.tango.fun/vaults/withdrawals.md#forced-exit). ## Locked shares If you locked shares as a creator commitment, you cannot withdraw them until the lock ends and they are released back to your wallet. --- # Perps on Hyperliquid > How Tango strategies trade perps on Hyperliquid through a separate attested sub-account, how often its value is posted, and the limits on every order and transfer. Source: https://docs.tango.fun/app/venues/hyperliquid A perp (perpetual future) is a contract on the price of an asset, such as BTC, that you can trade with leverage. Strategies on Base can trade perps on Hyperliquid, an exchange that runs on its own chain. Because no contract on Base can see a Hyperliquid account, a strategy with perps works differently from one without. Tango posts the account's value onchain, and Tango must co-sign every order. This page explains how that works for creators and what it means for backers. > **Key points** > > - A strategy with perps has a second sub-account on Base, an attested one, linked to the strategy's own trading account on Hyperliquid. > - Tango's NAV service posts the account's value on a regular schedule and before settlements. The vault only uses a value if it is recent, was observed after the latest transfer, and falls inside its deviation band. > - Every order needs signatures from both the creator and Tango. Tango only co-signs orders in the strategy's chosen markets, at isolated margin and within leverage ceilings. ## How a perps strategy is set up ```text Vault on Base -> Hyperliquid Account (attested sub-account on Base): sends USDC and brings it back Hyperliquid Account -> trading account on HyperCore: Circle CCTP fast transfer, to a recipient fixed at deployment Trading account -> Hyperliquid Account: USDC sent back can only go to this sub-account NAV attester: reads balances on Base and Hyperliquid, and posts the account's value on Base ``` When you pick perp markets for a strategy, deployment adds three things: - **A Hyperliquid Account**, an [attested sub-account](https://docs.tango.fun/vaults/attested-sub-accounts.md) on Base. It is a sub-account valued from a figure that Tango posts. It has only two approved transaction types (call shapes). It can approve USDC for Circle's bridge, and it can make a bridge transfer to the strategy's own trading account. - **A trading account on Hyperliquid**, a wallet that the creator and Tango control jointly. See [Hyperliquid trading wallets](https://docs.tango.fun/app/venues/hyperliquid-wallets.md). - **A NAV provider**, the contract that receives the account's posted value. Its only NAV managers are the strategy's attester and watcher keys. Perps are available on Base. While they roll out, they may be limited to selected creators. ## Markets and leverage You choose markets when you create the strategy. They come from Hyperliquid's main exchange and from its xyz exchange. The choice is fixed: a market you did not choose can only be closed. | Class | Markets | | --- | --- | | Crypto | BTC, ETH, SOL, HYPE, ZEC, AVAX, TAO, NEAR | | Equities (xyz) | NVDA, GOOGL, META, TSLA, MSFT, AAPL, AMZN | | Indices (xyz) | SP500, XYZ100 | | Commodities (xyz) | GOLD, SILVER, CL, BRENTOIL, NATGAS, COPPER | | FX (xyz) | EUR, JPY | Each market has a leverage ceiling, which the order ticket shows. A ceiling never goes above Hyperliquid's own live maximum for that market. When the underlying market is closed, xyz markets take their price from their own order book. So they keep trading and keep being valued at weekends, unlike [tokenized stocks](https://docs.tango.fun/app/tokenized-stocks.md). ## Order rules Tango checks every order before it co-signs. An order must meet these rules: - Positions use isolated margin only, so each has its own margin. Leverage must be at or under the market's ceiling and within Hyperliquid's margin tiers. - Anything that adds risk must be in one of the strategy's chosen markets. Closing, cancelling and protective orders are always allowed. - An order must meet a minimum size. - Market orders have a slippage limit, with a little more room when closing a position. - Tango's builder fee is attached, never above Hyperliquid's maximum. A builder fee is a fee an app adds to the orders it sends to Hyperliquid. You can place market and limit orders, with optional take-profit and stop-loss. Tango can pause actions that add risk for all strategies at once. Even then, closing, cancelling, protection, adding margin and withdrawals stay available. ## How the value is posted Tango's NAV service works out the Hyperliquid Account's value and posts it onchain. The vault then decides whether to use it. ```text On a regular schedule, after transfers land, and before settlement: read, check, post Read: USDC in the Hyperliquid Account on Base, plus the trading account's equity and spot USDC on Hyperliquid Check: no bridge transfer open, the ledger matches, and the data is recent Post: attest the account's equity in USDC, rounded down Vault accepts: a fresh value, observed after the last activity, inside the band Watcher: an independent service re-reads the account and pages Tango if the figures disagree or a posting is late Below the band: the account is invalidated until the NAV guardian re-anchors it ``` | Setting | What it does | | --- | --- | | Posting frequency | Values are posted on a regular schedule for each account, plus after a transfer lands, before every settlement, and on request | | What is posted | Equity in USDC: the sub-account's USDC on Base, plus the Hyperliquid account value and spot USDC. Never position size or notional. | | Heartbeat | A value older than the heartbeat is stale | | Stale period after calls | After any bridge transfer or call batch, values must wait out this period before they can be used | | Deviation band | How far a new value may move within each window and still be used | Each setting is fixed when the strategy is deployed. See [Attested sub-accounts](https://docs.tango.fun/vaults/attested-sub-accounts.md#safeguards) for how the vault applies them. The **heartbeat** is how old a value may be before the vault treats it as stale. The **deviation band** is how far a new value may move and still be used. Before posting, the service checks its work. It skips a run while a bridge transfer is in flight or an outflow is unexplained, and it checks that its readings are recent. Posting costs the strategy no gas. A separate **watcher** re-reads every account over its own connection. It pages Tango's on-call team if its figure differs from the posted one, or if a posting is late. The watcher has no power onchain. The vault decides onchain what happens to each posted value: - **Inside the band:** the vault uses it. - **Above the band:** the vault ignores it. The last accepted value stands until it becomes stale. - **Below the band:** the vault invalidates the account. Settlement waits until the NAV guardian, the role that can freeze and re-anchor attested values, re-anchors it to a posted reading. ## Moving USDC | Move | How | Time | Costs | | --- | --- | --- | --- | | Vault to Hyperliquid | One transaction signed by the creator on Base: send to the Hyperliquid Account, then a Circle CCTP fast transfer to the trading account | Usually seconds, or longer if it falls back to a standard transfer | Circle's protocol and forwarding fees, and Hyperliquid's account activation fee on the first deposit. Tango refuses a transfer if Circle's fees rise above a set limit, and transfers have a minimum size. | | Hyperliquid to Base | Signed by the creator and Tango. It can only go to the strategy's Hyperliquid Account. | Usually under a minute | Circle's forwarding fee, and Hyperliquid's withdrawal fee on the first withdrawal | | Hyperliquid Account to vault | Signed by the creator on Base | One transaction | Network fee | CCTP is Circle's Cross-Chain Transfer Protocol, which moves USDC between chains. After each transfer, the account's value waits out the stale period for a fresh posting. Until then, deposits and withdrawals cannot settle. When trading is enabled, spot USDC moves to the perps balance. Tango tops up a small amount of HYPE in the trading account. This pays Hyperliquid's network gas on transfers back to Base. ## Enabling trading After the first USDC lands, the creator enables trading once. This sets the account to Hyperliquid's standard mode, approves Tango's builder fee, and moves spot USDC to the perps balance. Both the creator and Tango sign each step. ## Risks specific to perps - Positions use leverage, and Hyperliquid can liquidate them. The app shows each position's liquidation price and how far it is from it. The app does not send liquidation alerts. - Part of the strategy's value is a figure that Tango posts. The vault limits how that figure can move, but backers rely on the attester as well as on the contracts. - Only the creator, with Tango's co-signature, can trade, close positions or bring money back from Hyperliquid. A [forced exit](https://docs.tango.fun/vaults/withdrawals.md#forced-exit) cannot reach funds on Hyperliquid. - Tango's co-signature enforces the market choice, leverage ceilings and order rules offchain. The vault contracts do not. - Hyperliquid, Circle's bridge and its forwarding service are third parties. Outages or failures on their side can delay or prevent transfers. - Deposits and withdrawals wait for a fresh posted value, and for the stale period after any transfer. --- # Hyperliquid trading wallets > How each perps strategy's Hyperliquid account is a Privy wallet that needs both the creator and Tango to sign, and the narrow policy that limits what it can sign. Source: https://docs.tango.fun/app/venues/hyperliquid-wallets Each strategy with perps trades from its own wallet on Hyperliquid. The vault contracts cannot reach funds on Hyperliquid directly, so this wallet's controls matter. This page explains who controls the wallet, what it can and cannot sign, and what happens if one party is unavailable. > **Key points** > > - Each strategy with perps trades from its own wallet on Hyperliquid. The wallet is held with Privy, a wallet service. It is owned by a 2-of-2 key quorum: the creator and a dedicated Tango key must both sign, and neither can sign alone. > - A Privy policy limits what the wallet can sign. It can trade, approve Tango's exact builder fee, and send USDC back to the strategy's own sub-account on Base. Everything else is denied, including transfers elsewhere and exporting the key. > - Tango only co-signs actions it planned and checked, and the app re-checks each one before the creator approves it. ## Which wallets are involved? | Wallet | Held by | Can sign | | --- | --- | --- | | **Trading wallet** (one per strategy) | A Privy server wallet owned by a 2-of-2 quorum: the creator and Tango's perps key | Hyperliquid actions allowed by its policy, and only with both signatures | | **Creator's wallet** | The creator | Everything on Base: sending USDC to the Hyperliquid Account, the bridge transfer, and bringing USDC back to the vault | | **NAV attester** (one per strategy) | A key held by Tango's NAV service | Only `attest` on this strategy's NAV provider, on the vault's chain | | **NAV watcher** (one per strategy) | A key with a policy that denies every signature | Nothing. Its address is registered as a NAV manager, and the watcher service holds no key. | | **Gas top-up wallet** (shared) | Tango | Only a small, fixed HYPE transfer, to pay Hyperliquid network gas on transfers back to Base | A **2-of-2 quorum** means two keys own the wallet and both must approve before it signs anything. The NAV attester posts the Hyperliquid account's value onchain, and the NAV provider is the contract that receives it. Setup creates the trading wallet before the vault is deployed. Its address is written into the vault's approved bridge transaction (its call shape) as the only recipient. ## Two signatures for every action Every action on Hyperliquid needs a signature from the creator and a signature from Tango. Each side checks the action independently before it signs. ```text Creator in Manage -> Tango API: asks for an action (open, close, adjust margin, send back) Tango API: plans the exact Hyperliquid action and records it, with a short window to approve it App on the creator's device: recomputes the typed data and checks the market, leverage, builder fee and destination Creator: approves the exact request with their Privy authorization signature Tango API: re-checks the wallet's owners and policy, and for risk-adding steps the market and trading switches Tango API: adds its authorization signature; Privy signs only with both, and only within the policy Hyperliquid: receives the signed action ``` 1. The creator asks for an action in Manage. Tango's API reads the account, plans the exact Hyperliquid actions and records each one. The creator then has a short window to approve them. 2. Before the creator approves, the app recomputes on the device what will be signed from the action itself, and requires the two to match. It checks that: - the market is one the strategy chose; - leverage is isolated and within the ceiling; - the builder fee is Tango's exact fee; - margin moves stay within the account; - any transfer goes only to this strategy's Hyperliquid Account. 3. The creator approves by signing a Privy authorization over that exact request. 4. Tango co-signs only requests it planned and recorded, and only typed-data signatures for this wallet. Typed data is a structured message that the signer can read. Before signing, Tango confirms that the wallet: - is still owned by exactly the 2-of-2 quorum; - has no extra signers; - has one policy; - was never exported. For anything that adds risk, Tango also re-checks the strategy's chosen markets and Tango's trading switches. It then checks that the signature recovers to the trading wallet, meaning the trading wallet produced it, and submits it once. On Base, the creator signs alone. Tango builds and checks those transactions, but it never signs them. ## The policy A **policy** is a set of rules that Privy checks before the wallet signs. Every signature the trading wallet produces must pass its Privy policy. The same 2-of-2 quorum owns the policy, so changing it also needs both signatures. | Allowed | Pinned to | | --- | --- | | Hyperliquid exchange actions: orders, cancels, modifies, leverage and isolated margin updates, moving collateral between the account's own exchanges | Hyperliquid mainnet's signing domain | | Switching to standard account mode | Mainnet, standard mode only | | Approving a builder fee | Tango's builder address and exactly Tango's maximum fee | | Moving USDC from spot to perps | The direction to perps only | | Sending USDC back to Base | USDC only, the Base bridge domain, and this strategy's Hyperliquid Account as the only recipient | | Denied | | --- | | Sending USDC or other tokens to any other address, on Hyperliquid or elsewhere | | Withdrawing through any other route | | Moving perps USDC back to spot | | Approving trading agents (unless the creator turns on automatic trading, below) | | Any EVM transaction on any chain | | Exporting the private key | ### Why can't the policy check every order? Hyperliquid exchange actions are hashed before they are signed, so Privy cannot inspect individual order fields. Three other checks keep these actions to the strategy's markets and limits: Tango's planner, the app's check before the creator approves, and Tango's re-check before it co-signs. Actions that move money work differently. They are signed as readable typed data, so Privy enforces their recipients directly. ## Who can do what alone? | Party | Can do alone | Cannot do alone | | --- | --- | --- | | Creator | Move USDC between the vault and the Hyperliquid Account on Base | Trade, close, or send USDC back from Hyperliquid | | Tango | Refuse to co-sign. Post NAV values within the vault's band. Top up HYPE gas. Trade through the agent wallet, but only if the creator turned on automatic trading. | Withdraw, or change the wallet's policy | | Anyone else | Nothing | Anything | Even with both signatures, USDC on Hyperliquid can only leave towards the strategy's own Hyperliquid Account on Base. From there, it can only go back into the vault. ## Automatic trading A creator who connects an AI agent can opt in to automatic perps trading for one strategy, where it is available. Turning it on takes two approvals, and the creator and Tango both sign each one: 1. A policy change that keeps every existing rule and adds one exact rule allowing a single trading agent. 2. Registering that agent with Hyperliquid. Tango's execution service holds the agent wallet. The agent can place, cancel and modify orders, update leverage and margin, and move collateral within the account. It cannot sign withdrawals or any other transfer. Tango's backend narrows it further, to the markets, leverage and slippage frozen in the creator's permission. With automatic trading on, Tango's execution service can trade the strategy's Hyperliquid account without a per-order approval from the creator, within those limits. Stopping automatic trading turns off Tango's signing for the agent. Each new permission uses a fresh agent wallet. ## What if something is unavailable? | Situation | Effect | | --- | --- | | Tango's API or Privy is down | No new signatures, so no trades and no transfers from Hyperliquid. Resting orders, take-profit and stop-loss triggers, and liquidations continue on Hyperliquid. | | Tango's NAV service is down | The account's value goes stale once it passes its heartbeat. Deposits and withdrawals wait, and the Hyperliquid Account cannot bring USDC back to the vault while its value is stale. | | The creator is unavailable | Nobody can trade, close or bring money back from Hyperliquid. A forced exit cannot reach it. | | Tango's perps key is lost | Funds on Hyperliquid could not be moved, because every action needs that key. | These are the trust assumptions of trading on an offchain venue. They are part of the reason strategies with perps settle deposits and withdrawals instead of allowing instant ones. See [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md#risks-specific-to-perps). --- # Glossary > Plain definitions of the terms used across the Tango docs and app, from allocation cap to VaultManager, with links to the pages that explain them. Source: https://docs.tango.fun/reference/glossary This page explains the terms used across the Tango docs and the Tango app. Each definition is short. Where a term has its own page or section, the definition links to it. > **Key points** > > - The app and the contracts sometimes use different names for the same thing. The app calls a vault a strategy, and a depositor a backer. > - NAV (net asset value) is the total value of everything a vault holds, minus fees it owes. NAV per share sets the price of every deposit and withdrawal. > - Profiles such as the VaultAdmin, VaultManager and Sentry are fixed bundles of permissions. [Roles and profiles](https://docs.tango.fun/vaults/roles.md) explains each one. | Term | Meaning | | --- | --- | | Allocation cap | The most USDC a vault can send to one sub-account, minus what that sub-account has sent back. See [Sub-accounts](https://docs.tango.fun/vaults/sub-accounts.md#limits-on-capital). | | Asset registry | The list of assets each tracked sub-account is allowed to hold. See [Tracked sub-accounts](https://docs.tango.fun/vaults/tracked-sub-accounts.md#the-asset-registry). | | Atomic deposit | A deposit that is requested, settled and delivered as shares in one transaction. It is off in vaults with an attested sub-account. See [Deposits](https://docs.tango.fun/vaults/deposits.md#atomic-deposits). | | Attested sub-account | A sub-account whose value comes from a figure someone posts. It is used for venues the vault cannot value onchain. The app calls it the Delegated Vault Account. See [Attested sub-accounts](https://docs.tango.fun/vaults/attested-sub-accounts.md). | | Backer | Someone who deposits into a strategy. Also called a depositor. | | Builder fee | A fee per order that Hyperliquid lets an app charge when an order fills. See [Perps on Hyperliquid](https://docs.tango.fun/app/venues/hyperliquid.md). | | Call shape | A transaction type an attested sub-account is approved to make: a set target, function and pattern of arguments. See [Approved call shapes](https://docs.tango.fun/vaults/attested-sub-accounts.md#approved-call-shapes). | | CCTP | Circle's Cross-Chain Transfer Protocol. It is used to move USDC between Base and Hyperliquid. See [Bridging](https://docs.tango.fun/vaults/bridging.md). | | Ceiling | A limit fixed when a vault is deployed. It can never be raised. | | Creator | The person who builds and runs a strategy. | | Creator commitment | Shares a creator has locked in their own strategy. See [Share locking](https://docs.tango.fun/vaults/share-locking.md). | | Crystallise | To turn fees that have built up into real shares. This happens at each settlement. See [Fees](https://docs.tango.fun/vaults/fees.md#how-fees-are-paid). | | Deposit cap | The most money a vault accepts in deposits, after subtracting what has been withdrawn (its net principal). See [Deposits](https://docs.tango.fun/vaults/deposits.md#deposit-cap). | | Deposit silo | Where USDC from pending deposit requests waits. It is not counted in NAV. | | Deviation band | How far a new attested value may move and still be used. See [Safeguards](https://docs.tango.fun/vaults/attested-sub-accounts.md#safeguards). | | Factory | The contract that deploys and sets up every vault for one release. See [Deployment](https://docs.tango.fun/vaults/factory.md). | | Fee splitter | The contract that receives a vault's fees and divides them between recipients. See [Fees](https://docs.tango.fun/vaults/fees.md#the-fee-splitter). | | Forced exit | A holder settling their own withdrawal when it is still unsettled after 3 days. See [Withdrawals](https://docs.tango.fun/vaults/withdrawals.md#forced-exit). | | Heartbeat | How old a price or attested value may be before it counts as stale. | | High-water mark | The highest share price on which a performance fee has been charged. | | HyperCore | Hyperliquid's trading layer, where perps positions and USDC balances live. | | Idle cash | USDC the vault holds itself, rather than in a sub-account. Withdrawals are paid from it. | | Module | A contract a tracked sub-account uses to swap, lend or provide liquidity. See [Modules](https://docs.tango.fun/vaults/tracked-sub-accounts.md#modules). | | NAV | Net asset value: the total value of everything the vault holds, in USDC, minus fees it owes. | | NAV guardian | The profile that can freeze an attested value and re-anchor it to a reading the NAV provider has posted. See [Roles](https://docs.tango.fun/vaults/roles.md). | | NAV manager | A key allowed to post attested values to a NAV provider, the contract that records them. | | Previous release | A strategy on an older contract release, kept for its existing backers. | | Queued deposit | The app's name for a settled deposit. The depositor requests a deposit, then the creator settles it. | | Release | The contract version a vault was deployed from. See [Contract releases](https://docs.tango.fun/vaults/architecture.md#contract-releases). | | Sentry | The profile that can pause the vault and lower limits. It can never raise anything or unpause. | | Settle | To fill pending requests at one NAV price. In the app, the creator does this. | | Shares | The vault's token, a standard ERC-20. Each share represents a part of the vault's NAV. | | Stale | Too old to trust: a price or value past its freshness limit. A stale NAV pauses settlement. | | Strategy | What the app calls a Tango vault. | | Sub-account | A separate contract that holds part of a vault's strategy. See [Sub-accounts](https://docs.tango.fun/vaults/sub-accounts.md). | | Timelock | A waiting period before a change that adds risk can take effect. See [Timelocks](https://docs.tango.fun/vaults/timelocks.md). | | Tracked sub-account | A sub-account valued onchain from its registered assets and their oracle prices. The app calls it the Onchain Vault Account. | | Trading wallet | The Hyperliquid account a perps strategy trades from. See [Hyperliquid trading wallets](https://docs.tango.fun/app/venues/hyperliquid-wallets.md). | | VaultAdmin | The top profile. It holds every role, each behind its timelock. | | VaultManager | The profile that runs the vault day to day. It settles requests, moves cash, executes actions on sub-accounts and adjusts fees within their ceilings. | --- # For AI assistants > How people, LLMs and AI agents can read these docs efficiently, with llms.txt, Markdown pages and the full-text bundle. Source: https://docs.tango.fun/reference/for-ai-assistants These docs are written to be read by people and by language models (LLMs) alike. Every page is also available as clean Markdown, and the whole site is available as one file. This page lists those files, and the rules an AI assistant should follow when it answers questions about Tango. > **Key points** > > - Start with llms.txt to find the right page, or load llms-full.txt to read the whole site at once. > - Add `.md` to any page URL to get that page as Markdown. > - Vault pages describe what the contracts make possible. App pages describe what a Tango user can do today. > - Assistants should not start transactions for a user, and nothing in these docs is investment advice. ## Endpoints | What | URL | When to use it | | --- | --- | --- | | Index | https://docs.tango.fun/llms.txt | Find the right page. Lists every page with a one-sentence summary, grouped by section. | | Full text | https://docs.tango.fun/llms-full.txt | Load everything at once when the context window allows. | | One page | Any page URL plus `.md`, for example https://docs.tango.fun/vaults/deposits.md | Read a single topic. Links inside point at other `.md` pages. | | Sitemap | https://docs.tango.fun/sitemap.xml | Crawl the HTML pages. | Every HTML page also has buttons to copy it as Markdown. Other buttons open it in ChatGPT or Claude, with a prompt that points at its Markdown version. ## How the docs are organised The site has four sections: - **Get started** introduces Tango and the words used everywhere else. - **Tango vaults** describes the smart contracts. It covers what they enforce for every vault, whichever app created it. - **Tango app** describes the choices the app at app.tango.fun makes on top of the contracts. It covers which features a strategy uses, which settings a creator can pick, and what depositors experience. - **Reference** holds the glossary and this page. When a question is about what is possible, the vault pages are the authority. When it is about what a Tango user can do today, the app pages are. ## Reading rules for assistants - Describe vault behaviour as these pages state it. Do not infer guarantees: permissions, bounds and timelocks limit what can happen; they do not make a strategy safe or profitable. - A strategy's own settings (assets, fees, lock terms) are shown on its page in the app. These docs explain what the settings mean, not the values a particular strategy chose. - Live strategy data such as value held, holdings and recorded performance comes from the app. Its own guide is at https://app.tango.fun/llms.txt. - Do not start deposits, withdrawals or other transactions for a user. Every money movement is reviewed and signed by the user in the app. - Nothing here is investment advice or a recommendation. ---