1inch Cross-Chain Swap Guide: How Fusion+, Escrows, Resolvers and Refunds Work

A 1inch cross-chain swap lets a user pay with an asset on one blockchain and receive another asset on a different blockchain through one intent-based order. Fusion+ hides much of the complexity, but settlement still involves resolvers, linked escrow contracts, two network histories, cryptographic conditions and timelocks. This guide explains that lifecycle, what “gasless” and “atomic” really mean, and how to investigate a pending or refunded order safely.

Last reviewed: October 29, 2026. Supported networks, tokens, interfaces, resolver rules, escrow timing, approvals and recovery behavior can change. Follow the instructions displayed by the current official 1inch application before signing. This independent article is educational and is not financial, investment, legal or individualized security advice.

What is a 1inch cross-chain swap?

A cross-chain swap exchanges value across two separate blockchain ledgers. For example, a user may sell a token on Arbitrum and receive a different token on Solana or Ethereum. The source asset does not literally jump from one ledger to another. Instead, coordinated settlement transfers assets already available on both sides.

1inch powers this flow with Fusion+, an intent-based protocol in which professional executors called resolvers compete to fulfill the user’s signed outcome. The resolver supplies the destination asset, coordinates escrow settlement and covers applicable execution gas. The user reviews the source, destination, amount and minimum return rather than manually operating a bridge and then a DEX.

Fusion and Fusion+ are not the same

Both products use intents and resolvers, but they solve different problems.

Our separate 1inch Fusion Mode guide covers same-chain auctions, presets and resolver execution. This article focuses on the additional cross-chain machinery.

Fusion+ versus a traditional bridge

A bridge commonly locks or burns an asset on one chain and releases or mints a corresponding representation on another. The user may then need a second swap to obtain the desired destination token. This creates several manual steps and may leave the user holding a wrapped representation whose value depends on the bridge system.

Fusion+ instead expresses the final outcome as one order: sell a defined source asset and receive a defined destination asset. Linked escrows coordinate assets on both chains. According to 1inch, this model does not require a messaging bridge or a wrapped intermediary for the transfer.

That does not make Fusion+ risk-free. It replaces bridge-specific custody and wrapped-asset risks with dependencies on protocol contracts, resolvers, liquidity, interface correctness and both blockchains.

The participants in a Fusion+ order

• Maker: the wallet owner who signs the cross-chain intent.
• Resolver: an executor that accepts the order, supplies destination liquidity and performs settlement.
• 1inch order infrastructure: distributes the signed intent and coordinates the execution flow.
• Source escrow: holds the source-side asset under cryptographic and time conditions.
• Destination escrow: holds the asset intended for the maker on the other chain.
• Blockchain networks: independently confirm each escrow and withdrawal transaction.

No legitimate resolver needs the maker’s recovery phrase or private key. The wallet signs specific approval and order data; signing secrets remain inside the wallet.

What the maker specifies

A safe cross-chain intent needs more than token tickers. It should bind the source token and chain, amount, destination token and chain, receiving address, acceptable return and time conditions. The user should review every displayed value immediately before signing because a quote can expire while token prices or resolver costs change.

An intent authorizes an outcome, not unrestricted wallet access. However, a separate token approval may give a protocol spender authority over a chosen allowance. Approval and intent must be reviewed as different requests.

What a resolver does

Resolvers monitor available orders and decide whether they can fulfill the requested result profitably. They can source liquidity through their own inventory or available venues and compete through the auction process. The winning resolver funds the required escrows, pays settlement gas and completes the linked withdrawals.

A resolver takes execution, timing and inventory risk. Its costs are economically reflected in the quote even when the interface shows no separate network fee charged to the user. “Resolver pays gas” does not mean blockchain computation is free.

How the Dutch auction affects execution

Fusion+ builds on the intent auction model. The order begins with terms calculated from current market conditions, then evolves along an auction curve until a resolver accepts it. This competition can improve execution, but it does not guarantee the optimistic amount initially displayed.

The critical protection is the signed minimum return. If market conditions do not allow a resolver to satisfy the order, it should expire or enter recovery rather than execute below the permitted terms. Inspect the minimum—not only the headline estimate.

The complete Fusion+ lifecycle

