1inch Fusion Mode turns a token swap into an intent-based order. Instead of broadcasting a conventional swap transaction and paying its network fee directly, the user signs acceptable price and time conditions. Professional market makers called resolvers compete to execute the order through a Dutch auction and pay the settlement gas. The experience can be gasless for the user, but the order can still wait, expire or execute at a rate between its optimistic and minimum return.
Last reviewed: September 27, 2026. 1inch interfaces, terminology, presets, supported tokens, networks, auction durations, resolver requirements and contract behavior can change. Confirm the live quote and wallet request in the official 1inch dApp. This article covers same-chain Fusion, now also described as an intent-based swap, not Fusion+ cross-chain swaps. It is independent educational content, not financial advice.
What is 1inch Fusion Mode?
Fusion is 1inch’s intent-based execution mode. A user specifies what asset will be exchanged and the acceptable result, while third-party resolvers determine how to source and settle the trade. The order combines offchain distribution with onchain settlement through 1inch protocol contracts.
The interface can resemble an ordinary swap, but the execution model differs. A Classic Swap asks the user’s wallet to submit a blockchain transaction. A Fusion order is signed and made available to resolvers. A resolver later performs the onchain execution when the auction terms are economically workable.
1inch documentation increasingly uses the name Intent Swap for this model. Older resources may call it Fusion Swap. The important distinction is the order structure, not the label shown in a particular interface version.
What is an intent?
An intent describes an acceptable outcome rather than a fixed route of contract calls selected by the user. In practical terms, the user expresses: “exchange this amount of the input token for at least this acceptable output within this period.”
The resolver can choose liquidity sources and settlement strategy as long as the signed constraints are respected. This allows professional executors to compete on price and execution while the user remains in control of the source assets until a valid order is settled.
An intent does not authorize unlimited behavior. Token, amount, receiving wallet, time limits and return conditions matter. Read the wallet signature and quote instead of assuming the 1inch brand makes every token or approval safe.
The Fusion lifecycle
- Quote: the user selects a network, input token, output token and amount.
- Parameters: 1inch calculates estimated returns and an auction curve using current market information.
- Approval: the token must have a valid allowance or supported permit.
- Signature: the user signs the Fusion order conditions.
- Distribution: the relayer makes the order available to resolvers.
- Auction: the executable return changes according to the price curve.
- Settlement: a resolver accepts the order, sources liquidity and pays the onchain gas.
- Result: output tokens reach the recipient, or the order expires if no resolver fills it.
Who are 1inch resolvers?
Resolvers are professional market makers or automated execution operators registered to fill Fusion orders. They monitor available orders, calculate whether execution is profitable, source tokens and submit settlement transactions.
A resolver can earn the difference between the value it obtains through its execution route and the amount it must deliver under the current auction terms, after accounting for gas and other costs. Competing resolvers have an incentive to fill attractive orders before another participant does.
The user does not manually select an individual resolver for each standard Fusion order. The protocol and auction make the opportunity available under the signed conditions.
Why does the resolver pay gas?
The resolver broadcasts the settlement transaction and therefore pays the network fee associated with that transaction. The resolver considers gas when deciding whether the order can be filled profitably.
For the user, this can remove the need to spend the network’s native asset on the Fusion settlement itself. According to 1inch, an expired Fusion order can also be resubmitted without the failed-transaction gas cost associated with an unsuccessful conventional swap.
Gas is not economically nonexistent. It is included in the resolver’s execution decision. A small order on an expensive network may be less attractive, and the auction rate can move until execution becomes practical.
Does gasless mean no native token is ever required?
Not always. The Fusion settlement can be gasless for the user, but a standard ERC-20 approval is a separate onchain transaction. If the token has no sufficient allowance and a supported gasless permit is unavailable, the wallet owner may need native gas to approve the 1inch contract.
After approval, later Fusion orders using the same valid allowance may not require another approval transaction until the allowance is exhausted, revoked or the spender contract changes.
Never buy an unknown “gas token” from a direct message or approve a contract solely because a website claims the final swap is gasless.
How the Dutch auction works
A Fusion order uses a price curve. The auction can begin with an optimistic return that is attractive to the user but difficult for resolvers to fill immediately. As time passes, the required output moves along the curve toward the minimum return accepted in the signed order.
A resolver fills when it can satisfy the current return and cover its costs. Competition can produce earlier execution at a better return, while difficult market conditions can move the order closer to its minimum or leave it unfilled.
This is called a Dutch auction because the executable requirement changes over time until a participant accepts it. It does not mean the user’s input amount is openly auctioned without limits.
Starting estimate, market amount and minimum return
| Quote value | Meaning | How to use it |
|---|---|---|
| Optimistic or starting return | Best result near the beginning of the curve | Do not treat it as guaranteed |
| Estimated market return | Reference based on current liquidity and market information | Compare it with Classic and independent market data |
| Minimum return | Lowest output permitted by the signed Fusion terms | Decide whether this outcome is acceptable before signing |
| Auction duration | Maximum period in which resolvers can fill the order | Balance urgency against the selected curve |
The minimum return is the most important downside boundary visible in the quote. A user who is comfortable only with the optimistic amount should not sign an order whose minimum is unacceptable.
Illustrative Dutch-auction example
Assume a user wants to exchange 10,000 USDC for ETH. The interface displays an optimistic return of 4.05 ETH and a minimum of 3.96 ETH over a defined auction period.
- A resolver may fill early at 4.03 ETH if liquidity and gas make that profitable.
- If no resolver accepts early, the required output can move lower along the curve.
- A later resolver might fill at 3.99 ETH.
- If no resolver can satisfy the order before expiry, no Fusion settlement occurs.
These figures are educational and do not describe a live market. The signed quote and onchain settlement determine the actual result.
Fusion presets: Auto, Fast, Fair and Custom
1inch has documented several ways to configure the auction. Names and availability can change, so use the controls shown in the current interface.
| Preset | General objective | Trade-off |
|---|---|---|
| Auto | Let 1inch select parameters for the pair and amount | The user still must review the resulting minimum and time |
| Fast | Encourage execution in earlier blocks | May accept a less favorable rate for speed |
| Fair | Wait longer for a potentially better balance of price and execution | Market can move and no fill is guaranteed |
| Custom | Set supported price and timing parameters manually | Unrealistic terms can leave the order unfilled |
| Auction option | Use a longer window and possible partial executions for suitable orders | More waiting does not guarantee a better final result |
How Auto should be reviewed
Auto can reduce configuration work by using 1inch backend calculations for the specific pair and volume. It does not transfer the final decision to 1inch. Before signing, inspect the exact output range and duration selected by Auto.
A parameter that works for a liquid stablecoin pair may be unsuitable for a volatile or thinly traded token. Re-open the quote if significant time has passed or the market moved.
How Pathfinder, the quoter and relayer fit together
1inch describes several offchain components:
- Pathfinder evaluates market liquidity and routes to establish relevant pricing information.
- Quoter uses pair, amount and selected preset to build the return curve.
- Relayer stores and distributes signed orders for resolver access.
- Resolver backend evaluates when and how an order can be profitably filled.
These services help coordinate the order, but settlement remains governed by onchain contracts and the signed conditions. If a quote becomes stale before signature, it may be rejected or unattractive to resolvers.
Sign the current quote, not an old one
Crypto markets can change within blocks. 1inch documentation explains that the calculated curve is time-sensitive. A delay between quote generation and signature can make the order irrelevant to current liquidity.
If the wallet was left open while checking another site, cancel the prompt, refresh the quote and inspect it again. Do not sign because a countdown creates pressure.
Token approval versus Fusion order signature
These are separate permissions:
- Token approval: an onchain authorization allowing a specified spender contract to transfer the source token.
- Order signature: authorization of the Fusion order’s exchange conditions.
An approval can remain valid after an order expires, while an expired order signature is no longer fillable under its time conditions. Review existing allowances and revoke permissions that are no longer needed.
Exact approval or unlimited approval?
An exact approval limits the contract to a particular amount but may require new transactions for future swaps. An unlimited approval can reduce repeated setup but increases exposure if the approved contract, interface or wallet is compromised.
Before approving, verify:
- official 1inch domain;
- correct blockchain;
- verified source-token contract;
- spender contract;
- allowance amount;
- wallet simulation and warnings;
- native gas estimate for the approval.
What does Pending mean in Fusion?
Pending can mean the signed order is active and waiting in its Dutch-auction period. It does not necessarily mean a transaction is stuck in the blockchain mempool.
Check the order status in the official 1inch interface using the wallet and network that created it. Identify whether it is active, partially filled, filled, expired or cancelled. If an onchain settlement hash exists, then inspect that hash on the correct block explorer.
Why a Fusion order may not fill immediately
- The current auction return is not profitable for resolvers.
- The order is small relative to network execution cost.
- The pair has limited liquidity.
- The market moved outside practical execution conditions.
- The source-token balance or allowance changed.
- The selected minimum return is too demanding.
- Resolver availability or protocol infrastructure is temporarily limited.
- The token has unusual transfer behavior.
Waiting is part of the execution design, but a status should be verified rather than assumed.
What happens when a Fusion swap expires?
If no resolver fills the order before its deadline, the order expires. According to 1inch, it can be submitted again without paying gas for the expired Fusion execution.
Expiry does not guarantee that the token allowance was removed. The approval and the order are separate. Before resubmitting, refresh the market quote, inspect the balance and review whether the old allowance remains appropriate.
Never increase risk parameters blindly just to force a fill. A new quote is a new decision.
What if the source tokens are moved?
Fusion does not necessarily lock source tokens in a separate balance when the order is signed. If the user spends or transfers the source asset, reduces the allowance, or otherwise makes the balance unavailable, a resolver may be unable to settle the order.
Keep the required amount accessible until the order fills, expires or is safely cancelled. Avoid creating overlapping orders that collectively require more tokens than the wallet holds.
Can Fusion orders fill partially?
Fusion and the underlying order infrastructure can support partial execution in relevant configurations. A large order can be split across several resolver fills instead of waiting for one participant to settle the entire amount.
Review:
- original input amount;
- amount already filled;
- remaining amount;
- weighted average output;
- individual settlement hashes;
- expiry of the remainder.
Do not count the first fill as completion without checking the remaining order state.
Fusion versus Classic Swap versus Limit Order
| Feature | Fusion / Intent Swap | Classic Swap | Limit Order |
|---|---|---|---|
| User action | Signs outcome conditions | Broadcasts a swap transaction | Signs a target-price order |
| Execution | Resolver competes through a Dutch auction | Aggregator route executes onchain | Taker fills when conditions are attractive |
| Settlement gas | Resolver pays | User pays | Depends on execution model |
| Timing | Can wait during an auction | Transaction waits for network confirmation | Can remain active until fill or expiry |
| Price structure | Return follows a curve toward minimum | Quote plus slippage protection | Chosen order rate |
| Failure outcome | Order can expire without a Fusion settlement | Failed transaction can consume gas | Order can remain unfilled or expire |
Our separate 1inch limit-order guide covers static target rates, cancellation and unfilled limit orders.
Fusion versus Fusion+
Fusion handles intent-based execution on one network. Fusion+ extends the design to cross-chain swaps using escrow contracts, secrets and timelocks across source and destination networks.
Do not apply same-chain assumptions to a Fusion+ transfer. Cross-chain verification, destination-chain assets and refund timing require a separate workflow. This article intentionally does not duplicate cross-chain guides already available in the library.
How Fusion addresses MEV
Maximum extractable value describes profit obtained by controlling transaction ordering or inclusion. A sandwich attack can place trades before and after a user’s public swap, worsening execution.
Fusion does not expose a conventional user swap to the public mempool in the same way. Resolvers compete to fulfill the signed intent, and the resolver handles settlement. 1inch describes this design as protecting users from front-running and sandwich attacks.
MEV protection does not prove that a token is legitimate, guarantee future price or secure a compromised wallet. It addresses execution-order risks within the supported protocol flow.
What Fusion does not protect against
- selecting a fake token contract;
- signing on a phishing domain;
- granting a malicious token allowance;
- using a compromised wallet or browser;
- accepting an unsuitable minimum return;
- market movement after receiving the output token;
- token taxes, rebasing or restrictive transfer logic;
- smart-contract and infrastructure risk;
- tax or legal consequences of the swap.
How to create a Fusion swap safely
- Open 1inch from a verified bookmark.
- Connect the intended wallet and select the correct network.
- Verify both token contracts independently.
- Enter the input amount and preserve a sensible balance.
- Confirm that Fusion or Intent Swap is the selected mode.
- Compare the quote with Classic Swap and independent market information.
- Review the optimistic result, minimum return and auction duration.
- Inspect the approval spender and amount if an allowance is needed.
- Refresh a stale quote before signing.
- Read the wallet signature request and confirm the recipient.
- Monitor the active order through the official dApp.
- After execution, verify output-token balance and settlement hashes.
- Revoke an unnecessary allowance after all intended activity is complete.
How to evaluate the completed result
Do not compare only the final wallet balance with the optimistic quote. Record:
- source-token quantity transferred;
- destination-token quantity received;
- weighted result across partial fills;
- minimum return signed;
- auction duration and execution time;
- approval gas paid by the user, if any;
- settlement gas paid by the resolver;
- market reference at signature and settlement;
- transaction hashes and order identifier.
Status and troubleshooting table
| Status or symptom | Likely meaning | Safe response |
|---|---|---|
| Waiting / Pending | Order remains in its auction window | Review current status, balance, allowance and remaining time |
| Partially filled | Some amount settled while a remainder remains | Record completed fills and inspect the remainder |
| Expired | No resolver completed the remaining order before deadline | Refresh the quote and resubmit only if new terms are acceptable |
| Insufficient balance | Source tokens were moved or another order consumed them | Reconcile active orders and wallet balance |
| Allowance problem | Approval is missing, too small, revoked or for another spender | Verify the official contract before approving |
| No Fusion option | Pair, network, amount or current availability may not qualify | Use the modes displayed by the official dApp; do not install a third-party extension |
| Output token not visible | Wallet may not display the verified contract automatically | Check explorer transfers and import only the verified token contract |
Common Fusion mistakes
- Treating the optimistic return as guaranteed.
- Ignoring the minimum return before signing.
- Assuming gasless settlement also makes the approval gasless.
- Confusing Pending order status with a stuck mempool transaction.
- Moving source tokens while the order remains active.
- Creating several orders against the same wallet balance.
- Signing a stale quote after a major market move.
- Increasing the auction range simply to force execution.
- Using an unverified token with a familiar ticker.
- Accepting an unlimited approval without checking the spender.
- Assuming MEV protection prevents every type of loss.
- Following Fusion+ cross-chain instructions for a same-chain Fusion order.
- Ignoring partial fills and counting only the first settlement.
- Calling an unofficial “resolver support” account.
Pre-signing checklist
- Official 1inch domain verified.
- Correct wallet and network connected.
- Source and destination contracts checked.
- Fusion/Intent mode confirmed.
- Input amount and recipient reviewed.
- Optimistic and minimum returns understood.
- Auction duration acceptable.
- Quote compared with Classic and current market data.
- Approval spender and allowance verified.
- Native gas available if approval requires it.
- Source balance will remain available during the auction.
- Order-monitoring and expiry plan prepared.
Frequently asked questions
What is 1inch Fusion Mode?
It is an intent-based swap mode in which the user signs acceptable exchange conditions and resolvers compete to execute the order through a Dutch auction.
Is 1inch Fusion really gasless?
The resolver pays gas for Fusion settlement. The user may still need native gas for a separate ERC-20 approval when no sufficient allowance or supported permit exists.
Who is a 1inch resolver?
A resolver is a registered professional execution participant that evaluates Fusion orders, sources liquidity and submits settlement transactions.
Why is my Fusion swap pending?
The order may still be moving through its Dutch-auction window while resolvers evaluate execution. Check the active order, remaining time, balance and allowance.
What happens if a Fusion order expires?
No remaining settlement occurs under that order. Refresh market conditions and resubmit only if the new quote is acceptable. The token approval may remain active separately.
Can a Fusion swap be partially filled?
Relevant Fusion configurations can support multiple fills. Review the amount completed, weighted output and remaining active amount.
Does Fusion guarantee the displayed best amount?
No. The starting or optimistic result is not guaranteed. Execution can occur along the auction curve down to the signed minimum return.
Does Fusion protect against sandwich attacks?
1inch describes Fusion’s intent and resolver model as providing protection against front-running and sandwich attacks. It does not protect against phishing, fake tokens or careless approvals.
Is Fusion the same as a 1inch limit order?
No. Fusion uses a time-dependent Dutch-auction curve and resolver competition. A conventional limit order specifies a target rate and can remain open until filled, cancelled or expired.
Is Fusion the same as Fusion+?
No. Fusion is the same-chain intent-based mode covered here. Fusion+ adds cross-chain escrow, hashlock and timelock mechanics.
Do my tokens become locked after signing?
Do not assume a separate locked balance. Keep the required source amount and allowance available until the order fills, expires or is cancelled.
Can I cancel a Fusion order?
Use the action and status shown in the current 1inch interface. Cancellation behavior can depend on the order state, so confirm whether an onchain action is requested and inspect its gas cost before signing.
Final perspective
Fusion changes who manages execution, not the need to review the trade. Resolvers pay settlement gas and compete through a Dutch auction, while the user’s signed minimum return defines the acceptable boundary. The result can be more convenient and resistant to common MEV attacks than a conventional public-mempool swap.
The most important checks remain simple: verify tokens and contracts, distinguish approval from order signature, understand the full auction range, keep the source balance available and verify the final settlement. Gasless execution should make the workflow easier, not make the user less careful.
Official sources and further reading
- 1inch Blog — Intent-based swaps and Fusion Mode
- 1inch Help Center — How Fusion works
- 1inch Blog — Fusion offchain execution
- 1inch Blog — Fusion onchain settlement
- 1inch Developer Portal — Intent Swap introduction