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.

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.

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.

An attested value is used only when it is fresh, observed after the account's latest activity, and inside the band.

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).
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.
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 describes how often values are posted and what is checked before posting.