Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/pacifica-fi/docs-migrate/llms.txt

Use this file to discover all available pages before exploring further.

Vaults are user-deployed managed trading pools that run on top of Pacifica’s full trading infrastructure. A creator sets up the vault with a configuration, a designated manager trades the pooled capital, and depositors (LPs) hold shares that represent their proportional claim on the vault’s net asset value. Because a vault is a real Pacifica trading account, every order it places is subject to the same margin model, mark-price rules, liquidation engine, and fee schedule as any other account on the exchange.
Vault accounts are ordinary Pacifica accounts. They are subject to normal margin requirements, mark-price calculations, and liquidation rules. Pacifica does not audit, vet, or insure third-party vault managers.

​
Roles

RoleDescription
CreatorThe address that calls create_lake and pays the 10 USDC creation fee. The creator sets the vault’s initial configuration and retains the ability to update mutable fields (deposit cap, whitelist, blacklist, leverage caps) after creation. The creator and manager may be the same address.
ManagerThe address authorized to place orders on behalf of the vault. Set at creation, or claimed later via claim_lake_manager on a manager-less vault. The manager deposits capital and holds Manager Shares. Their earnings come from their pro-rata share of returns plus an optional performance fee.
LP / DepositorAny address that deposits USDC into the vault. Receives LP Shares priced at the vault’s NAV at the time of deposit. LPs bear trading risk proportional to their share of the pool.

​
Share Classes

A vault maintains two independent share classes against the same underlying account balance and set of positions:
  • Manager Shares are minted when the manager deposits and burned when the manager withdraws. They route the manager’s pro-rata profits and losses through manager-side economics, including the performance fee on gains above the high-water mark.
  • LP Shares are minted to all other depositors. LP share pricing tracks the LP-side balance, which moves with the vault’s PnL after the performance fee is applied.
Both classes share one account balance and one set of positions. PnL is split between them pro-rata before any per-class economics are applied.

​
Creating a Vault

1

Prepare your configuration

Decide on your vault’s parameters: symbol whitelist/blacklist, per-symbol leverage caps, deposit cap, performance fee (manager_profit_share), minimum lock-up (deposit_min_duration_ms), manager balance requirements, and any withdrawal window settings. All fields are optional — omitting a field means no constraint of that type is applied.
2

Choose a manager address

Specify a manager address in the creation call. If you leave it blank, the vault is created as a “fresh vault” — any address can later claim the manager seat by depositing at least 10 USDC and meeting the manager_min_balance_portion requirement (if configured).
3

Optionally add a nickname

Nicknames are unique across all vaults and appear on the vaults page. A vault may be left unnamed.
4

Submit the creation call

Call create_lake signed by the creator’s wallet. A 10 USDC creation fee is charged. The vault is assigned a fresh address and starts with zero balance, zero shares, and no open positions.
5

Seed the vault

The creator may include an initial seed deposit in the same call, or the manager can deposit later via deposit_to_lake. If manager_min_balance_portion is set, the vault will not accept LP capital until the manager’s balance satisfies that minimum ratio.
A vault may itself be designated as the manager of another vault (a “subvault”), but nesting is limited to one level.

​
Depositing as an LP

Deposits are converted into LP Shares at the vault’s current NAV per share. Before a deposit is processed, the engine runs a ledger sync that credits the period’s accumulated PnL to existing shareholders, ensuring new depositors do not retroactively capture gains or losses that occurred before their entry. 
NAV_per_share_before_deposit = lp_balance / lp_shares    (after ledger sync)
shares_minted                = deposit_amount * lp_shares / lp_balance
If no LP shares exist yet, shares are minted 1:1 (1 share per 1 USDC).

​
Deposit Constraints

ConstraintValue / SourceEffect
Minimum deposit10 USDC (constant)Smaller amounts are rejected
Deposit capdeposit_cap in vault configTotal LP balance after deposit cannot exceed this cap; manager deposits are excluded from the cap
Available balanceStandard cross-margin checkDepositor must have sufficient available_to_withdraw

​
Withdrawing

Withdrawals are denominated in shares. The amount you receive 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 * lp_balance / lp_shares
A withdrawal is permitted only when all of the following hold:
  • You hold at least the requested number of shares.
  • If deposit_min_duration_ms > 0, that many milliseconds have elapsed since your most recent deposit. Each new deposit resets the timer for your entire share balance.
  • If withdraw_window_s and withdraw_duration_s are configured, the current time falls within an open window: current_unix_time_s mod withdraw_window_s < withdraw_duration_s. Windows are anchored to the Unix epoch, not to the vault’s creation time.
  • The vault has sufficient available_to_withdraw. If the manager has the vault fully deployed in positions, withdrawals may be delayed until positions are reduced.
A depositor can lose up to their entire deposit. Cross-margin liquidations reduce the vault’s USDC balance and can temporarily push available_to_withdraw to zero, delaying redemptions. Vaults with withdrawal windows are not redeemable outside those windows.

​
Depositor Risks

Before depositing, review the vault’s configuration and understand the specific exposures:
RiskDescription
Trading riskThe manager’s positions can lose money. Losses are taken from the LP balance pro-rata with the manager’s balance. Liquidations reduce the vault’s USDC and may force a withdrawal queue if available_to_withdraw drops to zero.
Manager riskThe manager has full discretion within the configured constraints. The creator may also widen those constraints over time — for example, adding new symbols to the whitelist or increasing leverage caps.
Liquidity riskWithdrawals require the vault to have free balance. Large drawdowns or fully-deployed positions can delay withdrawals until the manager closes positions or liquidations run.
Window riskA vault with withdraw_window_s / withdraw_duration_s configured is not redeemable outside the open window. Plan around the configured cycle.
Counterparty riskA vault deployed by a third party is not Pacifica-operated and is not insured by Pacifica. Pacifica does not audit, vet, or endorse any vault manager.

