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.

The table below represents a resolver’s architecture.

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.