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. 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.