Depositing into a Vault

How deposits, shares, and withdrawals work for vault LPs.

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.

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).

• 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 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 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.

• 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.