> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/math-engine/settlement.md).

# Settlement

Every trade on the Exchange ends in settlement: the moment abstract execution becomes actual transfers of USDX between accounts. The mechanism exists to make the Exchange's fee economics explicit and auditable — the taker, who consumes liquidity, pays a small fee on the trade's notional value; the maker, who provided the resting quote, receives a rebate funded out of that fee; and the difference is the Exchange's revenue on the fill. When the fill is a forced liquidation, an additional penalty on the same notional flows to the insurance fund, compensating the system for absorbing distressed risk.

Funding settlement is the second half of the story. Perpetual markets periodically charge one side of the market and pay the other to keep the contract price tethered to the index; settlement realizes those charges as transfers through a dedicated funding pool account. Throughout, the design commitment is conservation: every fee, rebate, penalty, and funding payment is a transfer between two named accounts, so money is moved, never created or destroyed.

![Each fill fans its notional out into fee, rebate, and penalty flows that recombine into ledger totals whose batch merge closes with V = F − R exactly.](/files/l6dGf425NiAtOD70buh1)

*Each fill fans its notional out into fee, rebate, and penalty flows that recombine into ledger totals whose batch merge closes with V = F − R exactly.*

## Setting

A market is parameterized by three fee rates quoted in basis points: the taker fee $$b\_t$$, the maker rebate $$b\_m$$ (stored as a negative number by convention; only its magnitude is charged), and the liquidation penalty $$b\_{liq}$$. The state being settled is a batch of fills, each with size $$q > 0$$ and price $$P > 0$$, plus a batch of signed funding payment amounts $$x$$. Three reserved accounts — the Exchange fee account, the insurance fund, and the funding pool — act as counterparties with untracked balances. All monetary results live in USDX and are truncated toward zero at 28 decimal places.

| Symbol       | Name                      | Description                                                                                                                                                           | Units              | Domain    |
| ------------ | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | --------- |
| $$q$$        | size                      | Fill quantity in units of the underlying asset; always positive for an executed fill.                                                                                 | units of asset     | (0, ∞)    |
| $$P$$        | price                     | Execution price of the fill.                                                                                                                                          | USDX per base unit | (0, ∞)    |
| $$b\_t$$     | taker\_fee\_bps           | Market taker fee rate in basis points; divided by 10,000 to obtain the fee fraction.                                                                                  | basis points       | \[0, ∞)   |
| $$b\_m$$     | maker\_rebate\_bps        | Market maker rebate rate in basis points, stored as a negative number by convention; the settlement engine charges only its absolute value.                           | basis points       | unbounded |
| $$b\_{liq}$$ | liquidation\_penalty\_bps | Penalty rate in basis points applied to the notional of liquidation fills and routed to the insurance fund.                                                           | basis points       | \[0, ∞)   |
| $$F$$        | total\_fees               | Sum of taker fees collected across all fills in a settlement record.                                                                                                  | USDX               | \[0, ∞)   |
| $$R$$        | total\_rebates            | Sum of maker rebates paid across all fills in a settlement record.                                                                                                    | USDX               | \[0, ∞)   |
| $$x$$        | funding\_amount           | Signed funding payment amount for one account: positive means the account pays the funding pool, negative means the pool pays the account, zero produces no transfer. | USDX               | unbounded |
| $$V\_1$$     | volume\_1                 | An accumulator field of one constituent settlement record being merged (shown for volume; the same summation applies to fees, rebates, and net revenue).              | USDX               | \[0, ∞)   |
| $$V\_2$$     | volume\_2                 | An accumulator field of one constituent settlement record being merged (shown for volume; the same summation applies to fees, rebates, and net revenue).              | USDX               | \[0, ∞)   |

## The mechanism

### Fee Settlement

Every fee in this primitive is proportional to the same base quantity: the notional value of the fill, the size traded times the price it traded at. Computing it once per fill fixes the base on which the taker fee, maker rebate, and liquidation penalty are all assessed.

$$
n = q \cdot P \tag{S.1}
$$

The taker — the aggressing side that consumed resting liquidity — pays the Exchange a fee proportional to the fill's notional (S.1). The rate is the market's taker fee expressed in basis points, so a market with $$b\_t = 5$$ charges five hundredths of a percent of notional. The resulting amount moves from the taker's account to the Exchange fee account. The product is truncated toward zero at 28 decimal places, so the fee never rounds up against the taker.

$$
\text{fee}\_t = n \cdot \frac{b\_t}{10,000} = q \cdot P \cdot \frac{b\_t}{10,000} \tag{S.2}
$$