​
Managing a Vault

The vault is a standard Pacifica account. The manager places orders through the trading interface or via the standard order REST endpoints, signed by the manager’s wallet or by an agent key bound to the manager’s address. All Pacifica trading rules apply: order types, margin model, funding rates, mark-price liquidations. The manager is additionally bound by the vault’s own trading constraints:
ConstraintBehavior
whitelistOrder symbol must be in the whitelist. If unset, all listed symbols are permitted.
blacklistOrder symbol must not be in the blacklist. Applied after the whitelist; a symbol in both lists is always blocked.
max_leverages[symbol]Leverage on the order cannot exceed this per-symbol cap. If unset, the exchange-default max leverage applies.
trading_haltIf true, all order submissions are rejected. Set automatically by the liquidation engine; cleared by a manager top-up past manager_min_balance_portion.
Constraint violations are returned as errors at order submission time and consume no state.

​
Configuration Mutability

FieldMutable by Creator?
deposit_cap✅ Yes
whitelist✅ Yes
blacklist✅ Yes
max_leverages✅ Yes
manager_profit_share❌ No (fixed at creation)
deposit_min_duration_ms❌ No (fixed at creation)
manager_min_balance_portion❌ No (fixed at creation)
manager_liquidation_balance_portion❌ No (fixed at creation)
withdraw_window_s / withdraw_duration_s❌ No (fixed at creation)
Mutable field updates take effect immediately on the next operation, with no notice period for depositors.

​
Profit & Loss

​
Ledger Sync

Every deposit or withdrawal triggers a ledger sync that attributes the period’s accumulated PnL to existing share classes before any share count changes: 
fee_eligible_profit  = max(current_equity - high_watermark, 0)
performance_fee      = fee_eligible_profit * manager_profit_share
remaining_pnl        = period_pnl - performance_fee

lp_ratio  = lp_balance      / (lp_balance + manager_balance)
mgr_ratio = manager_balance / (lp_balance + manager_balance)

lp_delta  = remaining_pnl * lp_ratio
mgr_delta = remaining_pnl * mgr_ratio + performance_fee

high_watermark = max(high_watermark, current_equity)
If manager_profit_share is unset, no performance fee is taken.

​
Performance Fee and High-Water Mark

The performance fee is charged only on equity above the previous all-time peak (the high-water mark, or HWM). If the vault is in drawdown, no fee accrues until the prior peak is fully recovered. The HWM adjusts for capital flows so that deposits and withdrawals do not artificially trigger or skip fees:
  • On deposit: HWM increases by the deposit amount.
  • On withdrawal: HWM decreases by the gross dollar amount paid out.
The HWM never moves down through trading losses — drawdowns must be recovered before the manager earns another performance fee.

​
Worked Example: Profit Period

A vault with manager_profit_share = 0.20, starting at equity 1,000 (LP: 800, Manager: 200, HWM: 1,000), trades up to 1,100: 
period_pnl           = +100
performance_fee      = 100 * 0.20 = 20
remaining_pnl        = 80

lp_delta             = 80 * 0.8 = 64    →  lp_balance:      864
mgr_delta            = 80 * 0.2 + 20 = 36  →  manager_balance: 236
high_watermark       → 1100
NAV per LP share rises from 1.00 → 1.08; NAV per Manager Share rises 1.00 → 1.18 (the manager captured both their pro-rata profit and the 20 USDC performance fee).

​
Loss Attribution

If PnL over a period is negative, the loss is split pro-rata between LP and Manager balances. No performance fee accrues and the HWM does not change. 
loss      = -period_pnl
lp_ratio  = lp_balance      / (lp_balance + manager_balance)
mgr_ratio = manager_balance / (lp_balance + manager_balance)

lp_delta  = -loss * lp_ratio
mgr_delta = -loss * mgr_ratio
high_watermark unchanged

​
Worked Example: Loss Period

The same vault starts a period at equity 1,000 (LP: 800, Manager: 200, HWM: 1,000) and trades down to 900: 
loss       = 100
lp_ratio   = 0.8,  mgr_ratio = 0.2

lp_delta   = -80   →  lp_balance:      720
mgr_delta  = -20   →  manager_balance: 180
high_watermark     →  1000  (unchanged)
The HWM remains at 1,000. The manager will not earn another performance fee until equity recovers above 1,000.

​
Risk Controls

​
Manager Balance Thresholds

The manager’s balance portion is: 
manager_balance_portion = manager_balance / (manager_balance + lp_balance)
Two immutable thresholds govern enforcement:
ThresholdRole
manager_liquidation_balance_portionWhen the live ratio falls below this value, the engine sets trading_halt = true and liquidates open positions.
manager_min_balance_portionRequired to claim the manager seat on a fresh vault and to lift a halt after liquidation. Must be strictly greater than manager_liquidation_balance_portion.
The gap between the two thresholds acts as an operating buffer. If neither is configured, the engine does not auto-halt the vault on manager-balance grounds.

​
Trading Halt and Lift

When a halt is triggered, all order submissions on the vault are rejected. The manager lifts the halt by depositing enough capital to bring manager_balance_portion back above manager_min_balance_portion.
If neither manager_min_balance_portion nor manager_liquidation_balance_portion is configured, the engine will not auto-halt the vault for manager-balance reasons. LPs are then exposed to a manager who may hold zero capital in the vault.

​
API Reference

Full REST endpoints for creating vaults, depositing, withdrawing, and querying vault state are documented at /api/rest/vaults.

Build docs developers (and LLMs) love

Get started for freeTalk to us