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. On tango.finance it is the Strategy account: your spot tokens, stocks and money market positions all sit here.

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 held asset's price goes stale, the vault's NAV goes stale and settlement pauses.
• The sub-account acts only through two modules, swap and ERC-4626 lending. After each action, it measures what it actually spent and received, prices both with the oracle, and reverts if the loss is above the tolerance.

The asset registry

Each vault has one asset registry: for every tracked sub-account, it lists the assets that sub-account may hold. USDC, the vault's own asset, is always registered.

An asset is in one of three states, and it only ever moves forward through them:

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 change. See Timelocks.

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.

Each sub-account has a maximum number of registered assets, fixed when the vault is deployed. On tango.finance, the assets you keep on Review become the registered assets: each spot token, each stock and each money market's vault shares. They are fixed from then on. See Fixed configuration.

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:

• It cannot acquire anything else, because the output of every action must be a registered asset or the action reverts, meaning it fails and is undone.
• It cannot spend anything else, because the input must be a registered asset, within the quantity the sub-account has tracked.
• It does not count anything else, 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. Only the VaultAdmin can rescue them, and only 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. Binding an adapter is Critical tier. Removing one is immediate, after which the asset reads as stale rather than mispriced.

When a price is stale

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, every price is also stale while the network's sequencer is down, and for a grace period after it comes back. The sequencer is the service that orders Base'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). An asset with a zero balance is skipped, so a dead feed for something the strategy does not hold does not stop it.

Modules

A module is a built-in tool for one kind of action. A tracked sub-account acts only through the modules installed on it, and a module cannot be installed without a policy that bounds it. Installing a module is Critical tier, and removing one is immediate.

Every tango.finance strategy has both. Spot and stock buys and sales go through the swap module. Money markets are ERC-4626 vaults, and cash parked in them goes through the lend module.

Modules hold nothing between calls. They cannot borrow or loop, which means borrowing 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 key that runs it names a tolerance: the most value this action may lose against oracle prices. It can be no higher than the policy's slippage ceiling. Each action has one input and one output. The sub-account then checks the result itself:

1. It hands the input to the module, which performs the swap or the supply and must end holding nothing.
2. It measures what was spent and received from its own balance changes, not from what the module reports.
3. It prices both at oracle prices read after the action. The value received must be at least the value spent times one minus the tolerance.
4. It charges the amounts that moved to the rate-limit buckets.

Any stale price, excess loss or empty bucket reverts the whole action. The check 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. Rate limits cap how much value can pass through in a window, but there is no total loss budget.
• Money market positions are valued at the venue's own convertToAssets figure. A venue that misreports its share price would misstate NAV.
• A money market is usable only while it is a registered asset with an ERC-4626 adapter and has a supply bucket above zero. Withdrawing from it is never rate limited.