# Vault Lifecycle

End-to-end flow of a Dedicated Client Vault — from a wallet's first access through to reading vault state — organized around the four things an integrator needs to know: how a wallet gets access, how a vault comes into existence, how it operates, and how to interact with it day-to-day. For step-by-step code, see the [Integration Guide](/dedicated-client-vaults/integration-guide.md).

### 1. Wallet access — the Whitelisting contract

Before any wallet can deploy or operate a vault, it has to appear on Tesseract's on-chain `Whitelisting` contract with a non-expired entry.

To get there, the client completes the [Compliance & Onboarding](/dedicated-client-vaults/compliance-and-onboarding.md) flow — KYC/KYB, then proof-of-ownership signatures for the wallets they want to use (one or more can be added). Once checks clear, Tesseract writes each wallet to the `Whitelisting` contract on-chain. From that moment the wallets work unattended until their entry expires — shortly before expiry, Tesseract emails the client with instructions to complete KYC renewal; once the renewal is cleared, the new expiration is written back to the whitelist on-chain.

For partner-led onboarding (custodian model), the partner and Tesseract agree on compliance responsibilities and the partner's users are provisioned through the Compliance API — see [Scenario B](/dedicated-client-vaults/integration-guide/scenario-b.md). The end state is identical: each wallet carries an active on-chain whitelist entry.

There is one `Whitelisting` contract covering all assets. See [Contract Addresses](/dedicated-client-vaults/reference/contract-addresses.md).

### 2. Vault creation — the Vault Deployer

A dedicated vault is created in a single transaction against a **Vault Deployer**. There's one deployer per supported asset (USDC, WETH, WBTC) — the caller invokes the deployer for the asset they want to hold, passing an initial deposit and acceptable fee bounds.

Most clients drive this through the Tesseract app at [app.tesseract.fi](https://app.tesseract.fi) — connect a whitelisted wallet, pick the asset, enter the deposit amount, and confirm. The app builds and submits the transaction on the client's behalf. Partners integrating directly from their own infrastructure call the deployer themselves — see the [Integration Guide](/dedicated-client-vaults/integration-guide.md).

Either way, that one transaction:

* Clones a fresh vault contract for the caller
* Wires the caller as the owner with deposit and withdrawal rights
* Configures management and performance fees
* Pulls the initial deposit from the caller and mints shares in return
* Emits a `VaultDeployed` event with the new vault's address

After the transaction, the vault is fully independent — the deployer has no further control over it. The client lands on the new vault with shares already in their wallet; there is no separate "first deposit" step.

### 3. Selecting a strategy

Strategy selection is off-chain and costs no gas — the client signs an EIP‑712 typed-data message from their wallet, and once submitted Tesseract picks the vault up and begins managing it. The same mechanism is used to switch strategies later as risk preferences change.

* **Retail.** Pick a strategy from the list in [app.tesseract.fi](https://app.tesseract.fi) and sign the prompt that appears in the wallet — the app builds the message and submits the signature.
* **Integrators.** Build and sign the EIP‑712 message yourself, then `PUT /vaults/{vault}/strategy` on the Public API. See [Strategy Assignment](/dedicated-client-vaults/integration-guide/scenario-a/strategy-assignment.md) for the schema and a worked example.

### 4. Operating the vault

Once a strategy is assigned, Tesseract Investment Oy executes the discretionary portfolio management mandate at the vault level — allocating into yield sources, rebalancing, and handling risk management on the client's behalf. Assets never leave the individual vault contract to enter a shared pool.

Day-to-day vault operations have two paths. Retail clients use [app.tesseract.fi](https://app.tesseract.fi), which handles approvals, transaction construction, and fallback between instant and scheduled withdrawals automatically. Integrators call the vault and its `WithdrawManager` directly — see the [Integration Guide](/dedicated-client-vaults/integration-guide.md) for code-level walkthroughs.

**Top-up.** Add to an existing vault by depositing more of the underlying asset — shares are minted immediately, and Tesseract allocates the new capital on the next management cycle. Retail: use the "Deposit" action in the app. Integrators: approve the asset and call `deposit` on the vault — see [Deposits](/dedicated-client-vaults/integration-guide/scenario-a/deposits.md).

**Instant withdrawal.** For amounts that fit within the vault's liquid balance, withdrawals are a single transaction and funds arrive in the same block. Retail: use the "Withdraw" action in the app. Integrators: call `withdraw` or `redeem` on the vault; if the amount exceeds instant capacity the call reverts and you fall back to the scheduled flow — see [Instant Withdrawals](/dedicated-client-vaults/integration-guide/scenario-a/instant-withdrawals.md).

**Scheduled withdrawal.** For larger amounts, withdrawal is a three-step flow spread over up to \~24 hours: request → wait for Tesseract to release funds → claim within the withdrawal window. Retail: the app walks you through all three steps. Integrators: call `requestShares` on the vault's `WithdrawManager`, poll for release, then call `redeemFromRequest` on the vault — see [Scheduled Withdrawals](/dedicated-client-vaults/integration-guide/scenario-a/scheduled-withdrawals.md).

Yield accrues to each vault's positions and compounds automatically into the share price — no manual claim, no separate rewards token. See [Vault Shares](/dedicated-client-vaults/vault-shares.md) for how shares, share price, and auto-compounding work.

### 5. Reading vault state

Every vault has a public page in the Tesseract app — for example, [app.tesseract.fi/vault/0xe1c3a197…76a9](https://app.tesseract.fi/vault/0xe1c3a197d16ef96a7c8e7c5f6b83b5e032cd76a9) — showing balance, share price, performance, and transaction history. Clients use this as their primary dashboard.

Behind the same data, vault state is available two ways for integrators:

* **Directly on-chain.** Share price, balance, asset, total assets — the vault is a standard ERC‑4626 contract. Any ERC‑4626 tooling works.
* **Via the** [**Public API**](/dedicated-client-vaults/reference/public-api.md)**.** Vault discovery, decoded transaction history, and performance time-series (APY/APR, TVL, share price over time).

For a partner integrating into their own stack, the Public API is the single canonical entry point for reporting. No periodic reconciliation is required — share price and positions are always derivable from on-chain state.

### Components at a glance

| Component                     | Purpose                                                               | Public surface                                                                     |
| ----------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `Whitelisting`                | KYC-gated access control                                              | `isWhitelisted`, `whitelistExpiration`                                             |
| Vault Deployer (per asset)    | Creates dedicated vaults                                              | `deployVault`, `deployVaultWithPermit`                                             |
| Vault (ERC‑4626)              | Holds client assets, mints/burns shares                               | Standard ERC‑4626 (`deposit`, `redeem`, `withdraw`, `balanceOf`, `totalAssets`, …) |
| `WithdrawManager` (per vault) | Scheduled-withdrawal requests for amounts exceeding instant liquidity | `requestShares`, together with the vault's `redeemFromRequest`                     |
| Public API                    | Vault discovery, transactions, performance, strategy assignment       | `api.vault.tesseract.fi`                                                           |

See [Contract Methods](/dedicated-client-vaults/reference/contract-methods.md) for full signatures.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.tesseract.fi/dedicated-client-vaults/vault-lifecycle.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.