1. The user selects the source token and network.
2. The user selects the destination token, network and receiver.
3. 1inch returns a quote with expected and minimum output.
4. The user grants a token allowance if one is required.
5. The wallet signs the cross-chain intent.
6. The order is distributed to eligible resolvers.
7. A resolver accepts the auction terms.
8. The resolver creates the source-chain escrow using the signed order.
9. The resolver creates and funds the destination-chain escrow.
10. The system verifies both contracts and required finality.
11. The cryptographic secret enables the coordinated withdrawals.
12. The user receives the destination asset and the resolver claims the source asset.
13. The interface marks the order completed after verification.

Some phases happen quickly, while others wait for network confirmations. A progress indicator is a summary of several blockchain events, not one transaction traveling between chains.

How the source escrow works

The source escrow applies the maker’s signed order on the chain where the sold asset exists. It contains or references the token, amount, participants, secret hash and time conditions. Once created, it restricts withdrawal according to protocol rules rather than giving the resolver arbitrary custody.

When inspecting a source transaction, verify the network, official contract context, asset and amount. Do not treat any contract labeled “escrow” by a random explorer tag as authentic without confirming it through the order and official interface.

How the destination escrow works

The resolver funds another escrow on the destination chain with the asset promised to the user. Its cryptographic conditions correspond to the source escrow. Settlement should not proceed as two unrelated transfers based merely on trust in the resolver.

The destination asset may be a different token, not a wrapped copy of the source token. Confirm its contract address and network because an identical ticker can represent unrelated or fraudulent assets.

Secret hashes in plain language

A secret is generated before settlement, while a cryptographic hash derived from that secret can be placed in both escrow conditions. Knowing the hash does not reveal the original secret. When the required escrows are verified, disclosure of the secret proves that the matching condition can be satisfied on both sides.

Ordinary users should not be asked to copy this secret into a website or message. The official 1inch flow manages the mechanism. Anyone requesting a recovery phrase, private key or “Fusion+ secret” through direct messages should be treated as a scammer.

What timelocks protect

Timelocks define when different withdrawal, cancellation and recovery actions become available. They prevent one unresolved order from locking assets indefinitely and establish an ordered response if normal settlement fails.

A timelock is not a promised customer-service deadline. The time visible in an interface can represent auction duration, network confirmation or another stage. Recovery may require the relevant onchain window to open before funds can return.

Safety deposits and resolver incentives

1inch’s resolver terms describe a safety deposit added in a chain’s native asset when a resolver deposits into an escrow. It can compensate the executor of subsequent withdrawal or cancellation actions and creates an economic incentive to complete the required operations.

A safety deposit is not insurance for token-price losses, malicious approvals or every smart-contract failure. It is one mechanism within the resolver and recovery design.

What “atomic cross-chain swap” means

Atomicity means the linked conditions are designed so that the exchange completes consistently or recovery returns assets according to the protocol path. It does not mean both chains write one shared transaction in the same block. Each network has its own transactions, validators and finality.

A cross-chain order can therefore spend minutes in intermediate states while still following an atomic design. Do not interpret “pending” as proof that half the assets have been permanently lost.

Why two-chain finality matters

Ethereum, EVM rollups and Solana do not confirm transactions identically. One chain may finalize quickly while the other is congested or waiting for additional confirmation. Resolver software must avoid revealing or acting on sensitive settlement information before the required states are reliable.

Exact duration depends on the route, current network conditions and the order. A “usually minutes” estimate is not a deadline or guarantee.

Are 1inch cross-chain swaps really gasless?

In Fusion+ settlement, resolvers pay execution gas on the involved networks and include their cost in the economics of the quote. The user does not normally submit each escrow transaction or need destination gas merely to receive the swap.

Gasless is not absolute. A first ERC-20 approval can require an onchain transaction if the token or wallet cannot use a supported permit. Some networks, wallet types, recovery cases or newly deployed integrations may have exceptions. Read the actual wallet request rather than assuming every signature is free.

Do you need gas on the destination chain?

Receiving through a supported Fusion+ route generally does not require a pre-existing destination gas balance because the resolver handles settlement. After delivery, gas may be needed to transfer the asset, approve a dapp or interact with another protocol.

