Bridging

A strategy that trades perps needs cash somewhere other than Base, in a trading account on Hyperliquid. 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 when the vault was deployed. While cash is in transit, the vault settles no deposits or withdrawals until it has a value that counts that cash.

Key points

• The vault has no bridge of its own, and every sub-account lives on Base.
• Funds leave Base only through an attested sub-account, using call shapes set for it. On tango.finance that is a Circle CCTP transfer to the strategy's own trading account, with the recipient fixed.
• While cash is in transit, the attested value must count it. The vault's NAV stays stale until it accepts a reading taken after the transfer.

Which sub-accounts can bridge?

A tracked sub-account can only hold registered tokens on Base, so it never bridges. Bridging is a call that an attested sub-account makes, and 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, which is a Critical-tier change. See Timelocks.

How NAV stays correct in transit

An attested sub-account's part of NAV comes from an attestation, a value posted for the account. While cash is moving, it has left the sub-account on Base but has not yet arrived at the destination. Three rules keep the value honest during that time:

1. The poster counts everything or waits. An attestation is the account's whole net worth, including funds in transit. If the poster 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 tango.finance uses

Perps strategies on tango.finance use an attested sub-account on Base, which the Advanced tab calls Perps, and a trading account on Hyperliquid:

• On the way out, the vault sends USDC to the Perps account. The Perps account then makes a fast transfer through Circle's Cross-Chain Transfer Protocol (CCTP), which burns USDC on Base and mints it on the other side, forwarded to the strategy's own trading account on HyperCore, Hyperliquid's trading layer. The Perps 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 Perps account on Base. The trading wallet's signing policy enforces this, not the vault.
• From the Perps account, cash goes back to the vault, never straight to another account.
• After each transfer, new values must wait out the account's stale period before they can be used. Activity shows this as an Updating Value step.

The first transfer to a new trading account also pays Hyperliquid's account activation. See Perps on Hyperliquid for timing and costs, and Hyperliquid trading wallets for how the trading account is controlled.