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 the creator asks for 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 are set, so it shapes what can and cannot change later.

Key points

• Every Tango vault comes from a factory for one contract release. The factory 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 deployer cannot be the vault's admin, and nothing is upgradeable.

How a vault is deployed

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

1. Deploy: clone the vault, price oracle, asset registry, policies, fee splitter, handlers and share locker; check every limit against the factory's maximums. The vault starts paused.
2. Add sub-accounts: tracked sub-accounts with their modules, assets, caps and rate limits; attested sub-accounts with their verifier and NAV provider.
3. Approve first call shapes: attested sub-accounts get their first shapes with no delay, before any role is set up.
4. Finalize: requires at least one sub-account, unpauses the vault, installs every role and timelock, and the factory gives up all of its powers.
After finalize: the vault is live, and every later change goes through the vault's own roles and timelocks.

1. The factory deploys by cloning (creating new instances of) the vault and its supporting contracts. It checks every requested limit against its own maximums. 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-accounts with their modules, registered assets, caps and rate limits. Attested sub-accounts get their verifier and NAV provider.
3. Attested sub-accounts receive their first call shapes (approved transaction types). This is the only time shapes can be approved without a timelock.
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 timelock. It then renounces (gives up) its admin roles. Finally, it checks that neither it nor the installer, the helper contract that set up the roles, still holds any admin role.

What the creator chooses

At deployment, the creator chooses settings in five groups. Some are permanent limits. Others are starting values that can change later, within those limits.

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 share locker's minimum and maximum lock durations;
• the timelock tiers in the factory's roles table.

Values inside those ceilings, such as the current deposit cap or fee rates, 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:

• The factory refuses to deploy 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.
• A factory with timelocks requires its High delay to be at least twice the forced-exit wait. See Exit before governance.
• From release 0.13.0, the factory refuses to finalize a vault that turns on atomic (one-transaction) redemptions alongside an attested sub-account.

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 (set up) the new contracts in a single step, so nobody else can initialise them first. Connecting them to the vault uses Critical-tier actions: adding the sub-account, installing modules, registering assets and approving shapes. So on Tango's production factories, the change takes at least 14 days.

Adding an attested sub-account to a live vault immediately turns off atomic deposits for the whole vault.

The Tango app does not offer additions after deployment. See Fixed configuration.