The liquidity pool

One shared pool takes the other side of every position and funds every win. How a win is paid, how the pool is read and how the pool loses money.

There is one shared pool. It takes the other side of every position on every market, funds every win, and receives a share of the fees traders pay. The pool belongs to the protocol.

The pool’s losses are real and they are not theoretical. The pool funds every winning position out of its own assets. A run of trader wins draws it down. Nothing about the design prevents that. A win larger than the pool can pay at once is paid in order, from a queue: see how a win is paid.

The program has no instruction to deposit into the pool and none to redeem from it.

The numbers that describe the pool

Read them together. Either one alone will mislead you.

Gauge	What it means
lpAssets	The pool’s assets: the vault’s token balance less any payout already settled and owed to a named trader, and nothing else. It does not subtract what the queue still owes: subtract the unfunded queue and the parked amount before you read it as free money.
withdrawable	The SDK’s name for lpAssets less every stake the pool holds (vault.totalReserved). Nobody can withdraw from the pool, so it is not an amount anyone can take out. It does not subtract the unfunded queue or the parked amount, so it is not the cash a fill can use.
fOpen	The free cash a fill is admitted against, from capitalGauges: the token balance less the payouts owed to named traders, less every stake, less the unfunded queue and the parked amount. It is 0 while any amount is parked or the cash cannot fund the whole unfunded queue. The cover rule and the capacity floors decide what a fill can take.

vaultGauges also returns openable, pendingRedemptionValue and sharePriceMicro. They describe deposits and redemptions, which the program does not offer, so do not show them.

import {
  capitalGauges, capitalPda, cashInputs, decodeCapitalState, decodeVault, vaultGauges, vaultPda,
} from '@rekt-trading/1000x';
import { Connection } from '@solana/web3.js';

// `vaultTokenBalance` is the balance of the SPL account that `vault.tokenAccount` names: read it, do not guess.
export async function poolGauges(connection: Connection, vaultTokenBalance: bigint) {
  const [vaultInfo, capitalInfo] = await Promise.all([
    connection.getAccountInfo(vaultPda().address, 'confirmed'),
    connection.getAccountInfo(capitalPda().address, 'confirmed'),
  ]);
  if (!vaultInfo || !capitalInfo) throw new Error('a pool account does not exist');
  const vault = decodeVault(new Uint8Array(vaultInfo.data));
  const capital = decodeCapitalState(new Uint8Array(capitalInfo.data));
  return {
    pool: vaultGauges(vault, vaultTokenBalance), // lpAssets, withdrawable
    cash: capitalGauges(capital, cashInputs(vault, capital, vaultTokenBalance)), // fOpen, queued, parked
  };
}

How a win is paid

A win is paid in full. Part of it may be paid later, in order. There is no guaranteed time. The amount queued ahead of you is shown.

• Opening takes the stake and nothing else. The venue decides at the fill whether a position fits, against a rule the program applies per market and in total. An order that does not fit is returned with the whole stake and no fee. A hedge, a smaller target and a close are never refused by it.
• At a close the stake comes back at once. The profit is paid from the pool’s free cash when no earlier claim is unfunded; whatever is left joins the queue. The settlement events say how much was paid now and how much was queued.
• The queue is first in, first out, and cash that other positions leave in the pool funds it. The protocol’s own share of a close is paid last, and not at all while any claim is unfunded.
• Anyone can deliver funded money with pay_queue, in line order, to the wallet recorded on the account. Money for an account that cannot receive it is held for that account under the unclaimed rule below.
• When the line is nearly full, a second unpaid win of the same account waits behind its first.
• A book with an unpaid entry cannot close its account until it is paid.

A client shows what happened and where the account stands, never a forecast: at a close, the amount paid now and the amount queued; while queued, the amount ahead, the entries ahead, what has been funded, what has been delivered and the entry’s age. It does not show an estimate of a wait.

Wind-down

The operator can wind the venue down. Positions still end by their own rules. An order or an add sent during a wind-down is taken but never filled: it is returned, and the whole stake comes back. A target raise is refused.

How the pool loses money

• Traders win. The pool pays. Over a run of favourable outcomes for traders, the pool’s assets fall, and they may not come back.
• Capacity is limited. A run of large wins can draw the pool down, and what it cannot pay at once is paid from the queue.
• Nothing will catch the pool. There is no insurance fund standing behind the pool, no backstop, no protocol treasury commitment and no third party standing behind a balance. See the insurance fund.
• Parameters are governed. Fees, bounds and caps can be changed on chain by the protocol’s authority. Every change is public and readable.
• This software has not been audited by a third party.

What reaches the pool

Five things reach the pool, and they are not the same kind of income:

• What losing positions lose, and the part of a gain the terms withhold. The loss of a losing position stays in the pool, and so does the part of each gain that the terms withhold.
• A share of the entry fee and of the exit fee. Traders pay an entry fee on every open and on every increment they add later (read config.params.entryFeeBps; it is 0, so opens are free), and an exit fee on most closes (not on one paid at the barrier). The exit fee is a share of the exit value, higher on a loss than on a win; the rates are on Fees and limits.
• A share of what losing positions forfeit. The loss tax is divided between the pool and the protocol.
• Funding, in full. Its rate is 0, so it collects nothing: Fees and limits has the rate.
• An unclaimed payout that expires. See below.

What that adds up to depends on how much is traded, at what sizes, against a pool of what size — read it from the on-chain accounts the SDK exposes, live, rather than from a number on this page.

An expired unclaimed payout is released to the pool

When a settlement cannot deliver a payout — the trader closed or froze their USDC account — the money is escrowed inside the vault and held against that trader’s name. It sits outside lpAssets for the whole of that time, so it is not part of the pool’s assets.

If nobody claims it before config.params.unclaimedPayoutExpiryS has passed, anyone may sweep it, and the sweep releases the claim rather than moving any tokens. The money was already in the vault; dropping the obligation raises lpAssets by exactly that amount.

The insurance fund

There is no insurance fund standing behind the pool, and no rule obliges the protocol to cover the pool’s loss. A win is paid from the pool’s assets and from nothing else.

Before you rely on the pool

Read the risk disclosure

The complete list of what can go wrong, for the pool and for traders, in plain language.