> ## Documentation Index > Fetch the complete documentation index at: https://docs.fade.finance/llms.txt > Use this file to discover all available pages before exploring further. # How the pool works > Shares, epochs, the strike, requests and claims. One move for a liquidity provider. The pool is one USDC vault that takes the other side of every wager. Liquidity providers own it through **shares**, a standard SPL token. ## Shares and the share price * A share is an SPL token with 9 decimals, minted and burned only by the strike. Shares are **transferable**: a holder can sell them to anyone at a price the two agree. That secondary market never touches the pool's solvency. * The share price is the pool's assets over its shares, with a fixed virtual offset (1 000 virtual share units against 1 virtual asset unit) so that the first depositor cannot manipulate it. * Assets are the pool's own ledger, `total_assets`, updated by every wager: credited when a wager opens, debited when it pays out. **No token balance is ever read to price anything**, so a donation or a stray transfer cannot move the price. ## Epochs: one price per batch Deposits and withdrawals are not instant. They join an **epoch**, a batch of requests that all clear at one price. * The first request opens an epoch, which closes at the next multiple of the epoch length on the UTC clock: every 10 minutes by default (:00, :10, :20 …), **every 120 seconds on devnet**. * A request made after the close joins the next epoch. At most two epochs are live: the one waiting for its price and the one filling behind it. A period with no request creates nothing and costs nothing. * The price is computed **after** the close, once every wager opened before the close has settled or expired. This is forward pricing: arriving after a result is known buys nothing, because the price you get includes that result. ### The strike `strike_epoch` prices an epoch and processes its requests. Anyone may send it, once: 1. the epoch's close has passed, and 2. no wager opened before the close is still open. It prices on the pool's settled assets as they stood at the close, leaving out wagers opened after the close (their credits while open, their results once closed). It mints shares for the epoch's deposits, burns shares for its withdrawals, writes an epoch record with the price, and pays the striker a flat 200 000 lamports from the strike fund. Its cost does not depend on the number of requests. A strike waits at most for the wagers open at the close: about a minute in practice (`T_SETTLE` for unfulfilled ones, the settler's incentive for fulfilled ones). A stream of new wagers cannot delay it. ## One move: the request A liquidity provider sends **one transaction**, the request. Keepers do the rest because each step is paid. `request_deposit(amount)` moves USDC from your wallet into the deposit queue, held apart from the pool's assets until the strike. `request_withdraw(shares)` moves shares into escrow. Each request prepays a 200 000-lamport `CLAIM_FEE`, and a 200 000-lamport `STRIKE_FEE` only while the strike fund is below its 0.05 SOL target. The request account's rent (about 0.001 SOL) is advanced, not spent. After the epoch closes and is clean, a keeper strikes it. A keeper sends `claim_deposit` or `claim_withdraw`, and collects your `CLAIM_FEE`. Your shares or your USDC arrive in your wallet's associated token account, and the request's rent comes back to you in the same transaction. If you claim yourself, you keep the fee. On devnet the whole cycle takes a couple of minutes; under the default 10-minute epochs, about ten minutes plus the wait for open wagers to close. ## Rules | Rule | Value | Why | | - | - | - | | Minimum deposit request | 1 USDC | Spam | | Minimum withdrawal request | 1 share, or your whole balance | No position is stranded below the minimum | | First deposit into an empty pool | at least 100 USDC | Closes the first-depositor inflation attack | | Cancelling a request | Not possible | A cancellable request is a free option on the epoch price | | Rounding | Down on both legs | The remainder stays in the pool | | Requests per owner | One deposit and one withdrawal per epoch; a second request in the same epoch tops up the first | Bounded state | | Transaction composition | A request's transaction may only contain compute budget, system, token, associated token and Fade instructions | Defence in depth around pricing | ### Rationed withdrawals A withdrawal can never take capital that open wagers have reserved. If a strike cannot pay every queued withdrawal in full, it pays each the same fraction and rolls the rest into the next epoch. A withdrawal served across several epochs is still claimed once, with one claim that pays the exact total. ### If your account cannot receive If your token account cannot receive at the claim (closed or frozen), the claim still completes its bookkeeping and **parks** what it owes on your request. A later claim delivers it, to that account once it can receive, or with your signature to another account of yours. ## Where the pool's return comes from There is no token, emission or subsidy. The pool earns because every paytable must leave it an edge: at least the 100 bps LP floor of every stake, plus whatever edge the games leave above the floor, the protocol fee and the apps' fees. Over a period: ``` expected pool result = pool edge × volume wagered ``` The realised result adds the luck of the draws, which can be negative. The edge is guaranteed in expectation by the paytable check; the outcomes are not. A month can end down, especially at low volume. Read [Risks](/liquidity/risks) before depositing. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.