Deposits

A deposit turns USDC into shares of a vault. A Tango vault can take deposits in up to three ways. Every deposit is priced at the vault's NAV per share at the moment it settles. NAV (net asset value) is the total value of everything the vault holds. Which ways are open depends on the vault's release and on whether it has an attested sub-account.

Key points

• Every deposit is priced at the vault's NAV when it is settled, never when it is requested.
• In a settled deposit, the depositor makes a request and the vault's settler fills it later, in a batch. This way is always available.
• An atomic deposit requests, settles and delivers the shares in one transaction. It only works in vaults with no attested sub-account.
• A signed atomic deposit (release 0.13.0) is an atomic deposit that also needs a signature from an approved signer.

Three ways to deposit

Settled: the depositor requests -> USDC waits in the deposit silo -> the settler settles a batch at NAV -> shares are delivered or claimed
Atomic: the depositor calls the deposit handler -> the handler requests, settles that one request and claims, all in one transaction
Signed atomic: as atomic, plus an EIP-712 signature from an approved signer naming the depositor, amount, nonce and deadline
Atomic and signed atomic deposits are refused while any sub-account is attested

Settled deposits

A settled deposit happens in three steps. The settler is whichever key settles requests: the VaultManager, a Settler or the VaultAdmin.

1. The depositor requests a deposit by calling requestDeposit, or an operator calls it for them. An operator is an address the depositor has approved to act for them. The amount must meet the vault's minimum. The USDC moves to the vault's deposit silo, a holding contract where it waits outside NAV.
2. The settler settles a batch of requests, up to the vault's batch size. Settlement first accrues fees, then values the vault. It fills every request in the batch at the same price.
3. Anyone can then deliver settled shares to their owner, so the settler can settle and deliver in one batch. The owner can also claim the shares themselves.

Deposit cap

The deposit cap limits the vault's net principal. Net principal is the deposits settled, minus the redemptions settled and the forced exits paid. The vault accepts every request and applies the cap at settlement. If the requests in a batch add up to more than the room left, each one is filled in proportion and the rest stays pending.

The cap can be lowered immediately. Raising it is a High-tier change, and it can never go above a ceiling fixed at deployment.

Fees at deposit

If the vault sets an entry fee, it is taken in shares at settlement. A depositor can cancel a pending request and get back the USDC still waiting. If the vault sets a deposit cancellation fee, that fee is taken first. Both fees are capped by ceilings fixed at deployment.

How long can a request wait?

A pending request has no expiry. It waits until it is settled or cancelled. Before it is settled, it can also be transferred to another address.

Settlement needs a fresh NAV. While NAV is stale, requests wait. This happens, for example, while a tokenized stock's price is frozen or an attested value is out of date. See When NAV is stale.

Atomic deposits

An atomic deposit does all three steps in one transaction, through a contract called the deposit handler. The handler opens a request for the depositor and settles only that request. It requires the request to be filled in full, with at least the minimum number of shares the depositor asked for. It then delivers the shares. The price and the entry fee are the same as a settled deposit at that moment.

The vault refuses an atomic deposit when:

• the handler or the vault is paused;
• NAV is stale;
• the room left under the cap would only allow a partial fill;
• any sub-account in the vault is attested.

The handler can also deposit and lock the new shares in the same transaction. See Share locking.

Why atomic deposits are off with an attested sub-account

An atomic deposit lets the depositor choose the exact moment their price is set. With tracked sub-accounts, that price comes from oracles. With an attested sub-account, part of the price is a figure someone posted.

A posted value lags behind reality. Suppose the account has gained since its last accepted value. The vault's NAV is then too low for a while. Anyone who could deposit atomically at that moment would get shares too cheaply, at the expense of existing holders. The party posting values could even time this.

Settled deposits avoid the problem. The settler decides when to settle, after a fresh value has been accepted. The handler checks for attested sub-accounts on every call, so adding one to a live vault turns atomic deposits off at once.

Oracle prices also update in steps, even without attested accounts. So an atomic depositor can sometimes buy into a gain the price feed has not shown yet. An entry fee larger than the typical gap caused by feed lag removes that edge.

Signed atomic deposits

From release 0.13.0, a vault can require a signature for atomic deposits. The signature decides who may skip the queue and deposit at the live price. It does not decide who may deposit at all: the settled path stays open to everyone.

• An approved signer signs an EIP-712 message, a standard format for signed data. The message names the depositor, the amount, a nonce (a number that can be used once) and a deadline. The depositor submits it with their deposit.
• Each nonce can be used once, and the deadline is enforced.
• Adding a signer is a High-tier change. Removing one is immediate and permanent: a removed address can never be added again.
• Like any atomic deposit, a signed deposit is refused while the vault has an attested sub-account.

The Tango app does not use release 0.13.0 yet. See Deposits in the app.