> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Trading fees

> What a fill costs: maker and taker rates, how the rate that applies to you is resolved, the rounding rules, and where the fees go.

A trading fee is charged **per fill**, on the notional value of that fill. Not per order, not per block — an order that fills in five pieces is charged five times, on five notionals, and an order that never fills is never charged.

Two rates apply, depending on which side of the trade you were on.

**Maker** — your order was resting on the book and someone else traded into it. You supplied liquidity, and the rate is lower.

**Taker** — your order crossed the spread and consumed resting liquidity. The rate is higher.

The distinction is about what your order *did*, not what you intended. A limit order that crosses on placement pays the taker rate. If you must be a maker, use post-only, which is rejected rather than filled when it would take liquidity. See [Order types](/trading/order-types).

## The calculation

$$
\text{fee} = \text{fill notional} \times \frac{\text{rate in ppm}}{1{,}000{,}000}
$$

Rates are stored on-chain in **parts per million**, not percent. The network default is `450` ppm taker and `150` ppm maker — 0.045% and 0.015%.

Working in ppm is not cosmetic. Everything on the settlement path is [fixed-point integer arithmetic](/protocol/architecture/kernel), because a rounding difference between two validators is a fork rather than a discrepancy. A rate expressed as a percentage of a percentage would have to become a decimal somewhere, and there is no version of that which every machine agrees on.

The rounding is therefore specified rather than incidental:

|                                     | Rule                                                                                            |
| ----------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Fee charged**                     | Round to nearest, ties away from zero, with a floor of 1 quantum whenever the rate is positive  |
| **Rebate paid**                     | Round to nearest, ties away from zero, with **no** floor — a rebate is allowed to round to zero |
| **Fee reserved at order placement** | Round to nearest, ties away from zero, floor of 1 quantum                                       |

The 1-quantum floor on charges exists so a very small fill cannot be free. The absence of that floor on rebates is the mirror image: the protocol will round a payment down to nothing rather than mint a unit it did not earn.

## Which rate applies to you

Every fill resolves the rate the same way, and the order is fixed.

<div className="dg" data-dg="fee-rate-resolution">
  <div className="dg-c" style={{aspectRatio:"720 / 300"}}>
    <svg className="dg-w" viewBox="0 0 720 300" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 134.00 112.00 L 155.60 112.00" />

      <path className="dg-head dg--blue" d="M 162.00 112.00 L 155.60 116.40 L 155.60 107.60 Z" />

      <path className="dg-wire dg--green" d="M 340.00 112.00 L 373.26 41.78" />

      <path className="dg-head dg--green" d="M 376.00 36.00 L 377.24 43.67 L 369.28 39.90 Z" />

      <path className="dg-wire dg--sky" d="M 340.00 112.00 L 369.60 112.00" />

      <path className="dg-head dg--sky" d="M 376.00 112.00 L 369.60 116.40 L 369.60 107.60 Z" />

      <path className="dg-wire" d="M 340.00 112.00 L 373.26 182.22" />

      <path className="dg-head" d="M 376.00 188.00 L 369.28 184.10 L 377.24 180.33 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"28.0000%",width:"18.0556%",height:"18.6667%"}}><span className="dg-t">A fill</span></div>
    <div className="dg-b dg--yellow dg-round" style={{left:"23.0556%",top:"24.6667%",width:"23.6111%",height:"25.3333%"}}><span className="dg-t">Does the account carry a rate?</span></div>
    <div className="dg-b dg--green dg-left" style={{left:"52.7778%",top:"0.6667%",width:"47.2222%",height:"22.6667%"}}><span className="dg-t">A negotiated account rate</span><span className="dg-s">set directly against the account, and deliberately skipped by the nightly tier pass — a recalculation never overwrites agreed terms</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"52.7778%",top:"26.0000%",width:"47.2222%",height:"22.6667%"}}><span className="dg-t">A volume tier rate</span><span className="dg-s">derived from rolling volume, written back on-chain daily</span></div>
    <div className="dg-b dg-left" style={{left:"52.7778%",top:"51.3333%",width:"47.2222%",height:"22.6667%"}}><span className="dg-t">The network default</span><span className="dg-s">a new account trades at tier 0, not at no rate at all</span><span className="dg-n">A rate of zero is a real rate: once set, it is charged literally.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"78.6667%",width:"100.0000%",height:"17.3333%"}}><span className="dg-s">A per-market base rate also exists in the on-chain configuration surface, but it is not applied on the fill path today — every market resolves against the account-then-default chain above.</span></div>
  </div>
