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

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.

​
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

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.