How It Works

Infrared finds the best execution path for token swaps by aggregating liquidity across multiple protocols and assembling optimized transactions. This page explains the request lifecycle, routing approach, and execution model at a conceptual level.

Request Lifecycle

A swap goes through four stages:

1. Quote request -- The consumer submits input tokens (with amounts), desired output tokens (with ratio allocations), the taker address, and optional parameters like slippage tolerance and gas priority.

2. Route discovery -- The system identifies all available liquidity paths across supported protocols. This includes direct swaps, multi-hop routes through intermediate tokens, and split paths that divide the input across multiple protocols.

3. Route optimization -- From the discovered paths, the optimizer selects the combination that produces the best output after accounting for gas costs, protocol fees, and price impact. The result is a complete execution plan with estimated outputs and cost breakdown.

4. Quote response -- The consumer receives a quote_id, the selected route with per-step details, estimated output amounts (expected and minimum after slippage), gas cost estimates with EIP-1559 parameters, and any required token approvals.

Routing Optimization

The routing engine operates across several dimensions to find the best execution:

Multi-protocol evaluation -- Every quote considers all supported protocols as potential liquidity sources. A swap from WETH to DAI might route through Uniswap V3 for one portion and Curve for another, depending on where depth is concentrated.

Multi-hop routing -- When a direct swap path has poor liquidity, the engine can route through intermediate tokens. A swap from Token A to Token C might go A -> WETH -> C if the intermediate hops offer better combined pricing.

Split output allocation -- The ratio_bps field on output tokens allows a single request to split output across multiple tokens. For example, swapping 1 ETH into 50% DAI and 50% USDC (each with ratio_bps: 5000) produces two output legs optimized independently.

Slippage protection -- Every quote includes both an expected_amount and a minimum_amount for each output token. The minimum amount accounts for the consumer's slippage_tolerance_bps setting and represents the guaranteed floor enforced on-chain.

Protocol exclusion -- Consumers can exclude specific protocols (exclude_protocols) or individual pools (exclude_pools) from routing when they have operational reasons to avoid certain liquidity sources.

Quote-Then-Build Execution Model

The API separates quoting from transaction assembly for several reasons:

Why Two Steps

Inspection before commitment -- After receiving a quote, consumers can evaluate the route, check estimated outputs against their requirements, and decide whether to proceed. No on-chain action happens until the build step.

Fork simulation -- Both the quote and build steps support a simulate parameter that runs the transaction against a fork of the current chain state. This verifies the transaction will succeed and provides actual output amounts before real execution.

Permit2 signatures -- The build step accepts an optional permit2_signature for signature-based token approval. This eliminates the need for a separate on-chain approval transaction, reducing gas costs and improving UX.

Reusable quotes -- A quote can be built multiple times. If a consumer wants to retry with a Permit2 signature after initially building without one, they can resubmit the same quote_id without re-routing.

What Each Step Produces

Quote returns:

• quote_id -- identifier for the build step

• estimated_outputs -- expected and minimum amounts per output token

• costs -- gas cost breakdown with EIP-1559 parameters

• path -- the full execution route with token metadata and per-step details

• protocols_used -- which protocols the route passes through

• approvals -- any ERC-20 approvals needed before execution

• permit2 -- EIP-712 typed data for signature-based approval (when requested)

Build returns:

• transaction -- unsigned transaction object (to, data, value, gas, chain_id) targeting the ExecutionProxy contract

• estimated_outputs -- carried forward from the quote

• simulation -- fork simulation results (when requested)

After Building

The consumer signs the returned transaction with their wallet and submits it on-chain. The transaction executes atomically through the ExecutionProxy contract -- either all swaps in the route succeed, or the entire transaction reverts.

Why This Architecture

Better prices -- Aggregating across protocols means the engine can find liquidity that a single-protocol integration would miss. Multi-hop and split routing capture additional value from fragmented liquidity pools.

Reduced slippage -- By spreading volume across multiple pools and protocols, each individual pool absorbs less impact. The enforced minimum output amount provides on-chain protection against adverse price movements.

Single integration point -- Consumers maintain one API integration instead of one per protocol. New protocol support is added server-side and becomes available to all consumers without code changes.

Gas efficiency -- The ExecutionProxy contract batches all swap operations into a single transaction, avoiding the gas overhead of multiple separate swap calls.