# Depositing into a Vault This page covers what a depositor (LP) needs to know before, during, and after depositing into a vault. Vault concepts and roles are described in the [Vaults overview](/docs/vaults/vaults.md). ### Before depositing A vault is a discretionary trading pool. Depositors take on the trading risk taken by the manager, capped at their deposited capital. Pacifica does not vet, audit, or insure third-party vault managers. Treat depositing into a vault the same way you would treat sending capital to any external trader. Before depositing, review: * The manager address, the creator address, and any nickname. The creator can change a small set of trading parameters after creation (see [Managing a Vault → Mutability](/docs/vaults/managing-a-vault.md#mutability)). * The current symbol whitelist, blacklist, and per-symbol leverage caps. These define what the manager is permitted to trade. * `manager_profit_share` and `deposit_min_duration_ms`. These determine your fees and your minimum lock-up. * `withdraw_window_s` and `withdraw_duration_s` if set. These determine when withdrawals are open. * The current balance, the current LP share count, and the current open positions. These define the NAV at which your shares will be priced. ### How shares are priced on deposit A deposit is converted into LP shares against the vault's net asset value at the moment of deposit. The vault's NAV is the lake account's equity (USDC balance plus unrealized PnL on all open positions, marked to mark price), with the period's PnL first attributed to existing shareholders. ``` NAV_per_share_before_deposit = lp_balance / lp_shares (after accumulated PnL is credited) shares_minted = amount / NAV_per_share_before_deposit = amount * lp_shares / lp_balance ``` If the vault is empty for the LP class (`lp_shares == 0`), shares are minted 1:1 (1 share per 1 USDC). The first step of a deposit is always a "ledger sync" that credits the period's profit or loss to the existing share classes. New shares are then minted at the post-sync NAV, so depositors do not capture or share in PnL that accrued before their deposit. See [Profit & Loss → Ledger sync](/docs/vaults/profit-and-loss.md#ledger-sync) for the formula. ### Deposit constraints | Constraint | Source | Effect | | ----------------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Minimum deposit | Constant 10 USDC. | Smaller amounts are rejected. | | Deposit cap | Vault config `deposit_cap`. | Total LP balance after the deposit cannot exceed the cap. The manager's own deposits are not counted against the cap. | | Available balance | Standard cross-margin check. | The depositor must have sufficient `available_to_withdraw` to cover the deposit, exactly as for any other USDC outflow. | ### Withdrawing Withdrawals are denominated in shares. The amount returned is your proportional claim on the LP-side balance after the period's PnL has been credited. ``` NAV_per_share_at_withdraw = lp_balance / lp_shares (after ledger sync) amount_withdrawn = shares_redeemed * NAV_per_share_at_withdraw = shares_redeemed * lp_balance / lp_shares ``` A withdrawal is permitted only if all of the following hold: * The depositor holds at least the requested number of shares. * If `deposit_min_duration_ms > 0` is configured, at least that many milliseconds have elapsed since the depositor's most recent deposit. Each new deposit resets the timer for the depositor's entire share balance, not just the new shares. * If `withdraw_window_s` and `withdraw_duration_s` are configured, the current time falls within an open window. The window check is `current_unix_time_s mod withdraw_window_s < withdraw_duration_s`, which means windows are anchored to the Unix epoch (1970-01-01 00:00:00 UTC), not to the vault's creation time. For example, with `withdraw_window_s = 86400` (1 day) and `withdraw_duration_s = 3600` (1 hour), withdrawals are open from 00:00 to 01:00 UTC every day. * The vault has sufficient `available_to_withdraw`. This is the lake account's free balance after subtracting margin reserved for open positions and orders. If the manager has the vault fully deployed in positions, withdrawals may be partially unfilled until the manager closes or de-risks. The redeemed amount is paid in USDC into the depositor's account immediately. The vault's high-water mark is reduced by the same dollar amount paid out, so future performance fees are charged on profit relative to the post-withdrawal balance rather than the pre-withdrawal peak. See [Profit & Loss → High-water mark](/docs/vaults/profit-and-loss.md#high-water-mark) for the exact behavior under deposits and withdrawals. ### Risks A depositor in a vault can lose up to their entire deposit. There is no Pacifica-funded backstop for vault losses beyond the standard exchange liquidation engine that protects the broader orderbook. Specific exposures to be aware of: * **Trading risk.** The manager's positions can lose money. Losses are taken from the LP balance pro-rata with the manager's balance. Cross-margin liquidations reduce the vault's USDC and may force a withdrawal queue if the lake account's `available_to_withdraw` drops to zero. * **Manager risk.** The manager has discretion within the configured constraints. The creator may also widen those constraints over time (e.g., adding symbols to the whitelist). See [Managing a Vault → Mutability](/docs/vaults/managing-a-vault.md#mutability). * **Liquidity risk.** Withdrawals require the vault to have free balance. Large drawdowns or fully-deployed positions can delay withdrawals until the manager closes positions or until liquidations run. * **Window risk.** A vault with a withdrawal window restriction is not redeemable outside the window. Plan around the configured cycle. * **Counterparty risk.** A vault deployed by a third party is not Pacifica-operated and is not insured by Pacifica. Treat it accordingly. ### Where to find vault state Vault metadata, configuration, current balances, and share counts are exposed through the standard account and vault endpoints (documented separately under API Documentation). The vault's address is a normal Pacifica account address and can also be inspected on the trading interface like any other account. --- # 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://pacifica.gitbook.io/docs/vaults/depositing.md?ask= ``` 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.