> ## 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.
# Design your offer
> One ticket, many shapes: how often a reward comes against how large it is, what the ticket price and the margin change, several rewards on one ticket, and what the vault can cover.
The business pays each ticket from its rewards budget, the vault pays any reward to the business, and the business credits it to its customer, who pays nothing extra. What the offer looks like is the business's choice: every ticket carries a payout table it sets before the draw. Four settings shape it, and the vault sets the ceiling:
| Setting | What it changes |
| - | - |
| **How often against how much** | The same budget pays a little to many people or a lot to a few |
| **The ticket price** | For a given reward, the chance of getting it |
| **The margin and the app share** | What comes back on average, and the vault capacity a ticket needs |
| **Several rewards** | Up to 32 outcomes on one ticket, sharing one budget |
The examples below use the 2 % margin, the smallest a payout table can declare, with no app share: 98 % of the rewards budget goes back to customers on average, 1 % to the vault and 1 % to the protocol. They are computed with the program's integer rules ([Payout tables](https://docs.fade.finance/build/payout-tables.md)). The [Ticket page](https://docs.fade.finance/try-it.md#ticket-design-your-own) of the app builds the same tables live, against the vault as it stands.
## How often, or how much
Hold the ticket price at 10 USDC. Whatever the shape, the ticket returns 9.80 USDC on average: the payout table check is `Σ p · m ≤ 9 800 × 1e9`. Spending that on a small reward makes it frequent; spending it on a large one makes it rare. These are the Ticket page's four presets:
The same 10 USDC ticket. Only the largest reward decides how large a vault must be.
| Preset | Reward | Chance | Vault, idle |
| - | - | - | - |
| **Often** | 20 USDC (2×) | about 1 in 2 | from 2 020 USDC |
| **Now and then** | 100 USDC (10×) | about 1 in 10 | from 18 020 USDC |
| **Rare and large** | 1 000 USDC (100×) | about 1 in 102 | from 198 020 USDC |
> [accordion] The exact integers
>
> ```
> Often m = 20 000 p = 490 000 000 rest p = 510 000 000, m = 0
> Now and then m = 100 000 p = 98 000 000 rest p = 902 000 000, m = 0
> Rare and large m = 1 000 000 p = 9 800 000 rest p = 990 200 000, m = 0
> ```
>
> Each satisfies `Σ p · m = 9 800 × 1e9`: exactly a 2 % margin. The liabilities are 10.10, 90.10 and 990.10 USDC.
The chance of a single reward follows from it: `0.98 ÷ multiplier` at a 2 % margin. The last column is the smallest idle vault that accepts the ticket: it depends on the **liability**, what the vault reserves while the ticket is open, the reward less the 9.90 USDC the ticket brings it (see [What the vault can cover](#what-the-vault-can-cover)).
The choice is a marketing one, not a cost one: all three cost 10 USDC and return 9.80 USDC on average. Frequent small rewards are felt by many customers; rare large ones are talked about. Only the large one needs a large vault.
## What the ticket price changes
Now hold the reward instead: 100 USDC, the whole of a 100 USDC order. The ticket price sets how often it comes, roughly `0.98 × price ÷ reward`:
The same 100 USDC reward. A higher price makes it more frequent; the vault it needs barely moves.
| Ticket price | Chance of 100 USDC | Liability | Vault, idle |
| - | - | - | - |
| 0.10 USDC (1 000×) | about 1 in 1 020 | 99.901 USDC | from 19 981 USDC |
| 0.50 USDC (200×) | about 1 in 204 | 99.505 USDC | from 19 901 USDC |
| 1 USDC (100×) | about 1 in 102 | 99.01 USDC | from 19 802 USDC |
| 2 USDC (50×) | about 1 in 51 | 98.02 USDC | from 19 604 USDC |
| 5 USDC (20×) | about 1 in 20 | 95.05 USDC | from 19 010 USDC |
| 10 USDC (10×) | about 1 in 10 | 90.10 USDC | from 18 020 USDC |
| 20 USDC (5×) | about 1 in 5 | 80.20 USDC | from 16 040 USDC |
> [accordion] The exact integers
>
> `m = ceil(100 × 10 000 ÷ price)`, rounded up so the reward is at least 100 USDC, then `p = floor(9 800 × 1e9 ÷ m)`, rounded down to keep the margin:
>
> ```
> 0.10 USDC m = 10 000 000 p = 980 000
> 0.50 USDC m = 2 000 000 p = 4 900 000
> 1 USDC m = 1 000 000 p = 9 800 000
> 2 USDC m = 500 000 p = 19 600 000
> 5 USDC m = 200 000 p = 49 000 000
> 10 USDC m = 100 000 p = 98 000 000
> 20 USDC m = 50 000 p = 196 000 000
> ```
Two things follow:
* **The reward sets the capacity, the price sets the chance.** Ten times the price makes the reward ten times as frequent, while the vault a ticket needs moves much less: from 19 802 to 18 020 USDC between a 1 and a 10 USDC ticket.
* **The price has a floor.** Every ticket pays a fixed SOL cost for its own draw, so the program sets a [minimum ticket price](https://docs.fade.finance/build/fees.md#the-minimum-ticket-price): 0.10 USDC on devnet, 7.5 USDC as the mainnet reference. Below it, group several payments into one ticket, for example one ticket per customer per day of spending, as [Card payments](https://docs.fade.finance/use-cases/card-payments.md#the-arithmetic) does.
## What comes back on average
The margin is what a ticket keeps of its price on average; the rest comes back to customers as rewards. The program checks it before the ticket opens and splits it at once ([Who pays what](https://docs.fade.finance/build/who-pays-what.md#one-margin-set-upfront)). On a 10 USDC ticket with a 100 USDC reward:
| Margin | Back on average | Chance of 100 USDC | Vault, idle |
| - | - | - | - |
| 2 %, no app share | 9.80 USDC | about 1 in 10.2 | from 18 020 USDC |
| 3 %, no app share | 9.70 USDC | about 1 in 10.3 | from 9 010 USDC |
| 4 %, 2 % app share | 9.60 USDC | about 1 in 10.4 | from 18 060 USDC |
The protocol takes 0.10 USDC in each case. The vault keeps 0.10, 0.20 and 0.10 USDC, and the app 0, 0 and 0.20 USDC.
* **The minimum, 2 %,** gives customers the most back. Its vault margin is the 1 % floor, which makes it the most demanding margin for vault capacity.
* **A margin above the minimum, with no app share,** goes to the vault. The chance barely moves (1 in 10.2 to 1 in 10.3), and the vault a ticket needs halves, since the per-ticket cap grows with the vault margin.
* **An app share** of 0 to 5 % pays the app on every ticket. It comes on top of the 2 % floor, so it lowers what comes back without widening the cap.
## Several rewards on one ticket
A payout table holds up to 32 outcomes. The Ticket page's **A bit of each** preset puts three rewards on the same 10 USDC ticket and gives each an equal part of the 9.80 USDC returned on average, `p = floor(9 800 × 1e9 ÷ 3 ÷ m)`:
| Outcome | Pays | Chance |
| - | - | - |
| Top reward | 1 000 USDC (100×) | about 1 in 306 |
| Middle reward | 100 USDC (10×) | about 1 in 31 |
| Small reward | 20 USDC (2×) | about 1 in 6 |
| Nothing | 0 | the rest |
```
Top reward m = 1 000 000 p = 3 266 666
Middle reward m = 100 000 p = 32 666 666
Small reward m = 20 000 p = 163 333 333
Nothing m = 0 p = 800 733 335
```
`Σ p · m = 9 799 999 260 000`, within `9 800 × 1e9`: the table keeps its 2 % margin, and about 1 ticket in 5 pays something. Every tier shares the same budget, so adding one means trimming the others, and the vault capacity is set by the top reward alone: this ticket needs the same 198 020 USDC idle vault as **Rare and large**.
Tiers can also pay less than the ticket price. A floor that returns part of the price to most customers leaves less for the top reward, as in the three-tier table on [DeFi yield and rewards](https://docs.fade.finance/use-cases/rewards.md#cashback-and-points-with-upside). How to build any table in exact integers, with rounding in the vault's favour, is on [Payout tables](https://docs.fade.finance/build/payout-tables.md#examples).
## What the vault can cover
The vault reserves each ticket's liability, and one ticket's liability may not exceed `min(0.5 × vault margin × free balance, 1.5 % of assets)`. At a 2 % margin with no app share, the vault margin is 1 %, so the first term binds: 0.5 % of the free balance. On an idle vault, the largest reward a 10 USDC ticket can carry is:
| Vault assets, idle | Largest liability | Largest reward, 10 USDC ticket |
| - | - | - |
| 10 000 USDC | 50 USDC | about 59.90 USDC |
| 100 000 USDC | 500 USDC | about 509.90 USDC |
| 1 000 000 USDC | 5 000 USDC | about 5 009.90 USDC |
As tickets open, the free balance shrinks and so does the cap. After the vault's [drawdown breaker](https://docs.fade.finance/liquidity/risks.md#what-limits-a-loss) trips (a 15 % fall of the share price within 24 hours), it is halved for 48 hours. Each app's open liability is also limited to 20 % of assets.
When a design does not fit, three levers bring it back in:
* **A smaller top reward:** a smaller multiplier, or a lower ticket price for the same multiplier.
* **A margin above the minimum,** with no app share.
* **A larger vault.**
The Ticket page reads the vault before the ticket opens and stops a reward at the largest one the vault backs right now. An app does the same: [Show the limit, do not hit it](https://docs.fade.finance/build/payout-tables.md#show-the-limit-do-not-hit-it).
## Where each use case starts
| Use case | Ticket price | Shape |
| - | - | - |
| [Card payments](https://docs.fade.finance/use-cases/card-payments.md#design-the-offer) | 0.80 USDC on a 40 USDC dinner | About 1 in 51 for the whole purchase, or 1 in 5 for 10 % back |
| [Swaps](https://docs.fade.finance/use-cases/swap-win-back.md#the-offer-is-yours-to-shape) | 9.18 USDC on a 450 USDC swap | 1 in 10 for 20 % off, 1 in 2 for 4 % off, or 1 in 50 for the whole swap |
| [Merchants and checkouts](https://docs.fade.finance/use-cases/checkout-win-back.md#design-the-offer) | 1.90 USDC on a 185.90 USDC order | About 1 in 100 for the whole order |
| [DeFi yield and rewards](https://docs.fade.finance/use-cases/rewards.md#cashback-and-points-with-upside) | 2.00 USDC from the program's budget, in place of a 2.00 USDC cashback | 1 in 10 for 19.60 USDC |
## Who can verify the draw
A Fade draw uses verifiable randomness (VRF), mapped by the program onto a payout table stored before the randomness exists. [Randomness](https://docs.fade.finance/protocol/randomness.md#verify-a-draw-yourself) shows how to recompute one from public data.
> [!NOTE]
>
> The business offering the reward runs it as organiser and is responsible for the rules of each market it serves. Fade is the technology provider. See [Legal framework](https://docs.fade.finance/legal-framework.md) for the design rules and a summary by region.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.