Roles and profiles

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);
• 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.

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 and Withdrawals.

Keys outside the AccessManager

A few keys live in other contracts, outside the vault's AccessManager. Each has a narrow job.

Who can freeze what

Brakes act immediately, but only the VaultAdmin can release them, and only after a delay.

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;
• 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, 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.

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.