> For the complete documentation index, see [llms.txt](https://docs.term.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.term.finance/terminal-1-execution/concepts/fees-slippage-and-buffers.md).

# Fees, slippage & buffers

Execution outcomes depend on both protocol economics and market conditions. Terminal 1 routes therefore distinguish between (i) fees that are deterministic once the route is defined, (ii) price movement and liquidity conditions that introduce slippage, and (iii) conservative buffers that make routes fail safely when conditions change.

### Fees (what gets paid)

A route can include multiple fee sources, depending on the workflow and venues used:

* **Term protocol fees** (see [Fees and Penalties](/protocol/fees-and-penalties.md)).
* **Venue fees** (e.g., borrow/repay costs on external lending venues).
* **Swap / aggregator costs** (DEX fees and any aggregator-specific costs).
* **Flash loan premium** (only for routes that use flash liquidity).
* **Network gas** (paid separately to execute the transaction(s)).

Terminal 1 surfaces fees where it can, but the canonical source of truth is always the onchain execution and the underlying venue’s rules.

### Slippage (what can change)

Slippage is the difference between an expected quote and the realized execution due to:

* price movement between quote and inclusion,
* limited liquidity / price impact,
* partial liquidity availability at execution time,
* path changes (if the route selects between eligible venues).

Slippage risk is highest in routes that rely on large swaps or swaps of illiquid tokens, and for Safe workflows where signing latency can be longer.

### Buffers (UI-layer safety margins)

Buffers are applied in the UI when constructing a route. They intentionally over‑provision certain amounts (or include small safety margins) to reduce avoidable reverts when fees or market conditions move slightly between preview and execution. Buffers do not change protocol rules or smart contract validation; they only affect the parameters the UI submits.

### Practical guidance

* Use conservative slippage in deep markets.
* Use wider buffers for long or liquidity-sensitive routes.
* Recheck the net outcome before signing.