Tango vaults
Timelocks
How Tango vaults make changes that add risk wait 3, 7 or 14 days, let changes that reduce risk happen at once, and give depositors time to leave first.
A timelock is a waiting period between announcing a change to a vault and making it. Tango vaults put one on most changes that add risk, such as adding a new asset or raising a fee. The scheduled change is public while it waits, so a depositor who disagrees has time to withdraw before it takes effect. Changes that reduce risk do not wait.
Key points
- Changes that add risk must wait. Fee raises wait 3 days, raising limits or unpausing waits 7 days, and adding assets, oracles, modules, call shapes or sub-accounts waits 14 days.
- Changes that reduce risk, such as pausing, lowering a limit or lowering a fee, take effect immediately.
- A depositor whose withdrawal is not settled within 3 days can force their own exit. Every delay of 7 days or more is at least twice that wait.
- A depositor who requests a withdrawal when a change is scheduled can therefore be out before it lands.
How a timelock works
Each vault has an AccessManager, the contract that decides who may call each restricted function. Every restricted function has its own role there. A timelock is a delay attached to one of those roles. The role holder cannot make a delayed change straight away. Instead:
- The role holder schedules the change. The schedule is public onchain, so anyone can see it.
- The delay passes.
- The role holder carries out the change. If they do not do so within one week of it becoming ready, the scheduled change expires.
A scheduled change can be cancelled by whoever scheduled it, by the VaultAdmin, or by the role's guardian. Every role that increases risk has an admin-level canceller.
Two changes to the AccessManager itself also wait behind a delay. One is giving a delayed role to a new holder. The other is letting the VaultAdmin's admin role act faster.
How long each change waits
Every role belongs to a tier, and the tier sets its delay. Tango's production factories use the tiers below for releases 0.10.0 and later. Release 0.5.0 had no timelocks.
| Tier | Delay | Used for |
|---|---|---|
| None | Immediate | Day-to-day running and anything that reduces risk |
| Medium | 3 days | Raising a fee, within its fixed ceiling |
| High | 7 days | Raising the deposit cap, a sub-account cap or a rate limit; unpausing; resetting the performance fee's high-water mark (at most once a year); adding a signer to a signed handler |
| Critical | 14 days | Adding a sub-account, module, asset, oracle adapter, NAV provider or call shape; changing the deposit or holder policy or the fee recipient; admin changes to the AccessManager |
A call shape is an approved transaction type for an attested sub-account. A NAV provider is the contract that supplies an attested sub-account's reported value.
The factory's roles table fixes these delays. They cannot be changed for a vault that already exists.
Which changes wait
Every role has a direction. It either increases risk, reduces risk or is neutral. Most changes that increase risk wait, so depositors have time to react. Changes that reduce risk, and routine work, take effect at once.
Day 0: the VaultAdmin schedules a change that adds risk (High tier, 7 days) Day 0: a depositor who disagrees requests a redemption Day 3: the forced-exit wait ends; if the request is not yet settled, the depositor can force their own exit Day 7: the earliest the High-tier change can run Day 14: the earliest a Critical-tier change scheduled on day 0 can run Changes that reduce risk (pause, lower a cap, lower a fee, revoke a call shape, invalidate NAV) take effect at once
| Direction | Examples | Delay |
|---|---|---|
| Increases risk | Register an asset, bind an oracle adapter, install a module, approve a call shape, add a sub-account, raise a cap or rate limit, raise a fee, unpause | Medium, High or Critical |
| Reduces risk | Pause, lower a cap or rate limit, lower a fee, start deregistering an asset, start removing a sub-account, revoke a call shape, invalidate an attested NAV, remove a signer | Immediate |
| Neutral | Settle requests, send USDC to sub-accounts and bring it back, act within existing limits | Immediate |
A few actions count as increasing risk but still take effect immediately. Each one is narrowly limited:
- Rescuing tokens that were sent to a contract without being asked. Only the untracked amount can be rescued.
- Removing an oracle adapter, the contract that supplies an asset's price. The asset then reads as stale, which pauses settlement instead of mispricing it.
- Re-anchoring by the NAV guardian, which can only re-anchor to a reading the provider has posted.
- Editing the fee splitter's beneficiaries, within their fixed cap.
Exit before governance
A depositor can force their own exit if their withdrawal request is still unsettled after the forced-exit wait. The factory requires the High delay to be at least twice that wait. With a 3-day wait, this means:
- A depositor who sees a High or Critical change scheduled can request a redemption and wait 3 days. They can then force their own exit before the change can run.
- A fee raise (Medium, 3 days) can land inside that window. It can only go up to the fee ceilings fixed at deployment.
No change waits for pending redemptions to clear first. The guarantee is time to leave, not a veto.
Watching for changes
The AccessManager emits an event for every scheduled change. The event shows the target contract and the calldata, the encoded call the change will make. Anyone can index these events to see what is coming. In the Tango app, creators are not offered any timelocked change after deployment. See Fixed configuration.