> ## 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 vault works
> Vault shares, epochs, the strike, requests and claims. One move for a liquidity provider.
The vault holds the USDC that pays every reward. Liquidity providers own it through **vault shares**, a standard SPL token.
> [!NOTE]
>
> **Closed to outside deposits at launch.** The vault opens to outside liquidity only after the external audit and legal review.
## 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 vault's solvency.
* The share price is the vault'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 vault's own ledger, `total_assets`, updated by every ticket: credited when a ticket 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 …). The live epoch length is in `Config`.
* 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 ticket 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.
Requests made during an epoch clear together, at one price set after the close.
### 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 ticket opened before the close is still open.
It prices on the vault's settled assets as they stood at the close, leaving out tickets 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 tickets 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 tickets cannot delay it.
## One move: the request
A liquidity provider sends **one transaction**, the request. Keepers do the rest because each step is paid.
**1. Request**
`request_deposit(amount)` moves USDC from your wallet into the deposit queue, held apart from the vault'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.
**2. Strike**
After the epoch closes and is clean, a keeper strikes it.
**3. Claim**
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.
Under the default 10-minute epochs, the whole cycle takes about ten minutes plus the wait for open tickets 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 vault | 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 vault |
| 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 tickets 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 vault's return comes from
There is no token, emission or subsidy. The vault earns because every payout table must leave it a margin: at least the 100 bps vault margin floor of every ticket price, plus whatever margin the payout tables leave above the floor, the protocol share and the app shares. Over a period:
```
expected vault result = vault margin × ticket volume
```
At the 2 % minimum margin. Payout tables with a larger margin leave the vault more.
Per year, that is about the vault margin times how many times the vault's size is spent on tickets each month, times 12. For a 1 000 000 USDC vault at the 100 bps floor:
| Monthly ticket volume | Turnover | Yearly return, in expectation |
| - | - | - |
| 1 000 000 USDC | once a month | about 12 % |
| 2 000 000 USDC | twice a month | about 24 % |
| 3 000 000 USDC | three times a month | about 36 % |
These are worked examples, not a forecast. Payout tables with a margin above the floor pay the vault more; capital arriving faster than volume lowers the turnover. The realised result adds the variance of the draws, which can be negative: the margin is guaranteed in expectation by the payout table check, the outcomes are not, and a month can end down, especially at low volume. Read [Risks](https://docs.fade.finance/liquidity/risks.md) before depositing.
The minimum margin is also the most demanding one for capacity. At 2 % the vault margin is 100 bps, so one ticket may reserve at most 0.5 × 1 % = 0.5 % of the free balance (the Kelly term of the per-ticket cap), against 1.25 % at a 3.5 % margin. A large top payout at the minimum margin needs a vault 2.5 times larger. See [Sizing a payout](https://docs.fade.finance/build/payout-tables.md#sizing-a-payout).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.