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 value comes from a figure that a separate service reports, called an attestation. Strict rules decide when the vault will use that figure. On tango.finance it is the Perps account, linked to your strategy's trading account on Hyperliquid.

Key points

• An attested sub-account holds money that cannot be valued onchain, such as a perps exchange account or funds in transit between chains.
• It can only make transactions that match its call shapes, a short list of approved transaction types fixed when the vault is deployed.
• 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 reading below the band freezes the account until the NAV 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. A strategy that trades perps needs a venue that lives elsewhere, and a contract on Base cannot read that venue's balances.

An attested sub-account covers that case. Everything that can be valued onchain still is, and only the offchain part is attested. A tango.finance strategy gets one only when it trades perps.

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, meaning 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.
• The first shapes are approved while the factory deploys the vault. Approving another later is Critical tier, and revoking one is immediate.

On tango.finance, the Perps 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 on Hyperliquid, with that recipient fixed. See Bridging.

The verifier checks each call on its own. It cannot stop approved calls from being repeated or combined, and an approval to spend granted to a third party 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. A reported value goes through these checks before the vault uses it:

1. A NAV manager posts an attestation: 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.
2. The value must have been observed after the last USDC sent in or brought back, and after the last call batch plus the stale period after calls.
3. It must not be older than the heartbeat.
4. It must fall inside the deviation band around the window's anchor, its reference value.
5. Inside the band, it is accepted and counts in the vault's NAV. Above the band, it is ignored and the last accepted value stands. Below the band, the account is invalidated and held until the NAV guardian re-anchors it.

A posted value is taken up by the sub-account in the same transaction as the attestation.

Three separate keys share the work:

• NAV managers post attestations, and each one must be observed later than the last.
• The NAV admin appoints and removes NAV managers. It is fixed when the provider is created.
• The NAV guardian can invalidate, meaning freeze, the account's NAV and re-anchor it to a reading the provider has posted. It cannot post attestations.

Keeping these keys separate matters. A key that could both attest and re-anchor could set any NAV. On tango.finance, Tango holds the NAV admin key, Tango's NAV service posts the values, and your wallet is the NAV guardian. See Perps on Hyperliquid.

Safeguards

Each attested sub-account has four settings, fixed when it is created:

The vault applies these rules to every reading:

• 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, so nothing settles against a value that predates the account's own 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. 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.
• 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 on the venue can still be reduced.

What it means for deposits and withdrawals

• Every deposit and withdrawal settles at a NAV that includes the last accepted value, so it waits for a fresh one after any transfer to or from the venue.
• A forced exit pays from the vault's idle cash only, so it never reaches an attested account. Funds on an exchange or in transit are out of its reach.

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. A strategy with an attested sub-account relies on the service posting values, as well as on the contracts.