1inch

1inch Fusion uses Dutch auctions to fill swaps

1inch Fusion uses Dutch auctions to let market makers called resolvers fill swaps within an order's price and time limits. The required output starts higher and falls along the auction curve. The token owner signs or places the order, with funding requirements that depend on the network and input asset.

Auction swaps and direct swaps differ in execution timing

Auction execution fits a swap that can wait for resolver participation within defined price and time limits. A Classic swap submits an aggregation transaction whose sender funds the network fee. Conventional fixed-price limit orders wait for their price condition; Fusion adds a time-dependent auction to its order terms. Fusion+ coordinates exchanges across supported networks, giving it a different settlement scope from a same-network swap. The choice turns on timing, transaction funding, and the destination network. Direct submission still requires blockchain confirmation.

Minimum return and expiry bound the auction

Minimum receive constrains the output for the executed quantity, while the order's expiration time sets the deadline for a valid fill.

View full-size image

Output falls along the auction curve

For a fixed input quantity, the auction begins with a higher required output and reduces it over time toward the order's minimum, making execution progressively more attractive to resolvers that must acquire the output and cover settlement costs. A fill early in the auction can therefore return more tokens than one near its end. This direction describes the time-based curve; gas adjustments can also influence the amount calculated at settlement.

Duration belongs to the selected preset

Auction presets package a duration and a price curve. Swap size, liquidity, and estimated gas influence the quote, so orders bearing the same preset name can carry different terms. Expiry ends the remaining opportunity to fill that order. A deadline limits valid execution; it does not promise settlement before that deadline.

Ethereum Virtual Machine (EVM) gas adjustments compare encoded estimates with the execution-time base fee, which can change the output without changing the order's signed minimum.

Partial fills follow the remaining quantity

When an order permits repeated partial fills, different resolvers can exchange separate portions at the applicable auction rates. The protocol records the reduced remainder and prevents later fills from exceeding the available quantity. A filled portion remains an executed trade even if the rest expires. The displayed full-order minimum must therefore be interpreted alongside how much of the input has actually changed hands.

Swap costs differ between off-chain orders and escrow funding

The cost of a Fusion swap includes any funding or authorization transactions that its particular order path requires before resolver execution.

Off-chain EVM token orders

The resolver pays the network gas for filling an off-chain EVM Fusion token order. The token owner, or maker, signs the order, and the relayer distributes it for execution. Any required on-chain token approval still has its own network fee; a supported permit can provide the needed authorization through a signature. Resolver costs influence the quoted rate. The settlement terms can also allocate protocol or integrator fees and a share of price surplus.

Native EVM order funding

Supported native-asset orders can use NativeOrdersFactory to fund an on-chain escrow that handles wrapping for settlement, and creating that escrow requires a paid network transaction that also supplies the native input. This removes the manual wrapping step while retaining an on-chain setup cost. The escrow holds the assets during the order's waiting period.

Solana order publication

Solana Fusion publishes the intent on-chain through an escrow transaction, which carries a network fee paid in SOL. The escrow holds the input while resolvers compete to execute the exchange. Publishing the intent does not establish that the swap will fill, and its upfront fee still pays for that transaction when the order remains unfilled. Solana publication incurs a network fee; signing an off-chain EVM order does not.

Resolver settlement reduces exposure to transaction ordering

Off-chain EVM signing avoids publishing the maker's ordinary swap transaction in the public mempool, where transactions await inclusion in a block. Fusion uses resolver settlement and transaction bundling to defend against front-running, a form of maximal extractable value (MEV). Ethereum settlement also caps priority fees under its configured rules to limit bidding for transaction position. The order still circulates among participants that need its terms. These protections target execution ordering; market prices can move while an order waits.

Minimum return and duration guide the auction choice

For the same token pair and input amount, compare the offered presets by their output curve, minimum receive, and duration. A longer window gives resolvers more time to act, while a higher minimum leaves less room for an economical fill. Those values belong to the specific quote; the durable rule is that settlement must satisfy the order's terms.

View full-size image

• Confirm that the network and both selected assets support the Fusion path offered by the interface.
• Read the minimum receive amount together with the input quantity that it covers.
• Compare the auction duration with how long the swap can remain unresolved.
• Account for required approval, native escrow funding, or Solana publication costs before committing.
• Decide whether a partial exchange is acceptable under the order's fill settings.

After an EVM order with suitable terms is authorized and submitted, a change from pending to filled should match confirmed fills that cover its intended input and credit the output to the designated recipient. A partially filled status leaves some of the intended exchange incomplete.

Settlement contracts enforce pricing and resolver access

On EVM networks, the Limit Order Protocol and Fusion's settlement extension jointly enforce the terms that govern a fill.

Amounts and permissions at settlement

The resolver calls the protocol's fill function. The settlement extension computes the applicable auction amount and checks the conditions encoded for that order. A valid fill must satisfy the order's asset and amount rules. Relayer acceptance alone does not establish that tokens have changed hands.

Eligibility changes during an auction

Resolver access can follow a schedule encoded in an EVM order. Listed resolvers can have different eligibility times, and a filler outside that list needs the applicable access token after the schedule has elapsed. Current Fusion resolver onboarding uses verification and issued access tokens. Unicorn Power-based staking and delegation requirements are disabled. Registration alone does not bypass the order's timing checks. The signed schedule can limit participation even when other resolvers could supply liquidity.