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

# Fees & rates

> Trading fees, funding rates, borrow rates, and charge caps.

Fee tiers and rate curves are estimated day-zero values, subject to change before launch. Published source, including example rate curves: [Trading Fees & Rates](https://tplus.cx/trading-fees.html).

## Trading fees

Spot trading is free. Margin trades pay volume-tiered fees in USD, measured on 14-day rolling USD volume:

| Tier | Volume   | Taker  | Maker          |
| ---- | -------- | ------ | -------------- |
| 0    | —        | 0.025% | 0.015%         |
| 1    | > \$50m  | 0.02%  | 0.005%         |
| 2    | > \$100m | 0.015% | 0.00% + rebate |
| 3    | > \$250m | 0.01%  | 0.00% + rebate |

Tier 2 and 3 makers receive a rebate of 25% and 50% respectively of the taker fee paid on their filled volume.

Trading fee rates are 1,000,000-scaled integers (`150` means `0.015%`). Taker and maker fees round up; maker rebates round down from the taker fee.

```text theme={null}
taker_fee = ceil(notional * taker_rate / 1,000,000)
maker_fee = ceil(notional * maker_rate / 1,000,000)
maker_rebate = floor(taker_fee * rebate_share / 1,000,000)
maker_net_fee = maker_fee - maker_rebate
```

Example: a `10,000 USD` margin fill at Tier 3 has `taker_rate = 100` and `maker_rate = 0`. The taker pays `ceil(10,000 USD * 100 / 1,000,000) = 1.00 USD`. With a `50%` rebate share, the maker receives `floor(1.00 USD * 500,000 / 1,000,000) = 0.50 USD`, so `maker_net_fee = -0.50 USD`.

Every order carries a max fee rate field (ppm); the order will not match at a higher fee. See [Orders](/trading/orders#order-fields).

## Funding rates

The overweight leverage side of a market pays the underweight side, bounding [skew](/matched-book-margin#skew). Rates are computed and applied once per hour from time-weighted averages over the preceding hour. Positive rate: longs pay shorts. Negative: shorts pay longs.

```
skew           = time-weighted (net long − net short) OI ÷ max OI
excess         = max(0, |skew| − skew_cliff)          # deadzone absorbs small skew
skew_component = sign(skew) × skew_factor × excess² ÷ 1,000,000
premium_component = avg_premium + clamp(base_funding_rate - avg_premium, ±premium_clamp)
funding_rate   = clamp(skew_component + premium_component, ±max_funding_rate)
```

* **Skew component**: skew (time-weighted net long/short open interest ÷ max OI) inside the per-asset deadzone (`skew_cliff`) contributes nothing; beyond it, the rate grows with the square of the excess, scaled by a per-asset factor.
* **Premium component**: tracks the deviation between the book's impact prices (the volume-weighted price to fill a reference notional on each side) and the oracle price, pulled toward a per-asset base rate, with a per-asset clamp on the adjustment. This is mainly a stress/deposit-scarcity term; skew is the normal funding driver.

Funding rates use the same 1,000,000 scaling. Example:

```text theme={null}
average_skew = 600
skew_cliff = 500
skew_factor = 9,000
excess = 600 - 500 = 100
skew_component = floor(9,000 * 100^2 / 1,000,000) = 90

average_premium_index = 1,200
base_funding_rate = 500
premium_clamp = 500
premium_component = 1,200 + clamp(500 - 1,200, ±500) = 700

funding_rate = 90 + 700 = 790 = 0.079%
```

A `50,000 USD` long pays `50,000 USD * 790 / 1,000,000 = 39.50 USD` for that funding interval.

<img src="https://mintcdn.com/tplus/4-smlrZA3aZwuaoy/images/funding-rate.svg?fit=max&auto=format&n=4-smlrZA3aZwuaoy&q=85&s=00a38668a93d64b0a95676cf2d24022b" alt="Funding rate vs skew: zero inside the deadzone, growing with the square of the skew beyond the cliff, clamped at the maximum funding rate" width="520" height="320" data-path="images/funding-rate.svg" />

*Funding rate vs skew (illustrative). Zero inside the ±`skew_cliff` deadzone; beyond it, it grows with the square of the excess and is clamped at ±`max_funding_rate`.*

### Imbalanced books

A market is almost always skewed, so funding is settled through the protocol rather than transferred one-to-one between traders:

* The paying side is charged in full: `position notional × |rate|`.
* The receiving side is paid its pro-rata share of what was collected, capped per account at `|rate| × position notional`.
* Because the paying side is usually the larger side, more is collected than is owed to receivers. The surplus goes to the protocol fee account.

This is how a one-sided book still funds: the overweight side always pays the rate, the underweight side is paid up to the same rate on its smaller notional, and the protocol absorbs the difference. A single rate is charged to both sides; per-side rates to rebalance the surplus are a planned refinement.

### Funding fee tiers

Accounts carrying large open interest pay discounted funding. The tier is set by the account's open interest (OI) averaged over a 14-day rolling window, in notional USD, and reduces funding charges only — not borrow rates or trading fees.

| 14-day average OI | Funding discount |
| ----------------- | ---------------- |
| —                 | 0%               |
| > \$50m           | 5%               |
| > \$100m          | 10%              |

The highest tier whose threshold the account meets applies. Discounts are 1,000,000-scaled registry values (`50000` means 5%).

The discount does not come out of the receiving side. The headline rate grosses up the raw skew-and-premium rate by the paying side's average discount, so the same total is collected and receivers are paid in full — full-rate accounts carry the cost, not receivers or the protocol.

```text theme={null}
avg_discount   = Σ(discount × OI) ÷ Σ OI         # paying side, OI-weighted
headline_rate  = raw_rate ÷ (1 − avg_discount)
account_charge = headline_rate × (1 − discount) × OI

Σ account_charge = raw_rate × Σ OI               # the gross-up offsets the discounts
```

The gross-up uses the OI-weighted average discount, so total funding collected stays at `raw_rate × Σ OI` no matter how the discounts are distributed — what the receiving side is owed never changes.

Example: the raw skew-and-premium rate is `0.095%`, and the paying side holds `100m USD` of open interest — `50m` at full rate and `50m` in the 10% tier, a `5%` OI-weighted average discount. The headline rate is `0.095% ÷ (1 − 0.05) = 0.10%`.

* A full-rate `50,000 USD` long pays `50,000 × 0.10% = 50.00 USD`.
* A `50,000 USD` long in the 10% tier pays `50,000 × 0.10% × 0.90 = 45.00 USD`.

Funding collected across the paying side is `50m × 0.10% + 50m × 0.09% = 95,000 USD` — exactly `0.095% × 100m`, what receivers are owed at the raw rate. The gross-up and the discounts cancel.

## Borrow rates

Borrowers pay depositors a utilization rate, quoted as an annual percentage. Two rates per asset:

* **Base borrow rate**: borrowing the asset itself (a short borrows ETH). Utilization is measured against that asset's deposits.
* **Quote borrow rate**: borrowing USD against that market (a leveraged long). Utilization is measured against the protocol-wide USD deposit pool.

Utilization = borrowed ÷ (lendable + borrowed), with lendable capped at the asset's [spot OI cap](/trading/margin#protocol-caps). Rates follow a piecewise-linear kink curve over per-asset utilization breakpoints (registry parameters): flat at low utilization, steep near 100%. An account borrows on at most one side per asset at a time (base borrows take priority over quote).

```
lendable = min(time_weighted_deposits, spot_OI_cap)    # if the cap is enabled
utilization = floor(borrowed * 1,000,000 / (lendable + borrowed))
borrow_rate = rate_below
            + floor((utilization - kink_below)
                    * (rate_above - rate_below)
                    / (kink_above - kink_below))
```

Example: if time-weighted borrows are `5m USD`, deposits are `15m USD`, and the spot OI cap is `5m USD`, then `lendable = 5m USD` and `utilization = 5m USD / (5m USD + 5m USD) = 50%`. With kink points `(40%, 2%)` and `(70%, 5%)`, the interpolated borrow rate is:

```text theme={null}
borrow_rate = 2% + ((50% - 40%) * (5% - 2%) / (70% - 40%)) = 3%
```

<img src="https://mintcdn.com/tplus/4-smlrZA3aZwuaoy/images/borrow-rate.svg?fit=max&auto=format&n=4-smlrZA3aZwuaoy&q=85&s=2d852dc46f958946dfae97904673b703" alt="Borrow rate vs utilization: a piecewise-linear kink curve, flat at low utilization and steep near 100%" width="520" height="320" data-path="images/borrow-rate.svg" />

*Borrow rate vs utilization (illustrative). Flat at low utilization, steepening through each kink toward 100%; the kink points are per-asset registry parameters.*

Charges accrue hourly in USD — each hour applies roughly the annual rate divided by the hours in a year (\~8,760). Funding is instead quoted per hour, so on a leveraged position the hourly borrow charge is a small fraction of the funding payment. Collected fees are distributed to lenders pro-rata to their time-weighted average spot deposits of the lent asset, credited as USD, capped per user at `deposit notional × max rate`; excess goes to the protocol fee account.

```text theme={null}
lender_credit = collected_fees * lender_TWA_deposit / total_TWA_deposits
lender_credit_capped = min(lender_credit, deposit_notional * max_rate)
```

Example: if `3,000 USD` of borrow fees are collected and a lender supplied `200,000 USD` of the `1,000,000 USD` time-weighted deposits, that lender receives `3,000 USD * 200,000 USD / 1,000,000 USD = 600 USD`, subject to the per-user cap.

## Rate data

* `GET /funding-rate/{asset_id}`: current indicative rate.
* `GET /funding-rate/history`: hourly applied rates (the authoritative record), newest first in the standard pagination envelope: `items`, `page`, `limit`, `total_pages`, `cursor_size`, `has_next_page`, and `next_page`.
* Indicative funding and borrow rates also stream over the public interest-engine `/rates` WebSocket; see [WebSocket streams](/api-reference/websockets).
* Per-asset rate parameters (`max_funding_rate`, `skew_cliff`, base rates, kink breakpoints): `GET /registry/risk-parameters`.

## Charge cap

Each hourly funding or interest charge is capped so the account's equity cannot fall below the midpoint between its liquidation threshold and its bad-debt threshold. A charge can make an account liquidatable but never insolvent; an account already at bad-debt level is charged nothing. Conversion rounding favors the user.

```text theme={null}
charge_floor = (liquidation_threshold + bad_debt_threshold) / 2
max_charge = max(0, equity - charge_floor)
applied_charge = min(raw_charge, max_charge)
```

Example: if account equity is `1,000 USD`, the liquidation threshold is `700 USD`, and the bad-debt threshold is `400 USD`, then `charge_floor = (700 USD + 400 USD) / 2 = 550 USD`. The account can be charged at most `1,000 USD - 550 USD = 450 USD` that hour.

## Other fees

* [Rebalancing](/funds/rebalancing): deposits, withdrawals, and settlements incur a fee or earn a reward of up to 2.5% to keep per-chain vault liquidity balanced.