If the user plans to operate on a new chain, receiving some of its native gas asset can prevent the wallet from becoming stranded with a token it cannot move. Check the chain’s actual gas currency; not every EVM network uses ETH.

Keep the tab or wallet open when instructed

Older official launch guidance told users to keep the 1inch swap tab or Wallet application open until verification completed, and warned that premature closure could cancel an order. Newer educational descriptions emphasize that settlement proceeds automatically after signing.

Product behavior can evolve. Follow the current instruction displayed for the individual order. If the application asks to remain open until verification, do so. Save the order ID before navigating away so the swap can be found again.

Expected output versus minimum received

The expected output is an estimate based on a current quote. Minimum received is the boundary encoded in the signed order. Auction movement, liquidity and execution costs can result in an amount between those values.

Reject a quote when the minimum is unacceptable. A familiar source token or reputable destination chain does not compensate for poor execution terms.

Liquidity and price impact across chains

A route needs viable liquidity for the source sale and destination delivery. Large orders, uncommon tokens or recently launched networks can produce wider spreads and fewer competing resolvers. Cross-chain availability does not guarantee deep liquidity for every pair.

Compare the final destination amount after all embedded costs. For a large swap, consider several quote sizes and times. Splitting an order can reduce price impact in one case and increase repeated costs in another.

MEV protection and its limits

Fusion+ orders use the intent-and-resolver model rather than exposing a conventional user swap for public-mempool execution. 1inch describes this design as protection from front-running and sandwich attacks, while the signed minimum constrains the result.

MEV protection does not verify that a token is legitimate, prevent phishing, reverse a malicious approval or protect against market losses after settlement. It addresses an execution problem, not every Web3 threat.

Supported networks are a moving list

Current 1inch material describes cross-chain coverage across more than 18 networks, including EVM chains and Solana. Support expands and can also be limited by product surface, token, liquidity, wallet or region.

Use the current network and token selectors as the account-specific authority. A network listed in developer documentation may not imply that every token pair has a consumer quote at all times.

Verify token contracts on both chains

A ticker such as USDC, ETH or BTC can refer to native, wrapped, bridged or counterfeit assets. Verify the complete source and destination identities through issuer or project documentation and a reputable explorer.

• Check the source chain and contract.
• Check the destination chain and contract independently.
• Confirm decimals and token name.
• Understand whether the output is native, wrapped or bridged.
• Make sure the receiving wallet supports the destination network.

Verify the receiving address

EVM addresses often look identical across EVM networks, but that does not make the networks interchangeable. Solana and other architectures use different formats. Confirm the destination network and full receiver on the wallet display.

When a custom recipient is supported, verify that the address can control the output token. Sending to an exchange deposit address or contract that does not support the route may make recovery difficult or impossible.

Approval, permit and intent are separate requests

An ERC-20 approval authorizes a spender to use a specified allowance. A permit may provide similar authorization through a signature when supported. The Fusion+ intent specifies the order outcome. Users should not click through these as one undifferentiated confirmation.

For each request, inspect the network, token, spender, amount and expiry. An unlimited approval can remain after the order completes. Review and revoke unnecessary allowances using the current official tool or a trusted explorer; disconnecting a wallet does not revoke them.

Common order statuses

Labels can change. Order details and onchain records are more informative than a color or progress animation alone.

Why a cross-chain swap may remain pending

• No resolver has accepted the current auction terms.
• Source-chain confirmation is slow.
• Destination escrow funding is awaiting finality.
• One network is congested or its RPC/indexer is delayed.
• Liquidity changed after the quote.
• The application is still verifying linked contract states.
• A recovery timelock has not yet opened.
• The interface has not indexed an already confirmed transaction.

A pending interface is not proof that nothing happened. Check whether onchain hashes exist before attempting another swap.

What to do when a Fusion+ swap is pending

1. Do not submit the same order again.
2. Keep the tab or application open if the interface requests it.
3. Save the 1inch order ID, source address, pair, amount and timestamp.
4. Check the status from the original wallet in the official 1inch interface.
5. Inspect any source transaction on the correct explorer.
6. Inspect a destination hash if one is displayed.
7. Distinguish auction delay, escrow verification and recovery.
8. Check official status and support channels for an incident.
9. Wait for the applicable timelock rather than using an unofficial recovery site.