</div>

**A negotiated account rate** is set directly against an account. It survives the nightly tier pass: an account carrying a negotiated rate is deliberately skipped, so a volume recalculation never overwrites terms someone agreed to.

**A volume tier rate** is what almost every account has. It is derived from rolling volume and written back on-chain daily. See [Fee tiers](/programs/fee-tiers).

**The network default** applies to an account that has never been assigned anything — a new account trades at tier 0 rather than at no rate at all.

<Note>
  A rate of zero is a real rate, not a missing one. Once an account carries an explicitly set rate, the protocol charges it literally, including when it is zero. Nothing silently falls back to the default because the number happens to look empty.
</Note>

A **per-market base rate** also exists in the on-chain configuration surface, for the case where a market's risk profile differs enough from the venue's that pricing it on the venue-wide schedule is wrong — a pre-market contract, an unusually thin listing. When it is applied, it replaces the network default as the base for that market, with account rates still layering on top of it.

<Warning>
  Per-market base rates are configurable but are **not applied on the fill path today**. Every market currently resolves against the account-then-default chain above. This page will say otherwise when that changes.
</Warning>

## What the rate can be

Both rates are bounded on-chain, and the write is rejected rather than clamped if a configuration exceeds them.

|           | Bound                                                     |
| --------- | --------------------------------------------------------- |
| **Taker** | Never negative. Capped at 10%                             |
| **Maker** | May be negative — a rebate — down to −0.1%. Capped at 10% |

The asymmetry is deliberate. A negative maker rate is a designed incentive: the venue pays for liquidity it wants on the book. A negative taker rate would be a mechanism for minting money by trading against yourself, so it is not representable rather than merely discouraged.

The 10% ceiling is a guardrail, not a schedule. Real rates live two orders of magnitude below it; the bound exists to stop an absurd or malicious configuration from reaching execution, not to describe what anyone pays.

## Placing orders costs no gas

Submitting, amending, and cancelling orders are native protocol transactions. They do not require a gas balance and do not compete in a fee market.

This matters more than it sounds. On a venue where order management costs gas, quoting is expensive and cancelling during volatility is most expensive exactly when it is most necessary — so market makers quote wider to cover it, and everyone pays that spread. Making order management free removes that cost from the spread rather than moving it around.

The consequence is that **the trading fee is the whole protocol cost of trading.** There is no second line item.

## Why your reserved margin exceeds the initial requirement

When you open a position, the protocol reserves margin for the initial requirement *plus an anticipated closing fee* — because a position that cannot afford to close is a position the venue has to absorb.

That anticipated fee is computed at the **network's default taker rate**, locked at the moment the order was placed — not at your rate, and not at whatever the rate becomes later.

Both parts of that are conservative on purpose. Using the default taker rate means the reservation never under-provisions for an account whose rate later rises. Locking it at placement means a rate change mid-life cannot retroactively invalidate margin that was already checked and accepted.

You are charged your actual rate when the close fills. The reservation is a bound, not a bill.

## Where fees go

Trading fees are collected into a protocol-controlled account on-chain. What flows out is directed to the ecosystem rather than retained.

