---
title: Trade types
description: Fixing the input or the output of a trade, and how each mode is priced.
---

Every quote request carries a `trade_type`. It answers two independent questions: which side of the trade the `amount` field fixes, and whether the quoted output is a target or a commitment. The field is required; `TRADE_TYPE_UNSPECIFIED` is rejected with `invalid trade_type`.

| Value | `amount` fixes | Output is |
| --- | --- | --- |
| `TRADE_TYPE_EXACT_INPUT` | The deposit, in source token base units | A target within slippage |
| `TRADE_TYPE_EXPECTED_OUTPUT` | The payout, in destination token base units | A target within slippage |
| `TRADE_TYPE_EXACT_INPUT_GUARANTEED_OUTPUT` | The deposit | Guaranteed |
| `TRADE_TYPE_EXACT_OUTPUT` | The payout | Guaranteed |

All four return the same response shape. `amount_in` on the response is the deposit amount: when the request fixes the input it echoes the request, when it fixes the output it is the solved value. Whichever type you quote, the deposit is built from `order_params.amount_in`.

## How output-fixed types are priced

For `EXPECTED_OUTPUT` and `EXACT_OUTPUT` the engine runs the pipeline in reverse (deterministic fees are inverted exactly; aggregator swap legs are estimated from a single probe quote assuming a linear price) and then prices the solved input forward through the normal exact-input pipeline. The forward pass is what the quote binds: every floor, fee, and safety check comes from it.

For `EXPECTED_OUTPUT` this means `amount_out` on the response is the binding expectation and can land a few basis points off the requested `amount`. It promises a target, not a guarantee; the delivered amount can be less or more within slippage, exactly as in exact-input mode, and `min_amount_out` is still the enforced floor.

## Guaranteed types

`EXACT_INPUT_GUARANTEED_OUTPUT` and `EXACT_OUTPUT` pin the floor to the quoted output: `min_amount_out` equals `amount_out`, `slippage_bps` comes back as `0`, and a fulfillment that cannot deliver the full amount does not land; the order refunds on the source chain instead of delivering less.

- `EXACT_INPUT_GUARANTEED_OUTPUT`: the user fixes the deposit and the response's `amount_out` is the committed payout.
- `EXACT_OUTPUT`: the user fixes the payout and the response's `amount_in` is the deposit that buys it. The committed `amount_out` equals the requested amount exactly; rounding in the input solve always lands at or above the request, and any dust above it stays with the operator rather than being delivered.

The guaranteed types are offered on routes with no swap leg on either side: the deposited token is the bridge token and the delivered token is its destination counterpart. On a same-asset lane the guarantee costs nothing extra. On a cross-asset lane the operator carries the peg risk between quote and fill, and charges a fixed premium for it: the `guaranteed_output_buffer` component in `fee_breakdown`, in basis points configured per lane. Cross-asset lanes without a configured buffer, pairs requiring a swap leg, and same-chain swaps fail with `guaranteed output is not supported for this pair`; fall back to the corresponding target type. As volatility-priced buffers roll out, eligibility will widen to whitelisted volatile pairs.

## Choosing a type

Quote input-fixed when the user edits the sell field, output-fixed when they edit the buy field. A form can switch `trade_type` per keystroke; the response's `amount_in` and `amount_out` always give you both sides to render.

Use `EXACT_INPUT` when the deposit is the constraint, such as sweeping a balance or spending a fixed budget. Use `EXPECTED_OUTPUT` when the destination is the constraint, such as topping an account up to a level. For payments that must deliver precisely the promised amount, such as an invoice denominated in the destination token, use the guaranteed types.