What happens when settlement cannot complete?

The linked escrows include cancellation and recovery paths. 1inch’s current educational material says that when a swap does not complete, timelocks expire and locked assets return to their original owners. The return may take time because recovery cannot bypass the contract’s time conditions.

Verify a refund on the source chain and confirm the correct token balance. A failed destination delivery does not require entering a seed phrase or paying a stranger to “synchronize” chains.

Refunds are not conventional chargebacks

A Fusion+ refund follows smart-contract rules; it is not a discretionary reversal of a completed trade. Once both sides settle correctly, market regret is not a reason to undo the order. Recovery applies when normal completion fails under the protocol conditions.

The refund amount and timing should be checked against the order and source-chain transactions. Gas economics, special recovery operations or protocol rules can change, so use current official documentation for an active incident.

Can a cross-chain order be canceled?

Cancellation depends on the order phase. An unsigned quote needs no cancellation. An unfilled intent may expire under its conditions. Once escrows exist, the protocol’s timelocks and recovery phases govern what can happen; an ordinary button cannot safely ignore the other chain.

Do not sign an unexpected cancellation transaction without verifying the network, contract and order. A scammer can imitate a support flow and request an unrelated approval or transfer.

Fusion+ compared with other transfer routes

No route is always best. Compare supported assets, final amount, custody assumptions, recovery options and the user’s ability to execute each process correctly.

Use a small test for an unfamiliar route

A test swap can verify the receiving address, destination token, wallet display and approximate process. First check minimum order requirements and embedded costs; an extremely small transaction may receive a poor quote or be unavailable.

After completion, confirm the destination contract and spendability, not merely a ticker appearing in the wallet. A counterfeit token can display a familiar name while having no legitimate liquidity.

Security checklist before signing

• The official 1inch domain or verified Wallet application is open.
• The intended wallet account is connected.
• Source network, token contract and amount are correct.
• Destination network, token contract and receiver are correct.
• Expected and minimum output are acceptable.
• The difference between approval, permit and order signature is understood.
• The spender and allowance are intentional.
• Any native gas request matches the approval or documented action.
• The order duration and current application instructions are understood.
• The user knows where the order ID and history will appear.

Scams that target cross-chain users

• A fake 1inch site asks for a recovery phrase to unlock a refund.
• A direct message claims a pending swap needs manual validation.
• A “resolver” asks the user to send destination gas to a personal address.
• A counterfeit token uses the expected ticker on the destination chain.
• A support impersonator requests screen control or a wallet export.
• A malicious cancellation signature grants token authority instead.
• A recovery service guarantees it can override escrow timelocks for a fee.

Official support may request public order and transaction identifiers. It does not need private keys, seed words or remote access to the wallet.

Common Fusion+ mistakes

• Confusing a same-chain Fusion order with Fusion+.
• Selecting the right token on the wrong destination network.
• Trusting a ticker without verifying the contract.
• Ignoring minimum received in favor of the optimistic estimate.
• Assuming “gasless” means every approval and recovery action is free.
• Closing the interface while it explicitly requests verification.
• Creating a duplicate swap during a pending phase.
• Expecting the two chains to confirm at the same speed.
• Assuming an expired order produces an instant refund.
• Revoking a required allowance while an order is still active.
• Using an exchange deposit address without confirming compatibility.
• Seeking help from an unsolicited “resolver” in direct messages.

Incident-response checklist

1. Record the order ID and status.
2. Record both chain names and token contracts.
3. Save source and destination transaction hashes.
4. Verify balances through independent explorers.
5. Check whether the order is active, completed or in recovery.
6. Do not revoke permissions impulsively while settlement is active; consult current official guidance.
7. Use the official 1inch help route and provide only public identifiers.
8. If a malicious approval was signed, protect remaining assets using a carefully planned response from an uncompromised device.
9. Preserve screenshots and timestamps for support and accounting.

Frequently asked questions

What is 1inch Fusion+?

Fusion+ is 1inch’s intent-based cross-chain swap protocol. Resolvers coordinate linked escrows on source and destination chains to fulfill a signed outcome.

Is Fusion+ the same as Fusion?

No. Fusion normally executes an intent on one chain. Fusion+ adds cross-chain escrows, two-chain verification, timelocks and recovery.

