1inch comparison is fusion orders versus Classic split routing

Pathfinder v6.1 sharpens the Classic side of the choice

Pathfinder v6.1 makes Classic routing more competitive by combining finer liquidity splits with merged paths that reduce avoidable execution overhead inside one atomic transaction. That matters because this 1inch comparison is no longer a simple gasless-versus-basic choice. Fusion’s Intent Swap v2.0 still delegates the fill to resolvers, yet Classic gives integrators explicit controls for protocols, connector tokens, route parts, minimum return, and gas estimation. The first decision is therefore whether immediate atomicity or delegated execution has higher value.

Who pays for execution in Fusion and Classic?

Fusion makes the resolver pay settlement gas, whereas Classic makes the connected wallet fund and broadcast the routed swap transaction on the selected chain.

On Ethereum, chain ID 1, a Classic ERC-20 swap with insufficient allowance and no permit creates two on-chain actions: an approval and the swap. With an existing allowance, only the swap remains. The wallet pays both execution gas and any approval gas in ETH, whose base unit is wei; 10^18 wei equals 1 ETH. Fusion replaces the settlement transaction with an EIP-712 order signature. A resolver settles it and recovers gas through the auction economics, so "gasless" describes the user’s settlement payment, not zero execution cost inside the fill.

Token authorization remains separate. EIP-2612 permits or Uniswap Permit2 can package authorization as signatures when the token and flow support them. Otherwise, an initial ERC-20 approval still needs a transaction. For integration fees, 100 basis points equal 1%; that conversion matters because Fusion exposes basis-point fields, while the Classic v6.1 endpoint expresses its partner fee as a percentage.

The comparison should use net output after all economic costs. For Fusion, inspect auction start amount, auction end amount, token fee, and gas adjustment. For Classic, combine destination amount, pool fees, price impact, and the wallet’s estimated network fee. The larger displayed output does not automatically produce the larger settled balance.

Price protection and incomplete execution

Price protection differs because Classic enforces one transaction threshold, while Fusion lets a signed order move along a bounded auction curve before expiry.

Classic accepts either a slippage percentage or an explicit minimum return. The router reverts the transaction if settlement cannot satisfy that bound, although the failed transaction still consumes gas. The Classic v6.1 swap endpoint accepts slippage from 0% through 50%, while integrators must choose either slippage or a minimum return. A 50% setting is an API ceiling, not a sensible default. Partial fill is false by default in the endpoint, preserving all-or-nothing behavior unless an integrator deliberately enables it. Partner fees accept values from 0% through 3%, another input that belongs in net-output arithmetic.

Fusion encodes an auction start amount, an end amount, a duration, and price-curve points. The receive amount available to a resolver declines within that signed boundary until a fill becomes economic. An order can receive multiple partial fills when its preset permits them; otherwise, it either settles or expires. Expiry leaves unfilled source tokens in the user’s wallet, while a partial fill reduces the order’s remaining capacity.

A pending Fusion order also depends on relayer distribution and active resolver interest. Classic depends on the selected RPC broadcast and pool state at inclusion. Choose the failure state you can operationally handle: an expired order or a reverted transaction with spent gas.

Order intent versus atomic route execution

Fusion signs an off-chain order description for resolver filling, while Classic signs one EVM transaction whose calldata fixes the chosen route and thresholds.

Fusion order path

The maker requests a quote, chooses fast, medium, slow, or custom, and signs typed data under EIP-712. The signed order includes maker asset, taker asset, amounts, receiver, expiry-related traits, and auction parameters. Its 32-byte hash becomes the tracking key. A 20-byte EVM address identifies the maker and settlement contracts, while the chain-specific signing domain prevents the same order from being treated as universal across networks.

Maker side

For ERC-20 inputs, the maker keeps the source token until settlement. A valid allowance or permit lets the settlement flow transfer only the filled amount. An order that allows multiple fills tracks remaining capacity; a single-fill order closes after its successful fill.

Resolver side

Resolvers evaluate the price curve, gas estimate, available liquidity, and their own execution path. Resolver guidance recommends splitting eligible orders into 6-10 parts and checking whether at least one part is profitable to fill. Competition happens around the signed minimum, not beyond it.

Classic transaction path

Pathfinder returns calldata for an atomic route. Its protocol distribution expresses route shares as percentages that total 100%, and the transaction invokes the 1inch Router directly. A route can pass through connector assets such as WETH and can split liquidity across Uniswap v3, Curve, Balancer, or PancakeSwap before recombining at the destination token. The wallet signs and broadcasts once after any required approval. Verification therefore starts with the transaction receipt, token balance delta, actual destination amount, gas used, and the route that executed, rather than an off-chain order-status endpoint.

When does split routing beat a resolver auction?

Classic split routing wins when immediate execution, custom route controls, or a tightly specified minimum return outweigh the cost of wallet-paid gas.

Pathfinder can divide one input across pools and depths when the combined output justifies extra calldata and gas. Uniswap v3 exposes common fee tiers of 0.01%, 0.05%, 0.3%, and 1%; Curve concentrates on low-slippage stable-asset and pegged-asset pools; Balancer supports weighted pools; PancakeSwap offers BNB Chain liquidity. The router evaluates these venues as parts of a route rather than requiring the user to select one pool.

Fusion has the stronger case when the wallet lacks the chain’s native gas token, when MEV protection matters, or when resolver competition has room to improve execution during the auction. For eligible large orders, partial fills let different resolvers settle separate portions at different price points. Yet size alone does not decide the mode. Compare the two quoted receive boundaries, the Fusion auction horizon, the Classic gas estimate, and the exact token approvals already present. The next choice is whether waiting capacity or atomic finality better fits the trade (detailed in Swap Preview ).

Direct pool fees remain embedded in the route economics in both modes. Resolver settlement changes who submits the transaction, not the underlying liquidity sources. Read the destination amount beside the complete execution model.

Chain coverage and token handling

Fusion reaches one documented chain that Classic omits, while their shared EVM coverage includes the networks most users expect from 1inch swap execution. Intent Swap supports 14 documented chain IDs, including Solana at 501, while Classic supports the other 13 listed EVM networks. Shared examples include Ethereum 1, Base 8453, BNB Chain 56, Polygon 137, Arbitrum 42161, Optimism 10, Avalanche 43114, Gnosis 100, Linea 59144, and zkSync 324. Confirm mode availability for the selected pair before comparing quotes.

A decision checklist before signing

A reliable 1inch comparison ends by matching the quoted execution model to five concrete conditions that remain visible before wallet confirmation and signing.

• Native gas: Choose Fusion when the ERC-20 wallet lacks ETH, BNB, or the relevant EVM gas token; choose Classic only after funding execution.
• Timing: Choose Classic when the swap must settle in one broadcast; accept Fusion only when the auction and possible expiry fit the workflow.
• Price boundary: Compare the Classic minimum return with the Fusion auction end amount, not only the optimistic start quote.
• Allowance: Count an ERC-20 approval as a separate on-chain action unless EIP-2612 or Permit2 removes that step for the selected token.
• Verification: Prepare to inspect one transaction receipt for Classic or an order hash plus fill transactions for Fusion.

Wallet type adds one last constraint. MetaMask handles ordinary EVM transaction and EIP-712 signing flows, while Ledger requires the connected interface and device to display supported typed data correctly. Smart-contract wallets add signature validation and timing considerations; the Fusion v2.0 order builder even exposes an additional auction-start delay for multisignature flows. After execution, reconcile the received token balance, allowance state, fees, and status. Repeat that check whenever the token pair, chain, wallet, or trade size changes, because the preferred mode belongs to the transaction, not permanently to the account.