Skip to main content
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.
1

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.
2

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.
3

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.

​
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. 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:
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.

​
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.

​
What the app chooses and what the protocol fixes

​
A wager’s life on-chain

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.

​
Next

Try it

Play the devnet demos.

Integration overview

Who signs what, and what an app needs.