> ## Documentation Index > Fetch the complete documentation index at: https://docs.pacifica.fi/llms.txt > Use this file to discover all available pages before exploring further. # Managing a Vault This page covers the manager and creator side of a vault: deploying it, choosing its parameters, and operating it day-to-day. Depositor mechanics are described in [Depositing](/vaults/depositing). ### Creating a Vault Vault creation is a single signed call. The creator provides: * An optional `manager` address. If omitted, the vault is created as a "fresh vault" with no manager - any address can later [claim the manager seat](#claiming-a-fresh-vault). * An optional `nickname`, for display on the vaults page. Nicknames are unique across all vaults. * An optional [configuration](#configuration) object. If omitted, the default configuration applies (no caps, no fees, no cooldowns, no symbol restrictions). * An optional seed deposit. If provided, the same call also performs a `deposit_to_lake` from the creator into the new vault. A creation fee of 10 USDC is charged to the creator at vault creation. The vault is assigned a freshly-generated address and starts with zero balance, zero shares, and zero positions. A vault may itself be designated as the manager of another vault (a "subvault"). Subvaults are limited to one level of nesting. ### Claiming a Fresh Vault A fresh vault (created without a manager) can have its manager seat claimed by any address via a signed `claim_lake_manager` call. Claiming requires: * An initial deposit of at least 10 USDC. * If the vault was created with `manager_min_balance_portion` set, the post-claim manager balance ratio must satisfy `manager_balance / (manager_balance + lp_balance) >= manager_min_balance_portion`. Once claimed, the manager seat is permanent for the lifetime of the vault. ### Configuration A vault's behavior is governed by a `LakeConfig`. Some fields are fixed at creation; others can be updated by the creator. All fields are optional. Where a field is `None` the vault behaves as if no constraint of that kind exists. | Field | Mutable? | Description | | ------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `deposit_cap` | Yes (creator) | Maximum total LP balance accepted by the vault. The manager's own deposits do not count against the cap. `None` = uncapped. | | `whitelist` | Yes (creator) | Symbols the manager is permitted to trade. `None` = all listed symbols allowed. | | `blacklist` | Yes (creator) | Symbols the manager is blocked from trading, applied after the whitelist. A symbol in both lists is blocked. `None` = no blocked symbols. | | `max_leverages` | Yes (creator) | Per-symbol leverage caps for orders placed by the vault. `None` = the symbol's exchange-default max leverage applies. | | `manager_profit_share` | No | Fraction of profits above the high-water mark routed to the manager as a performance fee, in `[0, 1]`. `None` = no fee. See [Profit & Loss](/vaults/profit-and-loss). | | `deposit_min_duration_ms` | No | Minimum time (in milliseconds) a depositor's funds must remain in the vault before they can be withdrawn. Reset on every new deposit by the same depositor. | | `manager_min_balance_portion` | No | Minimum manager-balance ratio required to claim the manager seat and to lift a trading halt. In `[0, 1]`. | | `manager_liquidation_balance_portion` | No | Manager-balance ratio at which the engine halts the vault and liquidates open positions. In `[0, 1]`. Must be strictly less than `manager_min_balance_portion` if both are set. | | `withdraw_window_s` | No | Period of the withdrawal-window cycle in seconds. Must be in `[1 hour, 90 days]`. Set together with `withdraw_duration_s`. | | `withdraw_duration_s` | No | How many seconds out of each `withdraw_window_s` period are open for withdrawals. Must be in `[1 hour, 30 days]` and strictly less than `withdraw_window_s`. | #### Mutability Only the creator can update mutable fields. Updates take effect immediately on the next operation. The non-mutable fields are deliberately fixed at creation: they govern the vault's economics, withdrawal cadence, and risk thresholds. ### Operating the Vault The vault is a real Pacifica account. The manager places orders for it through the Pacifica frontend or by using the standard order endpoints, signed by the manager's wallet or by an [agent key](/api-documentation/api/signing/api-agent-keys) bound to the manager's address. All Pacifica trading rules apply unchanged: order types, margin model, mark price, funding, liquidation. See [Trading on Pacifica](/trading-on-pacifica/overview). The manager is also subject to the standard exchange-wide constraints such as rate limits and individual deposit requirements for the vault account itself. ### Manager Economics Manager Shares and LP Shares are separate share classes against the same underlying balance and positions. * The manager's deposits and withdrawals follow the same minimum amount and the same `available_to_withdraw` constraints, and the same period-PnL ledger sync as LP deposits and withdrawals. * `deposit_min_duration_ms` and `withdraw_window_s/duration_s` apply to manager withdrawals as well. * When a vault is configured with `manager_min_balance_portion`, the manager must satisfy the threshold to claim the seat and to lift a trading halt. See [Risk Controls → Manager Balance Portion](/vaults/risk-controls#manager-balance-portion). The manager's earnings come from two sources: 1. The pro-rata return on Manager Shares, identical in form to an LP's return. 2. The performance fee on profits above the high-water mark, set by `manager_profit_share`. The fee is credited to `manager_balance` and accrues to Manager Shares automatically. See [Profit & Loss → Performance fee](/vaults/profit-and-loss#performance-fee).