The maker, whose resting order provided the liquidity, is paid a rebate out of the Exchange fee account, again proportional to the notional (S.1). Market parameters store the maker rate as a negative number of basis points to signal that money flows toward the maker; the engine applies its absolute value, so the transferred amount is always non-negative. Like the taker fee (S.2), the amount is truncated toward zero at 28 decimal places.

$$
\text{rebate}\_m = n \cdot \frac{|b\_m|}{10,000} = q \cdot P \cdot \frac{|b\_m|}{10,000} \tag{S.3}
$$

When a fill is flagged as a liquidation — the taker side is a forced close of a distressed position — an additional penalty is assessed on the same notional (S.1) at the market's liquidation penalty rate. This transfer runs from the taker's account to the insurance fund, not to the Exchange fee account: the penalty capitalizes the backstop that absorbs losses when liquidations complete underwater. Non-liquidation fills incur no penalty, and the amount is truncated toward zero at 28 decimal places.

$$
\text{penalty} = n \cdot \frac{b\_{liq}}{10,000} = q \cdot P \cdot \frac{b\_{liq}}{10,000} \tag{S.4}
$$

### Batch Accounting

Across a batch of fills, the Exchange's revenue is exactly what came in as taker fees (S.2) minus what went out as maker rebates (S.3): $$F$$ is the sum of per-fill taker fees and $$R$$ the sum of per-fill rebates. Liquidation penalties (S.4) are deliberately excluded — they belong to the insurance fund, not the Exchange. Because $$F$$ and $$R$$ are sums of the already-truncated per-fill amounts, the identity holds exactly with no further rounding.

$$
V = F - R \tag{S.5}
$$

### Funding Settlement

Funding settlement converts each account's signed funding payment into a transfer against the funding pool. The transferred amount is always the magnitude $$|x|$$; the sign selects the direction. A positive $$x$$ means the account pays: the transfer runs account → funding pool. A negative $$x$$ means the account receives: the transfer runs funding pool → account, carrying $$|x|$$. A zero payment produces no transfer at all, and funding settlement contributes nothing to fee totals or revenue.

$$
\text{transfer} = |x|, \qquad \text{direction} = \begin{cases} \text{account} \to \text{pool} & x > 0 \ \text{pool} \to \text{account} & x < 0 \ \text{none} & x = 0 \end{cases} \tag{S.6}
$$

### Batch Accounting

Settlement records compose additively. Merging a set of records concatenates their transfer lists and sums their fee totals and revenue, while the merged period spans from the earliest period start to the latest period end. Because every total is a plain sum, the merged record's revenue is the sum of the constituent revenues — merging never changes any amount, only groups them.

$$
X\_{\text{merged}} = \sum\_j X\_j \quad \text{for } X \in {V, F, R, \text{net}} \tag{S.7}
$$

## Invariants

* Fee accounting closes exactly: for any settlement record, $$V = F - R$$, where $$F$$ is the sum of all taker-fee transfer amounts and $$R$$ the sum of all maker-rebate transfer amounts ((S.5)). *Why it holds:* Each fill appends exactly one taker-fee and one maker-rebate transfer and adds the same two truncated amounts to the running totals $$F$$ and $$R$$; revenue is computed once at the end as $$F - R$$. No other path mutates these totals, and merging sums them component-wise, so closure is preserved under batching.
* Taker fees, maker rebates, and liquidation penalties are all non-negative: $$\text{fee}\_t \ge 0$$, $$\text{rebate}\_m \ge 0$$, $$\text{penalty} \ge 0$$. *Why it holds:* Each amount is a product of a positive notional $$q \cdot P$$ and a non-negative rate — the maker rate enters through its absolute value $$|b\_m|$$ — and truncation toward zero cannot cross zero. Hence no transfer amount is ever negative.
* Liquidation penalties route only to the insurance fund, never to the Exchange fee account, so $$V$$ contains no penalty revenue ((S.4)). *Why it holds:* The penalty transfer is constructed with the insurance fund as its fixed destination, and the penalty amount is never added to $$F$$ or $$R$$. The revenue identity therefore sees only fees and rebates.
* Funding settlement is conservative through the pool: every nonzero payment produces exactly one transfer of magnitude $$|x|$$, directed by the sign of $$x$$, and funding records carry zero fees, rebates, and revenue ((S.6)). *Why it holds:* The settle-funding path branches only on the sign of the payment, emitting one transfer with amount $$x$$ or $$|x|$$ and skipping zero amounts; its record hard-codes all fee totals to zero. So funding moves money between accounts and the pool without creating revenue.

