> For the complete documentation index, see [llms.txt](https://wiki.orbofi.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.orbofi.com/learn/tokenization-liquidity-and-onchain-systems/fees.md).

# Fees

### The one number

The fee is **1.5% of every swap**, buy or sell, plus **0.1%** that is automatically returned to the pool as locked liquidity — so the total charged in-swap is **1.6%**, and that total is what a quote from the V4 Quoter already reflects. Never subtract anything again when displaying an expected output.

There is no separate token tax, and nothing else is deducted anywhere.

{% hint style="warning" %}
These are the **standing** rates. For the first ten seconds of a pool's life an anti-snipe schedule opens at 80% and decays down, and the rate is per-pool configuration rather than a protocol constant. Always quote. See [Liquidity layer](/learn/tokenization-liquidity-and-onchain-systems/liquidity-layer.md).
{% endhint %}

### Nothing to integrate

Because the fee is taken at the pool level, there is **no fee step in your integration** — nothing to collect, route, register or account for, and no way to accidentally skip it. A swap sent through the Universal Router, or through any other path into the pool, pays the same fee before the trader receives their output. Fee accrual and distribution are handled entirely by the protocol's own contracts.

Fees fund the agent's **creator**, the **agent's own treasury** (capital the agent itself uses), and the protocol. The creator-side split is configurable at launch. From an integrator's perspective this is background: it never changes what a trader pays or what your swap needs to encode.

### The one fee fact your indexer needs

The total is charged as two legs by two different mechanisms, and only one of them is visible to Uniswap's own accounting:

| Leg      | Size | Visible where                         |
| -------- | ---- | ------------------------------------- |
| LP leg   | 0.1% | The `Swap` event's `fee` field        |
| Hook leg | 1.5% | Hook deltas — **never** in `Swap.fee` |

So **`Swap.fee` reads `1000` (0.1%) on a normal trade** — displaying it as the trading cost understates by 16x. Use the quoter for cost; the split above is only there to explain why that field looks wrong.

### Reconstructing what a trade actually cost

There is no per-swap fee event, and per the table above neither `Swap.fee` nor `amount0`/`amount1` tells you the trader's real rate.

For a **live or pending** trade, the quoter is exact and cheap: `quoteExactInputSingle` is already net of both legs.

For a **historical** trade there are two options, both with costs worth knowing up front:

* **Token transfers.** Sum the `Transfer` logs to and from the taker in that transaction. This gives what they actually paid and received, and needs no archive node — but you must identify the taker first, which is the transaction's `from`, not `Swap.sender`.
* **Re-quote at the block.** Simulate `quoteExactInputSingle` at block N−1 and compare. Exact, but needs an archive node and one call per trade.

If you only need a fee *column* rather than per-trade precision, showing the pool's standing rate is reasonable — provided you do not present it as measured, and you handle the first ten seconds of a pool's life separately.

### What the chart shows: two small sells after every buy

On any trade feed you will see each buy followed by two small `Sell` rows from `0x4e3468…a544`. That is the fee engine executing in-swap, not holders exiting:

| Row         | Size               | What it is                                                                                                                                                                                     |
| ----------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| First sell  | \~1.4% of the buy  | The revenue fee, taken on the buy's token output and converted to the numeraire immediately — this is why creators and the protocol earn ETH (or the paired stock) instead of decaying tokens. |
| Second sell | \~0.05% of the buy | The auto-compound rebalance: half of the compound slice is converted so both sides can be re-added as full-range, protocol-owned liquidity.                                                    |

On sells the fee is taken from the numeraire output directly, so there is no conversion row — you may instead see a tiny hook *buy* when the compound slice rebalances the other way. The math reconciles to the pool's standing rate to the basis point; treat these rows as protocol activity when rendering feeds.

{% hint style="info" %}
**If you run a screener or terminal:** tag `0x4e3468…a544` (the Pool Initializer — full address in [Deployed Contract Addresses](/learn/tokenization-liquidity-and-onchain-systems/deployed-contract-addresses.md)) as a protocol/AMM address, so its conversion swaps render as protocol activity rather than user selling.
{% endhint %}


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://wiki.orbofi.com/learn/tokenization-liquidity-and-onchain-systems/fees.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.