> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omnibook.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Fees
> What the venue charges, when it charges it, and how the fee is reserved before the fill happens.
**Only fills are charged.** Placing, amending, decreasing, cancelling,
settlement, pair redemption, deposits and withdrawals all cost nothing. There is
no listing fee, no inactivity fee, and no data fee.
A fill charges each side separately, in its own role: the aggressor pays the
**taker** rate, the resting order pays the **maker** rate.
## The formula
The fee is quadratic in price, not linear in notional:
```
Q(p) = p × (10000 − p)
fee = ceil( rate × qty × Q(p) / 10^8 ) [integer pips]
```
`p` is the fill's price tick in pips, `qty` is the number of shares, and `rate`
is the party's pinned maker or taker rate. Everything is integer arithmetic;
there are no floats anywhere in the money path.
Two properties fall out of `Q` and both matter:
* **It peaks at 50¢ and vanishes at the edges.** You pay most where the outcome
is most uncertain and almost nothing on a contract trading at 99¢.
* **It is mirror-invariant** — `Q(p) = Q(10000 − p)`. A YES fill at 3500 and the
NO fill facing it at 6500 compute the same `Q`, so both sides of one trade are
charged off an identical basis and neither outcome is the cheaper side to
hold.
## Live rates
Every 60-second round market binds fee schedule **2**:
| Role | Rate | What it means |
| - | - | - |
| Maker | `0` | Resting fills are free |
| Taker | `250` | Charged on the aggressing side only |
Read the schedule bound to a market from `fee_schedule_id` on
`GET /v1/markets/{market_id}`. Schedule `1` exists as a zero-fee spare.
`rate` is expressed in hundredths of a percent of the quadratic, Kalshi-style:
`250` is 2.5%, so the fee on a fill is `0.025 × qty × P × (1 − P)` in dollars,
where `P` is the fill price as a fraction of \$1.
### What a taker pays
The same curve as numbers, for a 100-share fill at `taker_rate = 250`:
| Fill price | Notional | Fee (pips) | Fee | Share of notional |
| - | - | - | - | - |
| 1¢ (`100`) | \$1.00 | 248 | \$0.0248 | 2.4800% |
| 10¢ (`1000`) | \$10.00 | 2,250 | \$0.2250 | 2.2500% |
| 25¢ (`2500`) | \$25.00 | 4,688 | \$0.4688 | 1.8752% |
| 50¢ (`5000`) | \$50.00 | 6,250 | \$0.6250 | 1.2500% |
| 75¢ (`7500`) | \$75.00 | 4,688 | \$0.4688 | 0.6251% |
| 90¢ (`9000`) | \$90.00 | 2,250 | \$0.2250 | 0.2500% |
| 99¢ (`9900`) | \$99.00 | 248 | \$0.0248 | 0.0251% |
Fees are denominated in **pips**, the same unit as every other money field
(1 pip = 0.01¢; \$1 = 10,000 pips).
Read the shape rather than the row: **fee per share is flat in cents but steeply
regressive as a share of what you paid.** Buying at 99¢ costs 0.025% of notional;
buying the same contract at 1¢ costs 2.48%. The cheap side of a lopsided market
is the expensive side to take.
Don't hard-code this table. Rates are venue configuration and can change by
sequenced admin command; the fee your order will pay is fixed at admission
(below), and the fee it actually paid is on the fill.
## Rounding is per fill, and upward
Each fill rounds up independently — `ceil`, house-favourable. One order filled
in five pieces rounds five times, so it can pay marginally more than the same
quantity filled at once. At the extreme, a single share always costs at least
1 pip.
This is why a resting order that gets picked apart by small aggressors is not
fee-equivalent to one that trades in a block, and it is worth knowing before you
compare a fill report against your own model.
## Your rate is pinned when the order is admitted
`maker_rate`, `taker_rate` and the per-share fee ceiling are read from the
market's schedule **once, when the order is accepted**, stored on the order, and
used for every later fill of that order.
A fee schedule change therefore affects only orders admitted after it. An order
resting across a change keeps the economics it was admitted under — which is
also what keeps its collateral sufficient, since a reservation taken at the old
rate can never be short at the new one.
## A buy reserves its fee up front
Buys reserve cash at admission for the whole order, fee included:
```
fee_ps = ceil( max(maker_rate, taker_rate) × Q(min(tick, 5000)) / 10^8 )
reserved = qty × (tick + fee_ps)
```
On the live schedule that is 63 pips per share for any buy at 50¢ or above, and
less below it — a buy of 100 at 50¢ reserves `100 × 5063 = 506,300` pips
($50.63), of which $50.00 is the order and \$0.63 the fee ceiling.
`fee_ps` is a **per-share ceiling**, not the fee you will pay. `min(tick, 5000)`
is there because a buy can only ever execute at or below its limit, and `Q`
peaks at 50¢ — so clamping toward the peak bounds every price the order could
reach. Because `ceil(a·q) ≤ q·ceil(a)`, no sequence of partial fills and no
pattern of rounding can push the total fee past what was reserved.
Consequences worth planning for:
* Your buying power is `qty × (tick + fee_ps)`, slightly more than
`qty × tick`. An order sized to the last pip of your balance can be rejected
for insufficient funds.
* The reservation is released as fills resolve, and what you actually paid is
almost always less than `qty × fee_ps`.
You can read the pinned ceiling back: the `accepted` event on the WebSocket
`user` channel carries `fee_ps`.
## A sell pays out of proceeds
Sells reserve no cash — the fee comes out of what the sale earns. Net proceeds
can reach zero at extreme ticks but are never negative, so a sell can never
leave you owing money.
## Market buys clip against the fee
A budget-denominated (market) buy spends a fixed amount of cash. The venue walks
the book and stops at the last share whose **fee-inclusive** cost still fits
inside the budget, so a market buy never overspends and never fails for
insufficient funds partway through. You get slightly fewer shares than a
fee-blind calculation predicts.
## Reading what you paid
| Where | Field | Notes |
| - | - | - |
| `GET /v1/portfolio/fills` | `fee` | Pips, decimal string. Your own side only |
| WebSocket `user` → `fill_ledger` | `fee` | Maker leg then taker leg; each party sees only its own fee |
| WebSocket `user` → `accepted` | `fee_ps` | The per-share ceiling pinned to that order |
| `GET /v1/markets/{market_id}` | `fee_schedule_id` | Which schedule the market is bound to |
The order placement response does **not** carry a fee. Its `fills[]` entries are
`tick_yes`, `qty` and `path` only. If you need the fee for a fill you just
caused, read it from `GET /v1/portfolio/fills` or the `fill_ledger` event — do
not compute it and treat your own number as authoritative.
## What is never charged
* **Settlement.** A winning share pays exactly \$1 (10,000 pips), gross.
* **Pair redemption.** Holding matched YES and NO redeems to \$1 automatically,
free.
* **Cancels, decreases and expiries.** Including mass cancel and dead-man
teardown.
* **Deposits and withdrawals.** No venue fee on either.
* **Rejected and unmatched orders.** Nothing that does not fill costs anything.
The exchange's fee account only ever grows on a fill.
## Maker rebates and referrals
These are credited by the accounts service, not by the trading API, and they
settle **once daily** for the prior UTC day:
* **Maker rebate — 50%.** Each maker receives half of the taker fees collected
against their resting orders. Under the live schedule the maker rate is
already `0`, so a maker pays nothing and is paid half of what the aggressor
paid.
* **Referral share — 50% of net.** A referrer earns half of the exchange's take
*after* maker rebates, on fees paid by direct referees. On a $1 taker fee: the
maker gets $0.50, the exchange nets $0.50, the referrer gets $0.25. Direct
referrals only, no multi-level.
Both are rounded half-up on the daily total rather than per fill, so a day of
small fills still rebates.
Rebates and referral credits arrive as **bonus balance**. Bonus is spendable —
you can trade it — but it is not withdrawable, and it never unlocks. It raises
`bonus_locked`, and `withdrawable = available − bonus_locked`. Profits you make
trading on top of it are withdrawable normally.
Check `bonus_locked` and `withdrawable` on `GET /v1/portfolio/balance` rather
than assuming `available` is what you can take out.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.