## Worked example

Consider a single fill of $$q = 1$$ BTC at $$P = 50{,}000$$ USDX in a market with $$b\_t = 5$$, $$b\_m = -2$$, and $$b\_{liq} = 5$$ basis points. The notional (S.1) is $$n = 1 \times 50{,}000 = 50{,}000$$ USDX. The taker fee (S.2) is $$50{,}000 \times 5/10{,}000 = 25$$ USDX, paid from the taker to the Exchange fee account. The maker rebate (S.3) uses the magnitude of the stored rate: $$50{,}000 \times 2/10{,}000 = 10$$ USDX, paid from the Exchange fee account to the maker.

If this were an ordinary fill, settlement would stop there and record net revenue (S.5) of $$V = 25 - 10 = 15$$ USDX. If instead the fill is a liquidation, one more transfer is added: a penalty (S.4) of $$50{,}000 \times 5/10{,}000 = 25$$ USDX from the taker to the insurance fund. Note that $$V$$ is still $$15$$ USDX — the penalty capitalizes the insurance fund and never counts as Exchange revenue.

Funding settles separately. Suppose the same account owes a funding payment of $$x = 100$$ USDX: since $$x > 0$$, settlement emits a transfer of $$100$$ USDX from the account to the funding pool (S.6). Had the payment been $$x = -75$$ USDX, the pool would instead pay the account $$75$$ USDX. Neither transfer touches $$F$$, $$R$$, or $$V$$.

## Analysis

### Sensitivity

Elasticities ε = (∂y/∂x)·(x/y), computed numerically from the verified expressions at each worked-example point. |ε| > 1 means the output moves more than proportionally with that input.

| Expression             | Input                     | Elasticity ε |
| ---------------------- | ------------------------- | ------------ |
| `fill_notional`        | size                      | 1            |
| `fill_notional`        | price                     | 1            |
| `taker_fee`            | size                      | 1            |
| `taker_fee`            | price                     | 1            |
| `taker_fee`            | taker\_fee\_bps           | 1            |
| `maker_rebate`         | size                      | 1            |
| `maker_rebate`         | price                     | 1            |
| `maker_rebate`         | maker\_rebate\_bps        | 1            |
| `liquidation_penalty`  | size                      | 1            |
| `liquidation_penalty`  | price                     | 1            |
| `liquidation_penalty`  | liquidation\_penalty\_bps | 1            |
| `net_exchange_revenue` | total\_fees               | 1.667        |
| `net_exchange_revenue` | total\_rebates            | -0.6667      |
| `funding_transfer`     | funding\_amount           | 1            |
| `merge_totals`         | volume\_1                 | 0.625        |
| `merge_totals`         | volume\_2                 | 0.375        |

![Sensitivity tornado — Taker fee](/files/uKkLBRpqMbhpbdV32wLV)

![Sensitivity tornado — Net exchange revenue](/files/Ykd9SkqGdTsksiuJnV4M)

### Response curves

![The taker fee grows linearly in price at each fill size, holding the taker rate fixed at 5 basis points.](/files/FbioQFdSF9zdQSZmvVwx)

*The taker fee grows linearly in price at each fill size, holding the taker rate fixed at 5 basis points.*

![Net revenue is fees minus rebates: each rebate level shifts the same unit-slope line downward, holding rebates constant along each series.](/files/mmQNkVBlFimrjzjAWhA6)

*Net revenue is fees minus rebates: each rebate level shifts the same unit-slope line downward, holding rebates constant along each series.*

![The transferred amount is the magnitude of the signed funding payment; the sign only selects the direction of the transfer, with zero producing no transfer.](/files/0S2jstRJhpo4c1qcLM10)

*The transferred amount is the magnitude of the signed funding payment; the sign only selects the direction of the transfer, with zero producing no transfer.*

## References

* Derived from and adversarially verified against the Exchange's Rust implementation and its test suite.
* Sibling model: [funding-rate](/math-engine/funding-rate.md)
* Sibling model: [insurance-fund](/math-engine/insurance-fund.md)
* Sibling model: [liquidation-engine](/math-engine/liquidation-engine.md)
* Sibling model: [margin-math](/math-engine/margin-math.md)
* Sibling model: [oracle](/math-engine/oracle.md)
* Sibling model: [order-book](/math-engine/order-book.md)
* Sibling model: [position-tracker](/math-engine/position-tracker.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nexus.xyz/math-engine/settlement.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.