Deployment through the factory

Every Tango vault is built by a factory: a contract that deploys all of a vault's parts and connects them. The factory checks every limit against its own maximums, hands control to the vault's own roles, and then gives up all of its powers. Deployment is also when a vault's permanent limits and its timelocks are set, so it shapes what can and cannot change later.

Key points

• Every tango.finance strategy comes from the release 0.15.0 factory on Base. It deploys every contract, sets up every role, then gives up all of its own powers.
• Ceilings such as maximum fees, the maximum number of sub-accounts and the deposit cap's ceiling are fixed at deployment and can never be raised.
• The timelocks you set on Review are passed to the factory and fixed for the vault's life.
• The deployer cannot be the vault's admin, and nothing is upgradeable.

How a vault is deployed

The factory's deployer builds a vault in stages. The vault stays paused until the last one, called finalize.

1. The factory deploys by cloning, meaning creating new instances of, the vault and its supporting contracts. It checks every requested limit and the timelocks against its own maximums and floors. Each address is derived from a salt, a value the deployer picks, and the deployer, so nobody can deploy to those addresses first.
2. The factory creates the tracked sub-account with its modules, registered assets, caps and rate limits. A strategy with perps also gets an attested sub-account with its verifier and NAV provider.
3. The attested sub-account receives its first call shapes. This is the only time shapes can be approved without going through the vault's own roles.
4. The factory finalizes the vault. It checks that there is at least one sub-account, unpauses the vault and installs every role at its tier. It then gives up its admin roles, and checks that neither it nor the installer, the helper contract that set up the roles, still holds any.

On tango.finance these stages are the first step of setup, Deploy Strategy. Tango's deployer sends them and pays their network fees. You don't sign anything until the vault exists. See Build a strategy.

What is chosen at deployment

Some settings are permanent limits. Others are starting values that can change later, within those limits.

The vault's onchain name does not include your strategy's name. Your strategy's name stays in the app. Vaults and wallets are still public onchain, so anyone can read a vault's holdings and transactions.

Fixed forever

After deployment, these can never change:

• the name, symbol and underlying asset;
• every fee ceiling, and the round-trip fee ceiling;
• the maximum number of sub-accounts, the settlement batch size, the minimum deposit and redemption, and the forced-exit wait;
• the deposit cap's ceiling and each sub-account's allocation ceiling;
• each policy's slippage ceiling;
• each attested sub-account's band, window, heartbeat and stale period, and its provider's NAV admin;
• the delay of each timelock tier.

Values inside those ceilings, such as the current deposit cap or a rate limit, can change through the vault's roles and timelocks. Changing a ceiling means deploying a new vault.

Factory guarantees

The factory enforces these rules for every vault it deploys:

• It refuses a vault whose admin is the deployer itself.
• After finalize, the factory and the installer hold no role on the vault.
• Every limit must sit at or below the factory's maximums. For example, entry, exit and one year of management fees together cannot be more than the round-trip ceiling.
• Timelocks are either all off, or each tier is longer than the one below it and at least the factory's floor for that tier.
• The forced-exit wait is above zero and no longer than the factory's longest. With timelocks on, the High tier must be at least twice the forced-exit wait.

Adding a sub-account later

The contracts let a vault's admin add sub-accounts after deployment, up to the vault's maximum. Expansion kits create and initialise the new contracts in a single step, so nobody else can initialise them first. Connecting them to the vault uses Critical-tier changes: adding the sub-account, installing modules, registering assets and approving shapes.

A tango.finance strategy keeps the sub-accounts it was deployed with, and the app does not offer additions. See Fixed configuration.