Hamburger image Launch dApp Arrow right

Fusion mode swap resolving

In the first article in a series explaining Fusion mode, we are looking at how swaps are resolved.

Unlike legacy swaps, in Fusion mode swaps, the actual transaction for exchanging one token into another is done by a resolver.

Let’s kick it off with a few important key points.

  • A resolver is a fully automated algorithm that consists of a server app (that determines which orders to fill and when), a set of smart contracts that execute trades and an externally owned account (or a multisig) that sets up the contracts. Resolvers are applications developed by third parties.
  • These applications resolve Fusion mode limit orders (also referred to as “Fusion swaps”), submitted by 1inch users, in automatic mode without involving any individuals.
  • 1inch makes sure that a user making a swap gets at least the minimum guaranteed amount (“minimum to receive”), and an auction mechanism is designed to provide the best possible price and maximize the user’s income.
  • In this framework, created by 1inch, resolvers can also optimize their income.

Resolver architecture

The table below represents a resolver’s architecture.

Architecture component Description Responsibilities
A resolver’s backend A server-side application hosted by a resolver, connected with 1inch’s backend via an API.
  • - Receives orders from the 1inch Relayer Backend, such as information about tokens, token amounts and auction price changes over time.
  • - “Decides” what tokens to swap and when (which orders to fill at which moment), based on a complex logic that is not open-source.
A resolver’s account An externally owned account or a multisig wallet (like Gnosis). Simply put, a wallet that is controlled by an individual or a group of individuals (in the case of a multi-signature wallet).
  • - Stakes 1INCH tokens to the 1inch staking contract to receive st1INCH and Unicorn Power to be able to resolve Fusion swaps and participate in 1inch DAO governance.
  • - Sets the resolver’s workers and whitelists them calling the whitelist contract.
A resolver’s workers Smart contracts or just wallets (externally owned accounts, EOA) associated with the resolver’s account for each of the supported networks (as of early March, Ethereum, BNB Chain and Polygon are supported).
A resolver can have 1 worker per chain, or between 1 and 3 workers in total.
  • - Get “instructions” from the resolver’s backend about orders to be filled.
  • - Calls the settlement protocol
  • - Depending on the implementation, can execute swaps or utilize external smart contracts for that purpose (implementation details will be discussed later).

How to become a resolver

A separate article will be dedicated to this topic. Here, we’ll explain it briefly.

  • Technically, any user who has staked an amount of 1INCH tokens sufficient to receive Unicorn Power of at least 100 can become a resolver. A resolver can also receive Unicorn Power delegated by other users. Apart from resolving, Unicorn Power can be used for participation in DAO governance.
  • To obtain the right to resolve swaps, a resolver has to go through a verification process, which includes KYC/KYB by Synaps and wallet/account screening by TRM Labs (the latter is done to make sure the account in question isn’t linked to any illicit activities).
  • 1inch does not assess any resolver’s backend and worker contract code, which are supposed to be private. Resolvers have to write their own resolver backend and smart contracts. But 1inch offers a simple example of how this can be done: https://github.com/1inch/fusion-resolver-example

The next article in the series will focus on the offchain component of the swap resolving process.

Share the article

Copy icon Copy done!
top-bg top-bg-mobile