> For the complete documentation index, see [llms.txt](https://docs.peach.ag/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peach.ag/documentation/bsc/aggregator/editor/slippage.md).

# Slippage

Set slippage tolerance, display minimum received and understand settlement.

Slippage tolerance limits how far execution may move against the prepared trade. Set it during preparation and display the signed minimum returned by the service.

### Slippage and minimum received

| Slippage (bps) | Tolerance |
| -------------- | --------- |
| `10`           | 0.1%      |
| `50`           | 0.5%      |
| `100`          | 1%        |

Pass the user's selected tolerance explicitly when preparing. The server returns the signed minimum in `tx.amountOutMin` / `execution.plan.minAmountOut`. Display this value in output-token units; do not deduct slippage from it again. If execution cannot satisfy the signed minimum, the swap reverts.

The setting is named `slippageBps` on `prepareSwap()`, `prepareDirectSwap()` and `prepareDelegatedSwap()`. The SDK accepts integers from 0 to 10000; omitting it leaves the service default in control. `getQuote()` has no slippage setting and returns no signed minimum.

Preparation can change the output even if tolerance stays the same. Show the **fresh expected recipient output and minimum received** before submission. In Delegated mode, the signed minimum is available only after signing and build; see [Delegated Swaps](https://docs.peach.ag/documentation/bsc/aggregator/editor/delegated-execution-with-permit2-witness).

A lower tolerance limits adverse price movement but can cause more reverts; a higher tolerance permits a worse price. Never raise it automatically after failure. Changes require fresh preparation and, in Delegated mode, a new signature.

The API's exact-input formula applies to expected **net** recipient output after custom fees:

`minAmountOut = expectedAmountOut * (10000 - slippageBps) / 10000`

Use integer base units and multiply before dividing; division rounds down. For example, 1001 output units at 50 bps produce a minimum of 995 units. The SDK sends the setting unchanged and checks consistency of the response and signed calldata; it does not recompute this formula to enforce the requested tolerance. Display the returned signed minimum and compare it with the terms your application is willing to accept.

Slippage protection is separate from price impact, gas fees and custom fees. Do not deduct the fee again from the signed minimum.

### Positive slippage

Positive-slippage treatment is bound through `settlementPolicyHash`. The SDK exports settlement-policy hashing utilities, but high-level prepared results do not provide a complete human-readable policy snapshot. Do not infer that all favorable price movement accrues to the recipient or derive the policy solely from a display quote.

Simulation reports `userAmountOut` for the chain state at the time of the call, not a guaranteed future or mined settlement amount.

See [Fees](https://docs.peach.ag/documentation/bsc/aggregator/editor/fees-slippage-and-settlement) for custom-fee settings and output amounts before and after fees.


---

# 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://docs.peach.ag/documentation/bsc/aggregator/editor/slippage.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.