The pools that back every bet.

A player placing a SOL bet wants their win (or refund) in SOL. A player placing a BUX bet wants it in BUX. Mixing the two would require an oracle and swap logic and introduce slippage risk that has nothing to do with the game. Keeping them separate also lets LPs take explicit exposure to whichever token they care about — you can be long SOL without touching BUX, or vice versa.

The SOL vault holds native lamports. Its PDA is a SystemAccount seeded as [b"sol_vault"]. Transfers out of it happen via anchor_lang::system_program::transfer with the vault's PDA signer seeds. There is no ATA, no token program, no SPL wrapper.

The BUX vault, by contrast, is a proper SPL token account at [b"bux_token_account"]. Its authority is itself (the program signs CPIs with the same PDA that holds the tokens).

Without the subtraction, the LP price would spike the instant a bet is placed (the vault balance just grew by the wager) and crash the instant it's settled as a win. Subtracting total_liability smooths that out by pre-booking the worst-case payout. The price only moves when the bet is actually resolved — up on losses, down on wins.

Start with a SOL vault holding 100 SOL and 100 SOL-LP outstanding. LP price = 1.0. A bettor wagers 1 SOL at 1.98× on Win All 2.

• Immediately after placement: vault holds 101 SOL, total_liability += 1.98 SOL. Effective balance = 101 − 1.98 = 99.02 SOL. LP price = 0.9902. A small dip because we've booked the worst case.
• If the bettor loses: total_liability −= 1.98, vault still holds 101 SOL. Effective = 101. LP price = 1.01. You made 1% on the house edge.
• If the bettor wins: vault pays 1.98 SOL (now holds 99.02), total_liability −= 1.98. Effective = 99.02. LP price = 0.9902. You're down 0.98%.

That symmetric movement — small up on losses, small down on wins — is the LP's return profile. Over thousands of bets, the house edge wins.

1. 1
   Enter an amount

   The /pool/sol or /pool/bux page previews how many LP tokens you'll receive based on the current on-chain price. That preview is computed from the exact same formula the program uses, so it's not a quote — it's the answer (subject to tiny slippage if a bet settles between your click and landing).

2. 2
   Click deposit, sign the transaction

   The settler builds an unsigned deposit_sol or deposit_bux transaction. Your wallet signs it. If you're using Web3Auth with no SOL, the settler partial-signs as fee payer so you don't need a balance for fees.

3. 3
   The program moves tokens and mints LP

   On-chain, the program validates amount > 0, computes the LP tokens to mint, transfers your tokens into the vault, and mints LP tokens to your ATA — creating that ATA if it doesn't exist yet.

4. 4
   Cost basis is recorded locally

   When the transaction confirms, the LiveView records your deposit (amount + LP price at deposit time) into Mnesia's user_pool_positions table so we can show you accurate P/L later. This is local bookkeeping — the on-chain LP tokens are the source of truth for your share.

There is no deposit or withdrawal fee. The house takes its edge from bet outcomes, not from LP flows. Gas (roughly 5,000 lamports) is the only cost, and in Web3Auth mode the settler can sponsor it for you.

def record_deposit(user_id, vault_type, amount, lp_price) do
  lp_received = amount / lp_price
  case get(user_id, vault_type) do
    nil ->
      write(user_id, vault_type, amount, lp_received, 0.0)
    %{total_cost: tc, total_lp: tl, realized_gain: rg} ->
      write(user_id, vault_type, tc + amount, tl + lp_received, rg)
  end
end

Every deposit grows your cost basis by the amount deposited and your LP balance by amount / lp_price. Your average cost per LP is always total_cost / total_lp.

def record_withdraw(user_id, vault_type, lp_burned, lp_price) do
  %{total_cost: tc, total_lp: tl, realized_gain: rg} = get(user_id, vault_type)
  avg_cost_per_lp  = tc / tl
  cost_removed     = lp_burned * avg_cost_per_lp
  proceeds         = lp_burned * lp_price
  realized_delta   = proceeds - cost_removed      # can be negative

  new_cost = tc - cost_removed
  new_lp   = tl - lp_burned
  write(user_id, vault_type, new_cost, new_lp, rg + realized_delta)
end

When you burn LP, your cost basis drops proportionally and the difference between proceeds and the retired cost is added to realized_gain. A full withdrawal zeros out both total_cost and total_lp (floating-point residuals below 10⁻⁹ are clamped to zero).

If you acquired SOL-LP or BUX-LP before the position tracking existed (or transferred from another wallet), you won't have a row in user_pool_positions. On your first load of the detail page we call seed_if_missing/4, which writes cost_basis = current_lp × current_lp_price and realized_gain = 0.

Translation: your P/L will read as zero on that first visit, and accrue from there. If you want true historical cost, you'd need to read your on-chain transaction history and reconstruct it manually.

• Periodic poll — LpPriceTracker pulls /pool-stats from the settler once per minute. Writes are throttled: if the last write was <60s ago we skip.
• Event-driven — Whenever a settle_bet is confirmed, the tracker gets a {:bet_settled, vault_type} message and writes a new price point immediately with force: true, bypassing the throttle. This is why the chart jiggles the moment a bet settles.
• Pruning — Once per day we delete everything older than 30 days.

Reading "the last 30 days" at 1-minute resolution would be ~43,000 points, too many to render smoothly. Each timeframe has a bucket size; points are grouped into buckets and the last point of each bucket is returned.

Below 500 points we skip downsampling entirely, so short histories look identical to raw data.

The LiveView subscribes to pool_chart:vault_type on mount. When a new point is recorded, PubSub fires a chart_point message. The LiveView pushes a chart_update JS event, the chart hook appends it without re-fetching history.

A single lucky bettor can push LP price down by several percent in a few seconds. Five wins in a row at the 31.68× difficulty — each at the maximum bet — could dent the pool by a material percentage even though the expected value is strongly positive. Drawdowns of 5–10% over an hour are plausible. You have no insurance against them.

Your deposit is locked in an on-chain program. If that program has a bug that lets someone drain the vault, your LP tokens go to zero with it. Our program has been reviewed (see the Security Audit), but no review eliminates this risk entirely.

The program has an authority keypair that can pause operations, register new games, and change per-game config (including multipliers). A compromised authority key could in principle push multipliers above 2×, turning every bet into a negative-EV trade for the LP. We document this fully in the audit and are actively planning to migrate authority to a multisig before mainnet. For now, LPs are trusting the authority keypair is secure.

Withdrawals are capped at available balance — the vault balance minus the rent buffer minus the outstanding liability. If many bets are pending simultaneously, a withdrawal might fail until those bets settle. In practice bets settle in seconds, so this is a latency issue, not a solvency one.