Is Fusion+ a bridge?

1inch describes it as a bridge-free cross-chain swap architecture. It coordinates assets in linked escrows rather than minting a wrapped representation through a traditional messaging bridge.

Does Fusion+ use wrapped tokens?

The protocol does not require a wrapped stand-in as the transfer mechanism. However, a user can still deliberately select a wrapped token as the destination asset, so verify its contract.

Who are 1inch resolvers?

Resolvers are professional executors that compete to fill intents, provide destination liquidity, fund escrows and pay settlement gas.

Are Fusion+ swaps atomic?

They use linked cryptographic and time conditions designed for consistent completion or recovery. Atomic does not mean one transaction or simultaneous blocks across both chains.

Are 1inch cross-chain swaps gasless?

Resolver settlement is designed to be gasless for the user, with costs reflected in the quote. A separate token approval or exceptional action may still require native gas.

Do I need gas on the destination chain?

Normally not to receive a supported Fusion+ swap. Gas may be required for any later transfer or contract interaction on that chain.

How long does a cross-chain swap take?

Often minutes, but auction timing, liquidity and finality on both networks determine the actual duration. There is no universal completion time.

Why is my 1inch cross-chain swap pending?

It may be waiting for a resolver, escrow creation, network confirmations, finality, indexing or a recovery timelock. Inspect the order status and hashes before retrying.

What happens if Fusion+ does not complete?

The protocol includes timelocked cancellation and recovery paths intended to return locked assets to their original owners when normal settlement fails.

Is a refund immediate?

Not necessarily. The relevant timelock and onchain recovery action may need to occur first, and the interface may take time to index the return.

Should I keep the 1inch tab open?

Follow the current instruction shown for the order. If the dApp or Wallet asks to remain open until verification, do not close it prematurely.

Can I cancel a Fusion+ swap?

It depends on the phase. Before execution, expiry may apply; after escrows exist, cancellation and recovery follow protocol timelocks rather than an unconditional reversal.

Does MEV protection make every swap safe?

No. It reduces front-running and sandwich exposure but does not prevent phishing, fake tokens, bad approvals or smart-contract and market risk.

Which networks support Fusion+?

Current 1inch materials list more than 18 supported networks, including EVM chains and Solana. Check the live selector because availability and token routes change.

Can I send the output to an exchange deposit address?

Only if that exchange explicitly supports the exact destination network and token contract and the route supports the receiver. A wrong deposit route may not be recoverable.

Final takeaway

A 1inch cross-chain swap reduces a multi-step bridge-and-trade workflow to one signed intent. Fusion+ uses competing resolvers, linked escrows, secret-based conditions and timelocks so assets can settle across independent chains without a centralized custodian or wrapped transfer token.

The simpler interface does not remove the need for verification. Check both networks and token contracts, understand minimum received, distinguish approvals from order signatures, save the order ID and respect recovery timing. If a swap is pending, investigate the existing order before creating another or trusting anyone who offers private-message recovery.

Related One Crypto Library guides

• 1inch Fusion Mode: Gasless Swaps, Dutch Auctions and Resolver Execution
• How 1inch Aggregation Works: Routes, MEV Protection and Trade-Offs
• 1inch Limit Orders: Execution, Expiry and Cancellation
• 1inch Wallet Connections, Address Screening and Privacy

Official 1inch resources

• 1inch Learn — Cross-Chain Swaps — the user-level explanation of networks, gas, timing, bridge differences and incomplete-swap recovery.
• 1inch Blog — Introducing Fusion+ Cross-Chain Swaps — the official overview of auctions, resolvers, escrows, secret hashes and timelocks.
• 1inch Blog — Fusion+ Goes Live — the official dApp and Wallet launch guide.
• 1inch Developer Portal — Cross-Chain Swap API — technical phases, gas abstraction, recovery and current supported chains.
• 1inch Help Center — What You Need to Start Swapping — official wallet, approval, gas and Fusion+ preparation guidance.
• 1inch Help Center — Supported Networks — current network availability and switching information.
• 1inch Business — Resolver Terms — official terms covering escrow contracts, safety deposits and resolver recovery duties.
• 1inch — Official Blog — current protocol and product announcements.