> ## 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 it works

> Open, draw, pay. One signature for the user, odds on-chain before the draw.

Every payout on Fade is a **wager**: a stake, a paytable, and an account that holds both plus the outcome once it is drawn. A wager goes through three steps.

<Steps>
  <Step title="The app opens the wager">
    One instruction, `open_wager`, carries the stake, the paytable (each outcome's probability and multiplier), the app's fee and the account the payout will go to. In that instruction Fade checks the paytable in exact integers, checks that the worst-case payout fits the pool's caps, moves the stake, splits out the fees and stores everything in the wager account. If any check fails, the whole transaction fails and nothing moves.
  </Step>

  <Step title="The oracle draws">
    From two slots after the open, anyone may call `request_randomness`. The program derives the oracle seed on-chain from the first block hash after the open, a hash that did not exist when the wager was placed, and asks ORAO's VRF for a random value. ORAO's authorities fulfil the request, typically within a few seconds.
  </Step>

  <Step title="The pool pays">
    Once the randomness is written, anyone may call `settle_wager`. The program maps the random value onto the stored paytable and pays the outcome in USDC to the beneficiary named at open. The wager account closes and its rent returns to whoever paid it.
  </Step>
</Steps>

## One signature for the user

Only the first step needs the app's signature, and the user's when the stake comes from the user's wallet. The other two are permissionless and prepaid: every wager carries a crank fee of 250 000 lamports, 50 000 for whoever requests the randomness and 200 000 for whoever settles. A **keeper** sends them. Fade runs a public keeper at `api.fade.finance` that apps can hand their wagers to, and anyone can run their own. See [Settlement and keepers](/build/settlement).

So a user who pays at a checkout, swaps on a DEX or claims a reward signs one transaction, the one they were signing anyway, and sees the result a few seconds later.

## Odds before the draw

The paytable is an argument of `open_wager` and is copied into the wager account before the randomness exists. Nothing changes it afterwards: settlement reads the snapshot, never live configuration. Anyone can open the wager in an explorer, or decode the open transaction, and check that what the app advertised is what the program applies.

The check that admits a paytable is a single inequality on integers:

```
Σ p_i · m_i  ≤  (10 000 − edge_bps) · 1 000 000 000
```

with each probability `p_i` in billionths (they must sum to exactly 1 000 000 000) and each multiplier `m_i` in basis points (10 000 is 1×). A paytable that pays out more than it takes in on average never opens. See [Paytables](/build/paytables).

## Who takes the other side

The **pool**: one USDC vault shared by every app, funded by liquidity providers. When a wager opens, the pool reserves its worst case, the largest payout the paytable can produce less what the stake brought in. A wager whose worst case is too large for the pool as it stands is refused at open. Caps are ratios of the pool's live state, so what the pool can back grows with it. See [How the pool works](/liquidity/pool).

## What the app chooses and what the protocol fixes

| The app chooses | The protocol fixes |
| - | - |
| The stake and who funds it | The randomness source, and when it is drawn |
| The paytable: 1 to 32 outcomes, any shape | The LP floor (100 bps) and the protocol fee (20 bps) |
| The declared edge, at or above 120 bps plus its own fee | The per-wager cap, the app's exposure ceiling, the breakers |
| Its own fee, 0 to 500 bps | One draw per wager, against a distribution frozen at open |
| The beneficiary of the payout | Settlement: permissionless, and never refusable |

## A wager's life on-chain

```mermaid theme={null}
stateDiagram-v2
    [*] --> Open: open_wager (app signs)
    Open --> Requested: request_randomness (anyone, from open slot + 2)
    Requested --> Settled: settle_wager (anyone, once ORAO has fulfilled)
    Requested --> PayoutPending: settle_wager, beneficiary cannot receive
    PayoutPending --> Settled: claim_payout (anyone)
    Open --> Expired: expire_wager (anyone, after T_SETTLE)
    Requested --> Expired: expire_wager (anyone, after T_SETTLE, if never fulfilled)
    Settled --> [*]
    Expired --> [*]
```

If the randomness never arrives within `T_SETTLE` (150 slots, about a minute), anyone may expire the wager: the stake is **forfeited to the pool**, never returned. A return would let whoever controls the oracle withhold losing draws for free. Under forfeiture that strategy gains nothing. The reasoning is on [Randomness](/protocol/randomness).

## Next

<CardGroup cols={2}>
  <Card title="Try it" icon="flask" href="/try-it">Play the devnet demos.</Card>
  <Card title="Integration overview" icon="plug" href="/build/overview">Who signs what, and what an app needs.</Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.