--- title: Slippage description: The two slippage settings, the floors they produce, and where each one is enforced. --- A swap leg only exists when the token you deposit is not the token that moves between chains, or when the token delivered is not the one that arrived. Those legs route through an aggregator, so they need a floor. Straight transfers of the same asset have no slippage at all. ## Two settings, two legs | Field | Applies to | Produces | | --- | --- | --- | | `src_slippage_bps` | The source swap, from `src_token` into `bridge_token_src` | `min_bridge_out` | | `slippage_bps` | The destination swap, into `dst_token` | `min_amount_out` | Both are optional on the request. Omit them and the operator applies a tier appropriate to the pair and size; the value actually used comes back as `slippage_bps` on the quote, so read it from the response rather than assuming your input was taken verbatim. On an [expected-output](/concepts/trade-types) quote the omitted default is 150 bps on both legs instead of the tier, absorbing the estimation in the reverse pricing pass. ## Where the floors are enforced `min_bridge_out` is checked on the source chain, inside the deposit transaction. The router runs the aggregator call and reverts with `InsufficientOutput` if the swap returns less. The user's funds never leave their wallet on a failed deposit. `min_amount_out` is checked on the destination chain, inside the fulfillment. If the destination swap cannot clear the floor, the fulfillment does not land, and after the attempt limit the order routes to refund rather than delivering less than promised. Surplus above a floor stays in the vault; it is not delivered to the recipient and not returned to the sender. ## Choosing a value Wider slippage does not cost anything when the market cooperates: the floor is a limit, not a price. It costs when it is too tight, because the deposit reverts or the order refunds, and the user pays gas for nothing either way. For stable-to-stable transfers of the same asset there is no swap leg on either side, so neither setting has any effect. `bridge_token_src` equals `src_token` and `min_amount_out` equals `amount_out` minus fees. ## Reading the result ```ts const quote = quoteOf(await hular.getQuote(request)); quote.slippageBps; // basis points actually applied quote.minAmountOut; // floor on the destination side quote.orderParams.minBridgeOut; // floor on the source side ``` Show `min_amount_out` next to `amount_out` in a confirmation screen. It is the number the protocol guarantees; `amount_out` is the number it expects.