<div className="dg" data-dg="fee-destinations">
  <div className="dg-c" style={{aspectRatio:"720 / 314"}}>
    <svg className="dg-w" viewBox="0 0 720 314" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 134.00 138.00 L 165.60 138.83" />

      <path className="dg-head dg--blue" d="M 172.00 139.00 L 165.49 143.23 L 165.72 134.43 Z" />

      <path className="dg-wire dg-soft" d="M 371.00 139.00 L 408.72 39.98" />

      <path className="dg-head" d="M 411.00 34.00 L 412.83 41.55 L 404.61 38.41 Z" />

      <path className="dg-wire dg-soft" d="M 371.00 139.00 L 406.18 108.21" />

      <path className="dg-head" d="M 411.00 104.00 L 409.08 111.53 L 403.29 104.90 Z" />

      <path className="dg-wire dg-soft" d="M 371.00 139.00 L 406.18 169.79" />

      <path className="dg-head" d="M 411.00 174.00 L 403.29 173.10 L 409.08 166.47 Z" />

      <path className="dg-wire dg-soft" d="M 371.00 139.00 L 408.72 238.02" />

      <path className="dg-head" d="M 411.00 244.00 L 404.61 239.59 L 412.83 236.45 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"35.0318%",width:"18.0556%",height:"17.8344%"}}><span className="dg-t">Every fill</span></div>
    <div className="dg-b dg--blue" style={{left:"24.4444%",top:"32.1656%",width:"26.3889%",height:"24.2038%"}}><span className="dg-t">Protocol fee account</span><span className="dg-s">on-chain and auditable</span></div>
    <div className="dg-b dg--green" style={{left:"57.7778%",top:"0.6369%",width:"42.2222%",height:"20.3822%"}}><span className="dg-t">Liquidity vault</span><span className="dg-s">quotes the book and takes over positions in liquidation; profits accrue to depositors</span></div>
    <div className="dg-b dg--green" style={{left:"57.7778%",top:"22.9299%",width:"42.2222%",height:"20.3822%"}}><span className="dg-t">Insurance fund</span><span className="dg-s">absorbs shortfalls before deleveraging reaches other traders</span></div>
    <div className="dg-b dg-dashed" style={{left:"57.7778%",top:"45.2229%",width:"42.2222%",height:"20.3822%"}}><span className="dg-t">Referral rebates</span><span className="dg-s">when that program is live</span></div>
    <div className="dg-b dg-dashed" style={{left:"57.7778%",top:"67.5159%",width:"42.2222%",height:"20.3822%"}}><span className="dg-t">Token deployers</span><span className="dg-s">for spot listings brought by someone else — spot is not live yet</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"88.5350%",width:"100.0000%"}}><div className="dg-n">Balances and movements are chain state — opening balance, fees in, transfers out, closing balance is a sum anyone can recompute from committed blocks.</div></div>
  </div>
</div>

* **The [liquidity vault](/trading/vaults)** that quotes the book and takes over positions during [liquidations](/trading/liquidations). Fee revenue is part of its income, and vault profits accrue to depositors.
* **The insurance fund**, which absorbs shortfalls a liquidation could not cover before [deleveraging](/trading/adl) reaches other traders.
* **[Referral](/programs/referrals) rebates**, when that program is live.
* **Token deployers**, for listings brought by someone else. This applies to spot listings, which are not live yet.

Balances and movements are chain state. The reconciliation — opening balance, fees in, transfers out, closing balance — is a sum anyone can recompute from committed blocks rather than a figure anyone has to publish.

Bridge and account fees are collected separately, into their own account. See [Non-trading fees](/programs/other-fees).

## What is not a trading fee

| Cost                                         | Paid to            | Notes                                 |
| -------------------------------------------- | ------------------ | ------------------------------------- |
| Trading fee                                  | The protocol       | This page                             |
| [Funding](/trading/funding)                  | Other traders      | The protocol takes no share           |
| Slippage                                     | Nobody             | It is the price you got, not a charge |
| [Liquidation penalty](/trading/liquidations) | The insurance fund | Only on liquidation                   |
| [Withdrawal fee](/programs/other-fees)       | The protocol       | Bridge, not trading                   |
| Gas                                          | —                  | Not charged on trading transactions   |

Funding is the one most often mistaken for a fee. It is a transfer between longs and shorts; depending on which side you hold, it is a cost or an income.

## Reducing what you pay

* **Be a maker.** For most accounts the maker–taker gap is wider than the gap between adjacent volume tiers. Changing *how* you trade moves your cost more than trading more does.
* **Use post-only** when you must not pay taker rates by accident. It is rejected rather than filled if it would cross.
* **Keep activity under one parent account.** Sub-accounts aggregate for tier purposes, so splitting gains nothing and costs operational complexity.
* **Split large orders.** [TWAP](/trading/twap) and [scale orders](/trading/scale-orders) reduce slippage, which on a large order usually exceeds the fee by a wide margin.

<Warning>
  Read rates from the chain rather than hard-coding them. The schedule is on-chain configuration and moves; an integration carrying its own copy will eventually compute a cost the network is not charging. See [Developers](/developers/overview).
</Warning>

## Where to go next

<CardGroup cols={2}>
  <Card title="Fee tiers" href="/programs/fee-tiers">
    The schedule, how your tier is computed, and market maker rebates.
  </Card>

  <Card title="Non-trading fees" href="/programs/other-fees">
    Bridge, account, vault, and liquidation costs.
  </Card>

  <Card title="Order types" href="/trading/order-types">
    Post-only, and guaranteeing maker status.
  </Card>

  <Card title="Funding" href="/trading/funding">
    The cost that goes to other traders rather than the protocol.
  </Card>
</CardGroup>